הקצאת משאבי רשת באמצעות GKE managed DRANET

Autopilot Standard

‫Google Kubernetes Engine (GKE) DRANET הוא פיצ'ר מנוהל של GKE שמבוסס על הפרויקט DRANET בקוד פתוח, שמטמיע את Kubernetes DRA API למשאבי רשת. ‫DRANET מאפשר לכם לבקש ולהקצות משאבי רשת עם ביצועים גבוהים עבור ה-Pods שלכם, כולל ממשקי רשת שתומכים בגישה ישירה לזיכרון מרחוק (RDMA). הגישה הזו מספקת API נייד שתואם ל-upstream לניהול משאבי רשת.

במאמר הזה מפורטת סקירה כללית של GKE DRANET, ומוסבר איך להקצות משאבי רשת לעומסי עבודה באשכולות GKE.

המסמך הזה מיועד לאדריכלי ענן ולמומחי רשתות שמתכננים רשתות לארגונים שלהם. סקירה כללית של כל מסמכי התיעוד של GKE זמינה במאמר עיון במסמכי התיעוד של GKE. במאמר תפקידים ומשימות נפוצים של משתמשי GKE מוסבר על תפקידים ומשימות נפוצים שמוזכרים ב Google Cloud תוכן.

לפני שקוראים את המסמך הזה, חשוב לוודא שמכירים את הנושאים הבאים:

• הקצאה דינמית של משאבים
• מידע על הקצאת משאבים דינמית ב-GKE
• מושגים ב-Kubernetes
• רישות ב-GKE
• מידע בסיסי על GKE Networking

איך פועל GKE managed DRANET

ההטמעה של GKE managed DRANET מתבצעת באמצעות networking-dra-driver DaemonSet. ה-DaemonSet הזה פועל בצמתים עם מעבדי GPU או TPU שבהם מופעל GKE DRANET.

הוא פועל כסוכן ברמת הצומת כדי לאפשר גילוי של ממשקי רשת והקצאה שלהם ל-Pods באמצעות ממשקי ה-API של הקצאת משאבים דינמית (DRA) ב-Kubernetes.

בגרסאות GKE‏ 1.34.1-gke.1829001 ואילך, GKE מתקין באופן אוטומטי משאבי DeviceClass לרשתות. המחלקות האלה מגדירות את סוגי מכשירי הרשת שאפשר לבקש. לדוגמה, GKE יוצר את המחלקה mrdma.google.com למכשירים עם יכולת RDMA ואת המחלקה netdev.google.com למכשירי רשת אחרים.

כדי להשתמש ב-GKE DRANET, קודם צריך להפעיל את מנהל ההתקן של GKE DRANET במאגר צמתים עם מעבדי GPU או TPU.

כדי לבקש מכשירי רשת לעומס עבודה, מגדירים ResourceClaimTemplate. בתבנית הזו מצוין DeviceClass ומצב ההקצאה, למשל בקשה של כל המכשירים הזמינים בצומת. במפרט של ה-Pod, מפנים לתבנית הזו בשדה resourceClaims כדי לתת ל-Pod גישה לממשקי הרשת המבוקשים בצומת.

מתי כדאי להשתמש ב-DRANET מנוהל של GKE

‫GKE DRANET מספק דרך סטנדרטית לניהול משאבי רשת שמודעים לטופולוגיה ולתלויות. הסטנדרטיזציה הזו הופכת אותו לפתרון מתאים לעומסי עבודה של AI ו-ML שדורשים רשתות עם ביצועים גבוהים.

תרחישים נפוצים לבקשת ממשקי רשת עבור Pod:

• נשלחת בקשה לכל הממשקים הזמינים עם תמיכה ב-RDMA.
• שליחת בקשה למספר ספציפי של ממשקים עם תמיכה ב-RDMA.
• נשלחת בקשה לכל הממשקים הזמינים שאינם RDMA.
• בקשה למספר ספציפי של ממשקי non-RDMA.

נקודות מרכזיות לשימוש ב-GKE managed DRANET לרישות

כדאי לקחת בחשבון את הנקודות הבאות כשמשתמשים ב-GKE DRANET לרשתות:

• ממשקי רשת ייעודיים

  כשמשתמשים ב-GKE DRANET כדי לתבוע ממשק רשת בשביל Pod, הממשק הזה מוקדש ל-Pod הזה. יחידות Pod אחרות באותו צומת לא יכולות לשתף אותו. הגישה הזו עוזרת לוודא של-Pod יש גישה בלעדית לרוחב הפס ולמשאבים המלאים של הממשק הזה, וזה יתרון חשוב לעומסי עבודה שרגישים לביצועים.

• שימוש בדרייבר DRANET מנוהל של GKE באופן עצמאי

  אתם יכולים להפעיל את דרייבר ה-DRA של GKE כדי לנהל משאבי רשת בלי להפעיל דרייברים אחרים של GKE DRANET. כדי לעשות את זה, מוסיפים את התווית cloud.google.com/gke-networking-dra-driver=true למאגר צמתים עם מעבדי GPU ו-TPU.

• שימוש במנהלי התקנים אחרים של GKE DRA

  כדי להשיג תפוקה גבוהה יותר בעומסי עבודה תובעניים של AI/ML, אפשר לשלב את ה-API של DRA למאיצים (כמו GPU ו-TPU) עם רשת מנוהלת של GKE DRANET. הגישה המשולבת הזו משפרת את התאמת המשאבים ואת ההבנה של הטופולוגיה. למידע נוסף על שימוש ב-DRA למשאבים אחרים, אפשר לקרוא את המאמר הכנת תשתית GKE לעומסי עבודה של DRA.

• הימנעו מהגדרות סותרות

  הדרייבר GKE DRANET מנהל ממשקי RDMA ו-gVNIC שלא מוגדרים בהם טווחים של כתובות IP משניות. אל תשתמשו גם במנהל התקן GKE DRANET וגם ב-API של GKE multi-network עם משאב Network מסוג Device באותו אשכול. אי אפשר להשתמש בדרייבר וב-API ביחד, כי שני ממשקי ה-API מנסים לנהל את אותה קבוצה של כרטיסי רשת, מה שעלול להוביל להגדרה שגויה ולהתנהגות בלתי צפויה.

• מחזור חיים מנוהל של מנהל ההתקן של DRANET

  ב-GKE מגרסה 1.34 ואילך, GKE יוצר באופן אוטומטי את מרחב השמות המנוהל gke-managed-networking-dra-driverבאשכול. בדומה לכמה עומסי עבודה אחרים של מערכת GKE, הפודים של מנהל ההתקן DRANET פועלים רק בצמתים שבהם הם רלוונטיים (כמו צמתים עם מעבדי GPU, מעבדי TPU וחומרה מיוחדת אחרת). בצמתים שבהם הדרייבר לא רלוונטי, לא מופעלים פודים של הדרייבר הזה. אל תשנו באופן ידני את ה-DaemonSet של networking-dra-driver. שינויים ידניים, כמו עדכון השדה nodeAffinity, יכולים להפריע לניהול של GKE בתכונה DRANET ולגרום ל-Pods של ה-daemon של DRANET לתזמן בצמתים שלא נתמכים.

דרישות

כדי להשתמש ב-GKE managed DRANET, הסביבה שלכם צריכה לעמוד בדרישות הבאות:

• רגילה: 1.34.1-gke.1829001 ואילך.
• ‫Autopilot: גרסה ‎1.35.2-gke.1842000 ואילך.
• ‫GKE Dataplane V2 מופעל באשכול.

צריך להשתמש באחד מסוגי המכונות הבאים שעברו אופטימיזציה לשימוש במאיצים:

סדרת מכונות	סוג המכונה	מודל המאיץ	טכנולוגיית רישות
A3 Ultra	a3-ultragpu-8g	NVIDIA H200 GPU	RDMA
A4	a4-highgpu-8g	NVIDIA B200 GPU	RDMA
A4X	a4x-highgpu-4g	NVIDIA GB200 GPU	RDMA
‫A4X Max	a4x-maxgpu-4g-metal	NVIDIA B300 GPU	RDMA
‫TPU v7	tpu7x-standard-4t	TPU v7	NetDevice
TPU v6e	ct6e-standard-8t	Trillium TPU	NetDevice
TPU v6e	ct6e-standard-4t	Trillium TPU	NetDevice
TPU v6e	ct6e-standard-1t	Trillium TPU	NetDevice

מגבלות

ל-GKE DRANET יש את המגבלות הבאות:

• אי אפשר להשתמש ב-GKE DRANET כדי להקצות את כרטיס רשת ברירת המחדל (NIC) או כרטיסי רשת וירטואליים (כמו veth).
• סוגים מסוימים של מכונות, במיוחד צומתי Bare Metal כמו a4x-max, לא תואמים לאשכולות של התאמה לעומס (Autoscaling) ו-Autopilot.

שיקולים ספציפיים למכונה

A4X Max bare metal

• פריסת asapd-lite: כשמשתמשים בצומתי GPU בשרת פיזי, כמו A4X Max, צריך לפרוס את asapd-lite DaemonSet באשכול. ‫asapd-lite DaemonSet מגדיר את כרטיסי הרשת (NIC) של RDMA. בלעדיו, לא נוצרים ממשקי צאצא, והדרייבר dranet מסנן את כרטיסי ה-NIC של RDMA, ומונע את הפונקציונליות של RDMA בתוך ה-Pods. הוראות מלאות להגדרה מופיעות במאמר הגדרת כרטיסי הרשת של MRDMA באמצעות asapd-lite.

לפני שמתחילים

לפני שמתחילים, חשוב לוודא שביצעתם את המשימות הבאות:

• מפעילים את ממשק ה-API של Google Kubernetes Engine.
הפעלת Google Kubernetes Engine API
• כדי להשתמש ב-CLI של Google Cloud למשימה הזו, צריך להתקין ואז לאתחל את ה-CLI של gcloud. אם כבר התקנתם את ה-CLI של gcloud, הריצו את הפקודה gcloud components update כדי לקבל את הגרסה העדכנית. יכול להיות שגרסאות קודמות של ה-CLI של gcloud לא יתמכו בהרצת הפקודות שמופיעות במסמך הזה.
  הערה: אם כבר התקנתם את ה-CLI של gcloud, הקפידו להגדיר את compute/region המאפיין. אם אתם משתמשים בעיקר באשכולות אזוריים, צריך להגדיר את compute/zone במקום זאת. אם מגדירים מיקום ברירת מחדל, אפשר להימנע משגיאות ב-CLI של gcloud כמו השגיאה הבאה: One of [--zone, --region] must be supplied: Please specify location. יכול להיות שתצטרכו לציין את המיקום בפקודות מסוימות אם המיקום של האשכול שונה מברירת המחדל שהגדרתם.

התפקידים הנדרשים

כדי לקבל את ההרשאות שנדרשות ליצירת מאגרי צמתים ולהקצאת משאבי רשת, צריך לבקש מהאדמין להקצות לכם ב-IAM את התפקיד אדמין של Kubernetes Engine (roles/container.admin) בפרויקט. כדי לקרוא הסבר על מתן תפקידים, ראו איך מנהלים את הגישה ברמת הפרויקט, התיקייה והארגון.

יכול להיות שאפשר לקבל את ההרשאות הנדרשות גם באמצעות תפקידים בהתאמה אישית או תפקידים מוגדרים מראש.

יצירת אשכול

יוצרים אשכול GKE Standard שמשתמש ב-GKE Dataplane V2:

gcloud container clusters create CLUSTER_NAME \
    --enable-dataplane-v2 \
    --region=CONTROL_PLANE_LOCATION \
    --project=PROJECT_ID \
    --cluster-version=CLUSTER_VERSION

מחליפים את מה שכתוב בשדות הבאים:

• ‫CLUSTER_NAME: השם של האשכול החדש.
• ‫CONTROL_PLANE_LOCATION: האזור או האזור שבו נמצא מישור הבקרה של האשכול, למשל us-central1 או us-central1-a.
• ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
• ‫CLUSTER_VERSION: גרסת GKE של האשכול. הגרסה צריכה להיות ‎1.34.1-gke.1829001 ואילך.

שימוש בממשקי RDMA ממאגר צמתים של GPU

בקטעים הבאים מוסבר איך להגדיר מאגר צמתים ועומס עבודה של GPU לשימוש בממשקי רשת RDMA עם GKE DRANET.

הפעלת דרייבר DRANET מנוהל של GKE במאגר צמתים של GPU

כדי להפעיל את דרייבר ה-DRANET של GKE במאגר צמתים של GPU שתומך ב-RDMA, מוסיפים את התווית cloud.google.com/gke-networking-dra-driver=true כשיוצרים את מאגר הצמתים.

gcloud beta container node-pools create NODE_POOL_NAME \
  --region=REGION \
  --cluster=CLUSTER_NAME \
  --node-locations=NODE_LOCATIONS \
  --accelerator type=ACCELERATOR_TYPE,count=ACCELERATOR_COUNT,gpu-driver-version=DRIVER_VERSION \
  --machine-type=MACHINE_TYPE \
  --num-nodes=NUM_NODES \
  --reservation-affinity=specific \
  --reservation=projects/RESERVATION_PROJECT/reservations/RESERVATION_NAME/reservationBlocks/RESERVATION_BLOCK \
  --accelerator-network-profile=auto \
  --node-labels=cloud.google.com/gke-networking-dra-driver=true

מחליפים את מה שכתוב בשדות הבאים:

• ‫NODE_POOL_NAME: השם של מאגר הצמתים החדש.
• ‫REGION: האזור Google Cloud של האשכול.
• ‫CLUSTER_NAME: שם האשכול.

• ‫ACCELERATOR_TYPE: סוג התאוצה של ה-GPU:

  לדוגמה:

  • מכונות וירטואליות מסוג A4: מזינים nvidia-b200.
  • מכונות וירטואליות של A3 Ultra: מזינים nvidia-h200-141gb.

• ‫ACCELERATOR_COUNT: מספר יחידות ה-GPU לצירוף לצמתים במאגר הצמתים. לדוגמה, גם במכונות וירטואליות מסוג a4-highgpu-8g וגם במכונות וירטואליות מסוג a3-ultragpu-8g, מספר ה-GPU הוא 8.

• ‫DRIVER_VERSION: גרסת מנהל ההתקן של ה-GPU לשימוש. לדוגמה, default או latest.

• ‫MACHINE_TYPE: סוג המכונה של מאגר הצמתים, לדוגמה a3-ultragpu-8g.

• ‫NUM_NODES: מספר הצמתים במאגר הצמתים. עבור התחלה גמישה (Flex-start), הערך הזה חייב להיות 0.

• ‫RESERVATION_PROJECT: מזהה הפרויקט של ההזמנה.

• ‫RESERVATION_NAME: שם ההזמנה. כדי למצוא את הערך הזה, עיינו בקטע הצגת בקשות למקום שמור לעתיד.

• ‫RESERVATION_BLOCK: השם של בלוק ספציפי בהזמנה. כדי למצוא את הערך הזה, עיינו בקטע הצגת בקשות למקום שמור לעתיד.

הפקודה הזו משתמשת בפרופילים של רשתות מאיצים כדי להגדיר באופן אוטומטי רשתות VPC ותתי-רשתות למכונות הווירטואליות של המאיצים. אפשר גם לציין במפורש את רשת ה-VPC ואת רשתות המשנה.

פריסת משאבי RDMA של עומס עבודה

כדי להקצות משאבי RDMA ל-Pod, מציינים ResourceClaimTemplate.

1. יוצרים ResourceClaimTemplate כדי להגדיר איך להקצות את מכשירי ה-RDMA. במניפסט הבא יש בקשה לכל מכשירי mrdma הזמינים בצומת. שומרים את המניפסט בתור all-mrdma-template.yaml:

   apiVersion: resource.k8s.io/v1
   kind: ResourceClaimTemplate
   metadata:
     name: all-mrdma
   spec:
     spec:
       devices:
         requests:
         - name: req-mrdma
           exactly:
             deviceClassName: mrdma.google.com
             allocationMode: All
   

2. החלת המניפסט:

   kubectl apply -f all-mrdma-template.yaml
   

3. פורסים את עומס העבודה ומפנים אל ResourceClaimTemplate. המניפסט הבא פורס Pod שמפנה לתבנית all-mrdma, שנותנת ל-Pod גישה לממשקי ה-RDMA בצומת. שומרים את קובץ המניפסט בשם agnhost-rdma-pod.yaml:

   apiVersion: v1
   kind: Pod
   metadata:
     name: agnhost-rdma
     namespace: default
     labels:
       app: agnhost
   spec:
     containers:
     - name: agnhost
       image: registry.k8s.io/e2e-test-images/agnhost:2.39
       args: ["netexec", "--http-port", "80"]
       ports:
       - name: agnhost-port
         containerPort: 80
       resources:
         claims:
         - name: rdma
         limits:
           nvidia.com/gpu: 1
     resourceClaims:
     - name: rdma
       resourceClaimTemplateName: all-mrdma
   

4. החלת המניפסט:

   kubectl apply -f agnhost-rdma-pod.yaml
   

5. מוודאים שממשקי הרשת הנוספים שהוקצו גלויים בתוך ה-Pod.

   kubectl exec agnhost-rdma -- ls /sys/class/net
   

   בדוגמה הבאה של הפלט מוצגים ממשקי ברירת המחדל eth0 ו-lo, וגם ממשקי ה-RDMA שהוקצו, כמו gpu0rdma0. המספר והשמות של ממשקי הרשת (NIC) משתנים בהתאם לסוג המכונה של צומת GKE.

   eth0
   gpu0rdma0
   gpu1rdma0
   gpu2rdma0
   gpu3rdma0
   lo
   

שימוש בממשקי רשת שאינם RDMA במאגר צמתי TPU

בקטעים הבאים מוסבר איך להגדיר מאגר צמתים של TPU ועומס עבודה כדי להשתמש בממשקי רשת שאינם RDMA עם GKE DRANET.

אימות של DeviceClasses ברשת

מוודאים שמשאבי DeviceClass לרשת קיימים באשכול.

kubectl get deviceclass netdev.google.com

הפלט אמור להיראות כך:

NAME                AGE
netdev.google.com   2d22h

הפעלת דרייבר DRANET מנוהל של GKE במאגר צמתים של חלקי TPU

כדי להפעיל את מנהל ההתקן של GKE DRANET כשיוצרים מאגר צמתים של פרוסות TPU, מוסיפים את התווית cloud.google.com/gke-networking-dra-driver=true.

gcloud beta container node-pools create NODE_POOL_NAME \
    --location=LOCATION \
    --cluster=CLUSTER_NAME \
    --node-locations=NODE_LOCATIONS \
    --machine-type=MACHINE_TYPE \
    --tpu-topology=TPU_TOPOLOGY \
    --num-nodes=NUM_NODES \
    --accelerator-network-profile=auto \
    --node-labels=cloud.google.com/gke-networking-dra-driver=true

מחליפים את מה שכתוב בשדות הבאים:

• NODE_POOL_NAME: השם של מאגר הצמתים החדש.
• ‫LOCATION: האזור Google Cloud או האזור של האשכול.
• ‫CLUSTER_NAME: השם של האשכול.
• ‫NODE_LOCATIONS: האזורים ( Google Cloud ) של הצמתים במאגר הצמתים.
• ‫MACHINE_TYPE: סוג המכונה שבה משתמשים לצמתים. למידע נוסף על סוגי מכונות שתואמים ל-TPU, קראו את המאמר בחירת גרסת TPU.
• ‫TPU_TOPOLOGY: הטופולוגיה של ה-TPU, לדוגמה 2x4x4. הפורמט של הטופולוגיה תלוי בגרסת ה-TPU. מידע נוסף על טופולוגיות של TPU זמין במאמר בחירת טופולוגיה.
• ‫NUM_NODES: מספר הצמתים במאגר הצמתים.

מידע נוסף זמין במאמר יצירת מאגר צמתים של פרוסות TPU במארח יחיד.

פריסת עומס עבודה שדורש את כל מכשירי הרשת

כדי להקצות מכשירי רשת שאינם RDMA לקבוצת Pod, צריך לציין ResourceClaimTemplate.

1. יוצרים ResourceClaimTemplate שמפנה אל netdev.google.com DeviceClass. המניפסט הבא מבקש את כל מכשירי הרשת שזמינים בצומת ושאינם RDMA.

   שומרים את קובץ המניפסט בשם all-netdev-template.yaml:

   apiVersion: resource.k8s.io/v1
   kind: ResourceClaimTemplate
   metadata:
     name: all-netdev
   spec:
     spec:
       devices:
         requests:
         - name: req-netdev
           exactly:
             deviceClassName: netdev.google.com
             allocationMode: All
   

2. החלת המניפסט:

   kubectl apply -f all-netdev-template.yaml
   

3. פורסים את עומס העבודה ומפנים אל ResourceClaimTemplate. המניפסט הבא פורס Pod שמשתמש בתבנית all-netdev כדי להעניק ל-Pod גישה לכל מכשירי הרשת שאינם RDMA בצומת. שומרים את המניפסט בתור netdev-pod.yaml:

   apiVersion: v1
   kind: Pod
   metadata:
     name: agnhost-netdev
     namespace: default
     labels:
       app: agnhost
   spec:
     containers:
     - name: agnhost
       image: registry.k8s.io/e2e-test-images/agnhost:2.39
       args: ["netexec", "--http-port", "80"]
       ports:
       - name: agnhost-port
         containerPort: 80
       resources:
         claims:
         - name: netdev
         limits:
           google.com/tpu: 4
     nodeSelector:
       cloud.google.com/gke-tpu-accelerator: TPU_ACCELERATOR
       cloud.google.com/gke-tpu-topology: TPU_TOPOLOGY
     resourceClaims:
     - name: netdev
       resourceClaimTemplateName: all-netdev
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫TPU_ACCELERATOR: סוג מאיץ ה-TPU, לדוגמה tpu-v5p-slice.
   • ‫TPU_TOPOLOGY: טופולוגיית ה-TPU, לדוגמה, 2x4x4.

4. מחילים את המניפסט:

   kubectl apply -f netdev-pod.yaml
   

5. מוודאים שממשקי הרשת הנוספים שהוקצו גלויים בתוך ה-Pod.

   kubectl exec agnhost-netdev -- ls /sys/class/net
   

   בדוגמת הפלט הבאה מוצגים ממשקי ברירת המחדל eth0 ו-lo, וגם מכשירי הרשת שהוקצו, עם שמות כמו eth1 ו-eth2. מספר כרטיסי ה-NIC והשמות שלהם משתנה בהתאם לסוג המכונה של צומת GKE.

   eth0
   eth1
   eth2
   lo
   

הפעלת DRANET עם ComputeClass בהתאמה אישית

כדי להשתמש ב-GKE managed DRANET באשכולות Autopilot או בהקצאה אוטומטית של צמתים באשכולות Standard, צריך להשתמש במשאב ComputeClass מותאם אישית כדי להביע הסכמה לתכונה.

1. יוצרים מניפסט ComputeClass שמפעיל את דרייבר DRANET ומגדיר את פרופיל הרשת של מאיץ החומרה ל-auto:

   apiVersion: cloud.google.com/v1
   kind: ComputeClass
   metadata:
     name: dranet-compute-class
   spec:
     nodePoolAutoCreation:
       enabled: true
     nodePoolConfig:
       dra:
         networking:
           enabled: true
     priorities:
     - machineType: MACHINE_TYPE
       gpu:
         count: GPU_COUNT
         type: GPU_TYPE
       acceleratorNetworkProfile: auto
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫MACHINE_TYPE: סוג המכונה של מאגר הצמתים, למשל a3-ultragpu-8g.
   • ‫GPU_COUNT: מספר יחידות ה-GPU לסוג המכונה.
   • ‫GPU_TYPE: סוג ה-GPU, למשל nvidia-h200.

2. מחילים את המניפסט:

   kubectl apply -f COMPUTE_CLASS_FILENAME.yaml
   

3. במפרט של ה-Pod, מפנים אל ComputeClass באמצעות cloud.google.com/compute-class node selector:

   apiVersion: v1
   kind: Pod
   metadata:
     name: dranet-pod
   spec:
     nodeSelector:
       cloud.google.com/compute-class: "dranet-compute-class"
     ...
   

בקשה למספר ספציפי של מכשירים ברשת

בדוגמאות הקודמות אפשר לראות איך לבקש את כל התקני הרשת הזמינים מסוג מסוים, על ידי הגדרת allocationMode לערך All. אם אתם צריכים לבקש מספר ספציפי של מכשירים, אתם יכולים להגדיר את allocationMode ל-ExactCount ב-ResourceClaimTemplate.

בדוגמה הבאה מוצגת בקשה לשני מכשירי רשת RDMA:

apiVersion: resource.k8s.io/v1
kind: ResourceClaimTemplate
metadata:
  name: two-mrdma
spec:
  spec:
    devices:
      requests:
      - name: req-mrdma
        exactly:
          deviceClassName: mrdma.google.com
          allocationMode: ExactCount
          count: 2

המאמרים הבאים

• מידע נוסף על הקצאת משאבים דינמית
• מידע נוסף על הגדרת רשת אוטומטית למכונות וירטואליות של מאיצים