הגדרת רשת אוטומטית למכונות וירטואליות של מאיצים

במאמר הזה נסביר איך להשתמש ברשת אוטומטית למכונות וירטואליות עם מאיצים, כמו GPU ו-TPU, כדי לפשט את הגדרת הרשת לעומסי עבודה של מאיצים ב-Google Kubernetes Engine‏ (GKE). התכונה הזו חיונית להפעלת בינה מלאכותית (AI), למידת מכונה (ML) ומחשוב עתיר ביצועים (HPC) במכונות שעברו אופטימיזציה להאצה.

ההנחה במאמר הזה היא שאתם מכירים את המושגים הבסיסיים של GKE, את עומסי העבודה של GPU ו-TPU ואת הרישות של VPC. באופן ספציפי, חשוב להכיר את הנושאים הבאים:

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

‫GKE מפשט את ההפעלה של AI ו-ML עם ביצועים גבוהים במאיצים מיוחדים. בעזרת רשתות אוטומטיות למכונות וירטואליות של מאיצים, אתם יכולים להפעיל קישוריות מהירה בין כמה רשתות – דבר חיוני לפרוטוקולים כמו RDMA – באמצעות דגל הגדרה יחיד. האוטומציה הזו מבטלת את התהליך המורכב והידני של הגדרת כמה רשתות VPC, ניהול טווחי כתובות IP והגדרת ממשקי רשת לכל מאגר צמתים ו-Pod. כשמשתמשים בפרמטר יחיד ליצירת מאגר צמתים, GKE מספק את כל משאבי הרשת הדרושים בענן וב-Kubernetes.

הסברים על המונחים

המונחים הבאים חשובים להבנת ארכיטקטורת הרשת של מכונות וירטואליות עם מאיצים.

  • ענן וירטואלי פרטי (VPC): VPC הוא גרסה וירטואלית של רשת פיזית, שמוטמעת בתוך רשת הייצור של Google. הוא מספק קישוריות למכונות וירטואליות (VM) ב-Compute Engine, לאשכולות GKE ולמשאבים אחרים.
  • Titanium NIC: כרטיס רשת חכם שמבצע את משימות העיבוד של הרשת במקום המעבד, וכך מאפשר למעבד להתמקד בעומסי העבודה. במכונות עם GPU, הם מטפלים בכל התנועה שלא מגיעה ישירות מה-GPU. במכונות TPU, כל כרטיסי ה-NIC הם כרטיסי Titanium NIC.
  • תת-רשת: תת-רשת היא חלק מפולח של רשת VPC גדולה יותר. כל תת-רשת משויכת לאזור מסוים ויש לה טווח כתובות IP מוגדר.
  • כרטיס רשת (NIC): NIC הוא ממשק רשת וירטואלי שמחבר מכונה וירטואלית לרשת. כל כרטיס NIC מצורף לרשת VPC ולתת-רשת ספציפיות.
  • רשת המארח: הרשת הראשית שמשמשת את ממשקי הרשת (NIC) של הצומת לתקשורת כללית של האשכול, כמו תעבורה של מישור הבקרה ורשתות רגילות של Pod.
  • רשת נתונים: רשת ייעודית להעברת נתונים בביצועים גבוהים בין מכונות וירטואליות של מאיצים. במקרה של יחידות GPU, לרוב מדובר ב-GPUDirect VPC עם RDMA. ב-TPU, יכול להיות שמדובר ברשת מארחת שנייה.
  • גישה ישירה לזיכרון מרחוק(RDMA): ‫RDMA היא טכנולוגיה שמאפשרת למכשירי רשת להחליף נתונים ישירות עם הזיכרון הראשי של מחשב בלי לערב את מערכת ההפעלה או את המעבד. כך מצמצמים באופן משמעותי את זמן האחזור ומשפרים את קצב העברת הנתונים, שזה קריטי לעומסי עבודה של HPC ו-ML.
  • NVLink: ‏NVLink היא טכנולוגיית קישוריות מהירה שפותחה על ידי NVIDIA כדי לקשר בין כמה מעבדים גרפיים בתוך צומת יחיד, וכך לאפשר להם לשתף זיכרון ולעבוד יחד על מערכי נתונים גדולים.
  • הקצאה דינמית של משאבים (DRA) ב-Kubernetes: DRA היא תכונה של Kubernetes שמספקת דרך גמישה יותר ל-Pods לבקש משאבים ולצרוך אותם, כמו יחידות GPU וחומרה מיוחדת אחרת. הוא מאפשר שליטה פרטנית בהקצאת משאבים.

איך פועל יצירת קשרים אוטומטית

למכונות שעברו אופטימיזציה למאיצים יש ארכיטקטורת רשת מיוחדת שתומכת בתפוקה גבוהה ובתקשורת עם זמן אחזור נמוך בין יחידות GPU ו-TPU. כל מכונה פיזית מכילה כמה יחידות GPU או TPU, שלרוב מחוברות באמצעות חיבורים מהירים כמו NVLink. למכונות יש גם כרטיס NIC אחד או יותר לרשתות כלליות, וכמה כרטיסי NIC של GPU לחיבורים מהירים.

כשיוצרים צומת GKE שמשתמש בסוג מכונה שעבר אופטימיזציה להאצה, GKE מגדיר כמה כרטיסי רשת במכונת ה-VM הבסיסית. כרטיסי ה-NIC של המארח מתחברים לרשתות ה-VPC של המארח כדי לאפשר תקשורת וניהול כלליים של האשכול, וכדי לתקשר עם מישור הבקרה. כרטיסי רשת של GPU מתחברים לרשת VPC ייעודית עם ביצועים גבוהים, לרוב עם RDMA מופעל והגדרת MTU גבוהה (8896), כדי לאפשר תקשורת GPUDirect.

כש-Pod מבקש יחידות GPU או TPU, אפשר להגדיר אותו כך שתהיה לו גישה לממשקי הרשת בעלי הביצועים הגבוהים בצומת. אתם יכולים לבקש את כל כרטיסי ה-NIC הזמינים או קבוצת משנה ספציפית. כל ממשק רשת שמוקצה מוקדש ל-Pod אחד ולא משותף. הגדרת הרשת הזו עוזרת לוודא של-Pod יש גישה בלעדית לרוחב הפס ולמשאבים המלאים של הממשק הזה. זהו יתרון חשוב לעומסי עבודה שרגישים לביצועים.

מגבלות

  • כדי להשתמש באוטומציה של רשתות, צריך להגדיר את האשכול לשימוש ב-GKE Dataplane V2.
  • סוגי מכונות נתמכים: רשתות אוטומטיות נתמכות במשפחות של מכונות שעברו אופטימיזציה למאיצי A3,‏ A4 ו-TPU Trillium (גרסה v6e).
  • חובה להשתמש במאגרי צמתים של אזור יחיד: אתם צריכים להשתמש במאגר צמתים עם אזור יחיד.
  • כשמשתמשים ב-DRANET מנוהל של GKE כדי להגדיר עומסי עבודה, כדאי לעיין בשיקולים העיקריים ובמגבלות של DRANET מנוהל של GKE.
  • אי אפשר להשתמש גם ב-multi-network API וגם ב-DRANET באותו מאגר צמתים. צריך לבחור שיטה אחת לצירוף רשת ל-Pods.
  • במקרה של אשכולות אזוריים, צריך לציין את אזור היעד כשמפעילים פרופילים של רשתות מאיצות. אם עומס העבודה שלכם מתפרס על כמה אזורים, אתם צריכים להפעיל את פרופיל הרשת לכל אזור בנפרד.

תצורות רשת של מכונות שעברו אופטימיזציה למאיץ

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

מכונות וירטואליות עם מאיץ GPU

סוג המכונה מספר יחידות ה-GPU מספר כרטיסי ה-NIC של Titanium מספר כרטיסי ה-NIC של ה-GPU טכנולוגיית GPUDirect עוד עננים וירטואליים פרטיים (VPC)
A3 ‫8 (H100) 1 4 TCPX ‫4 עבור כרטיסי רשת של GPU
A3 Mega ‫8 (H100) 1 8 TCPXO ‫8 עבור כרטיסי GPU NIC
A3 Ultra ‫8 (H200) 2 8 RDMA ‫2 (1 עבור כרטיס רשת שני, 1 עבור כרטיסי רשת של GPU)
A4 ‫8 (B200) 2 8 RDMA ‫2 (1 עבור כרטיס רשת שני, 1 עבור כרטיסי רשת של GPU)
A4X ‫4 (GB200) 2 4 RDMA ‫2 (1 עבור כרטיס רשת שני, 1 עבור כרטיסי רשת של GPU)
A4X BM 8 2 8 BM-RDMA ‫2 (1 עבור כרטיס רשת שני, 1 עבור כרטיסי רשת של GPU)

מכונות וירטואליות עם מאיצי TPU

סוג המכונה מספר שבבי ה-TPU מספר כרטיסי ה-NIC עוד עננים וירטואליים פרטיים (VPC)
TPU Trillium (v6e) (ct6e-standard-1t) 1 0.25 1
TPU Trillium (v6e) (ct6e-standard-4t) 4 2 ‫2 (1 עבור כרטיס רשת שני, 1 עבור כרטיס רשת וירטואלי נוסף בכרטיס הרשת הראשון)
TPU Trillium (v6e) (ct6e-standard-8t) 8 4 4
tpu7x-standard-4t 4 2 2

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

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

  • מפעילים את ממשק Google Kubernetes Engine API.
  • הפעלת Google Kubernetes Engine API
  • כדי להשתמש ב-CLI של Google Cloud למשימה הזו, צריך להתקין ואז לאתחל את ה-CLI של gcloud. אם התקנתם בעבר את ה-CLI של gcloud, תוכלו להריץ את הפקודה gcloud components update כדי לקבל את הגרסה העדכנית. יכול להיות שגרסאות קודמות של ה-CLI של gcloud לא יתמכו בהרצת הפקודות שמופיעות במסמך הזה.
  • מוודאים שהגרסה של GKE באשכול היא 1.34.1-gke.2037000 ואילך.
  • כדי להפעיל הקצאת צמתים אוטומטית (NAP) ומחלוקות ComputeClass בהתאמה אישית, צריך לוודא שהאשכול שלכם משתמש בגרסה GKE 1.35.2-gke.1302000 ואילך.

  • מוודאים שלחשבון השירות של GKE בפרויקט מוקצה התפקיד compute.networkAdmin.

  • מוודאים שהאשכול כולל את GKE Dataplane V2. אפשר להפעיל את GKE Dataplane V2 רק כשיוצרים אשכול חדש ב-GKE בגרסה 1.34.1-gke.2037000 ואילך. אי אפשר להפעיל את GKE Dataplane V2 באשכולות שקודמים לגרסה הזו.

      gcloud container clusters create CLUSTER_NAME \
        --cluster-version=CLUSTER_VERSION \
        --enable-dataplane-v2
    
  • אם אתם מתכננים לפרוס עומסי עבודה של GPU שמשתמשים ב-RDMA, אתם צריכים לוודא שקיימים משאבי DeviceClass:

    kubectl get deviceclass mrdma.google.com
    

הגדרת רשת אוטומטית

כדי להפעיל רשת אוטומטית, צריך לציין פרופיל רשת של מאיץ כשיוצרים מאגר צמתים. אפשר גם ליצור משאב ComputeClass לאשכולות שמשתמשים בהקצאת משאבים אוטומטית של צמתים.

יצירת מאגר צמתים עם פרופיל רשת שמוגדר כברירת מחדל

כדי ליצור באופן אוטומטי רשת שמחברת את כל מכונות ה-GPU או ה-TPU באזור יחיד, צריך ליצור מאגר צמתים עם פרופיל auto accelerator network.

gcloud

כדי ליצור מאגר צמתים עם פרופיל רשת שהוגדר אוטומטית, מריצים את הפקודה הבאה:

gcloud beta container node-pools create NODE_POOL_NAME \
    --accelerator-network-profile=auto \
    --node-locations=ZONE \
    --machine-type=MACHINE_TYPE

כשיוצרים מאגר צמתים עם הדגל --accelerator-network-profile=auto,‏ GKE מוסיף באופן אוטומטי את התווית gke.networks.io/accelerator-network-profile: auto לצמתים. כדי לתזמן עומסי עבודה בצמתים האלה, צריך לכלול את התווית הזו בקובץ ה-nodeSelector של עומס העבודה.

מידע נוסף על יצירת מאגרי צמתים עם מאיצים זמין במאמרים בנושא הפעלת GPU במאגרי צמתים של Autopilot ופריסת עומסי עבודה של TPU ב-Autopilot. כשפועלים לפי ההוראות במסמכים האלה, מוסיפים את הדגל --accelerator-network-profile=auto לפקודה gcloud container node-pools create.

במאגרי צמתים של פרוסות TPU עם כמה מארחים, צריך להוסיף גם את הדגל --tpu-topology.

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

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

REST

בבקשה לשיטה nodePools.create, מציינים את השדה accelerator_network_profile:

{
  "nodePool": {
    "name": "NODE_POOL_NAME",
    "machineType": "MACHINE_TYPE",
    ...
    "accelerator_network_profile": "auto"
  }
}

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

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

הפעלת יצירה אוטומטית של רשתות באמצעות Node Auto Provisioning

כדי להגדיר רשת אוטומטית באשכולות Autopilot או באשכולות רגילים שמשתמשים בהקצאת משאבים אוטומטית של צמתים, מוסיפים את השדה acceleratorNetworkProfile למשאב ComputeClass.

  1. במניפסט ComputeClass הבא מופעלת רשת אוטומטית למכונות A3 Mega. שומרים את קובץ המניפסט הבא בשם anp-compute-class.yaml:

    apiVersion: cloud.google.com/v1
    kind: ComputeClass
    metadata:
      name: anp-a3-mega-class
    spec:
      autopilot:
        enabled: true
      nodePoolAutoCreation:
        enabled: true
      priorities:
      # Priority 1: A3 Mega in us-central1-a
      - machineType: a3-megagpu-8g
        gpu:
          count: 8
          driverVersion: default
          type: nvidia-h100-mega-80gb
        flexStart:
          enabled: true
        location:
          zones: [us-central1-a]
        acceleratorNetworkProfile: auto
      whenUnsatisfiable: DoNotScaleUp
    
  2. מחילים את המניפסט על האשכול:

    kubectl apply -f anp-compute-class.yaml
    

כשפורסים עומס עבודה שבוחר במשאב ComputeClass הזה,‏ GKE מגדיר באופן אוטומטי את ממשקי הרשת הנדרשים לצמתים שהוקצו.

תזמון של עומס עבודה שמשתמש ב-GPU

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

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

כדי להפעיל את דרייבר GKE DRANET במאגר צמתים של 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.
    • מכונות VM מסוג 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
    

תזמון של עומס עבודה שמשתמש ב-TPU

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

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

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

kubectl get deviceclass netdev.google.com

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

NAME                AGE
netdev.google.com   2d22h

הפעלת דרייבר GKE מנוהל של DRANET במאגר צמתים של פרוסת 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
    

פתרון בעיות

כדי לבדוק את הגדרת הרשת של מאגר צמתים, מריצים את הפקודה הבאה:

gcloud beta container node-pools describe NODE_POOL_NAME \
    --zone=ZONE \
    --cluster=CLUSTER_NAME

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

  • NODE_POOL_NAME: השם של מאגר הצמתים.
  • ZONE: האזור של מאגר הצמתים.
  • CLUSTER_NAME: השם של האשכול.

בפלט מוצגים הרשתות הנוספות ורשתות המשנה שמצורפות למאגר הצמתים.

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