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

Autopilot Standard

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

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

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

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

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

איך פועל DRANET שמנוהל על ידי GKE

‫DRANET שמנוהל על ידי GKE מוטמע באמצעות DaemonSet של networking-dra-driver. ה-DaemonSet הזה פועל בצמתים עם GPUs,‏ TPUs או מכונות וירטואליות שמותאמות לאחסון, שבהם GKE DRANET מופעל.

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

בגרסאות GKE‏ 1.34.1-gke.1829001 ואילך, GKE מתקין באופן אוטומטי משאבי DeviceClass לרשתות. המחלקות האלה מגדירות את סוגי מכשירי הרשת שאפשר לבקש. לדוגמה, GKE יוצר את המחלקה mrdma.google.com למכונות וירטואליות של GPU, את המחלקה netdev.google.com ל-TPU ולהתקני רשת אחרים, ואת המחלקה irdma.google.com למכונות וירטואליות שמותאמות לאחסון (כמו Z4M).

כדי להשתמש ב-GKE DRANET, קודם צריך להפעיל את מנהל ההתקן של GKE DRANET במאגר צמתים עם GPUs,‏ TPUs או מכונות וירטואליות שמותאמות לאחסון.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

דרישות

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

• ‫Standard: ‏1.34.1-gke.1829001 ואילך (1.36.3-gke.1767000 ואילך למכונות וירטואליות מסוג Z4M).
• ‫Autopilot: גרסה ‎1.35.2-gke.1842000 ואילך (גרסה ‎1.37.0-gke.4713000 ואילך למכונות וירטואליות מסוג Z4M).
• ‫GKE Dataplane V2 מופעל באשכול.

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

סדרת מכונות	סוג המכונה	מודל המאיץ	טכנולוגיית רישות	DeviceClass
A3 Ultra	a3-ultragpu-8g	NVIDIA H200 GPU	RDMA	mrdma.google.com
A4	a4-highgpu-8g	NVIDIA B200 GPU	RDMA	mrdma.google.com
A4X	a4x-highgpu-4g	NVIDIA GB200 GPU	RDMA	mrdma.google.com
A4X Max	a4x-maxgpu-4g-metal	NVIDIA B300 GPU	RDMA	mrdma.google.com
TPU v7	tpu7x-standard-4t	TPU v7	NetDevice	netdev.google.com
TPU v6e	ct6e-standard-8t	Trillium TPU	NetDevice	netdev.google.com
TPU v6e	ct6e-standard-4t	Trillium TPU	NetDevice	netdev.google.com
TPU v6e	ct6e-standard-1t	Trillium TPU	NetDevice	netdev.google.com
Z4M	כל סוג מכונה Z4M שתומך ב-IRDMA	לא רלוונטי (אופטימיזציה של אחסון)	RDMA	irdma.google.com

מגבלות

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

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

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

בהתאם לארכיטקטורת החומרה הבסיסית של הצמתים, בחלק מסדרות המכונות נדרשים דגלים נוספים של מאגרי צמתים, חבילות של קובצי אימג' של קונטיינרים או DaemonSets של המערכת כדי להגדיר ממשקי RDMA עם GKE DRANET.

A4X Max bare metal

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

מכונות וירטואליות מסוג Z4M עם אופטימיזציה לאחסון

• דרישות לגבי קובץ האימג' של הקונטיינר: כדי להשתמש ב-RDMA במכונות Z4M, צריך להשתמש בקובץ אימג' של קונטיינר Rocky Linux 8 שמוגדר עם חבילות ה-RDMA הנדרשות במרחב המשתמש. אין תמיכה בהפצות אחרות, כמו Ubuntu או Debian. בחבילות ה-upstream הרגילות של ההפצות האלה חסרות התוספות המותאמות אישית של ה-ABI שנדרשות למנהל ההתקן של IRDMA. בלי התוספים האלה, החבילות נכשלות בזמן הריצה עם שגיאת -ENOSPC. הוראות להגדרה מופיעות במאמר שימוש בממשקי RDMA במאגר של צמתים עם אופטימיזציה לאחסון.

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

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

• מפעילים את Google Kubernetes Engine API.
הפעלת Google Kubernetes Engine API
• כדי להשתמש ב-Google Cloud CLI למשימה הזו, מתקינים ואז מאתחלים את ה-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 של האשכול:
  • ‫מכונות וירטואליות מסוג Z4M: גרסה 1.36.3-gke.1767000 ואילך
  • כל שאר המכונות הווירטואליות או המכונות ללא מערכת הפעלה שנתמכות: גרסה 1.34.1-gke.1829001 ואילך

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

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

הפעלת מנהל התקן 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 VMs: מזינים 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: מספר הצמתים במאגר הצמתים. במודל "התחלה גמישה", הערך הזה חייב להיות 0.

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

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

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

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

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

כדי להקצות משאבי RDMA לפוד, מציינים 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
   

שימוש בממשקי RDMA במאגר צמתים שעבר אופטימיזציה לאחסון

בקטעים הבאים מוסבר איך להגדיר מאגר צמתים ועומס עבודה שמותאמים לאחסון, כדי להשתמש בממשקי רשת RDMA עם GKE DRANET, באמצעות VM מסוג Z4M (z4m-highmem-192) כדוגמה.

יצירת מאגר צמתים עם אופטימיזציה לאחסון

יוצרים מאגר צמתים עם אופטימיזציה לאחסון באמצעות הדגל --accelerator-network-profile=auto, כדי ש-GKE יקצה ויצרף באופן אוטומטי את רשתות ה-VPC, רשתות המשנה וממשקי הרשת המשניים של Falcon. במאגרי צמתים מסוג Z4M, ‏GKE מפעיל את DRANET כברירת מחדל, כך שלא צריך לציין את תווית הצומת cloud.google.com/gke-networking-dra-driver=true כשיוצרים את מאגר הצמתים. בדוגמה הזו משתמשים בסוג המכונה z4m-highmem-192, שיש לה שני כרטיסי רשת פיזיים מסוג Titanium ושני ממשקי RDMA. רשימת סוגי המכונות הנתמכים מפורטת בקטע דרישות.

gcloud container node-pools create NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --project=PROJECT_ID \
    --zone=ZONE \
    --machine-type=z4m-highmem-192 \
    --num-nodes=NUM_NODES \
    --accelerator-network-profile=auto

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

• ‫NODE_POOL_NAME: השם של מאגר הצמתים החדש.
• ‫CLUSTER_NAME: שם האשכול.
• ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
• ‫ZONE: האזור ( Google Cloud ) של מאגר הצמתים.
• ‫NUM_NODES: מספר הצמתים במאגר הצמתים. כדי לבדוק את תעבורת הנתונים של RDMA בין צמתים באמצעות הפודים לדוגמה rdma-server ו-rdma-client, צריך לציין לפחות 2.

הכנת קובץ האימג' של קונטיינר עומס העבודה שמותאם לאחסון

כדי להריץ עומסי עבודה שמשתמשים ב-Cloud RDMA בצמתים שמותאמים לאחסון, צריך להתקין קובץ אימג' של קונטיינר Rocky Linux 8 עם ספריות RDMA מותאמות אישית של מרחב המשתמש (rdma-core) ל-Cloud RDMA. אל תשתמשו בחבילות ברירת המחדל של ה-upstream, כי אין בהן את תוספי ה-ABI בהתאמה אישית שנדרשים למנהל ההתקן של ה-IRDMA המארח, והן נכשלות בזמן הריצה עם שגיאות -ENOSPC. כדי לאמת את הקצאות כתובות ה-IP ולבדוק את הקישוריות של RDMA, צריך להתקין גם את iproute,‏ libibverbs-utils,‏ librdmacm-utils,‏ infiniband-diags ו-perftest.

בקטע הכנת קובץ האימג' של Docker מופיעה דוגמה ל-Dockerfile שמגדיר את Package Repository הנדרש. בפקודה dnf install, כוללים את iproute כדי שתוכלו לבדוק את הקצאות ה-IP באמצעות הפקודה ip. למידע נוסף על החבילות הנדרשות, ראו Cloud RDMA RPMs.

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

כדי להקצות ממשקי RDMA ל-Pod בצומת שעבר אופטימיזציה לאחסון, יוצרים ResourceClaimTemplate שמבקש את irdma.google.com DeviceClass:

1. יוצרים מניפסט של ResourceClaimTemplate ושומרים אותו בשם irdma-template.yaml:

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

   במניפסט הזה:

   • ‫deviceClassName: irdma.google.com: בקשות לממשקי רשת IRDMA שמנוהלים על ידי GKE DRANET בצמתים שעברו אופטימיזציה לאחסון.
   • ‫allocationMode: ExactCount ו-count: 2: בקשה לשני ממשקי ה-IRDMA שזמינים בצומת z4m-highmem-192. אם לעומס העבודה נדרש רק ממשק RDMA אחד, או אם אתם משתמשים בסוג מכונה Z4M שמספק ממשק IRDMA אחד, ציינו 1.

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

   kubectl apply -f irdma-template.yaml
   

3. יוצרים מניפסט שמגדיר שני Pods, ‏ rdma-server ו-rdma-client, כדי שתוכלו לבדוק את תעבורת הנתונים של RDMA בין הצמתים. כל Pod מוסיף את היכולת IPC_LOCK ומפנה אל irdma-template ResourceClaimTemplate. שומרים את המניפסט בתור irdma-pods.yaml:

   apiVersion: v1
   kind: Pod
   metadata:
     name: rdma-server
     labels:
       app: perftest
       role: server
   spec:
     restartPolicy: Never
     affinity:
       podAntiAffinity:
         requiredDuringSchedulingIgnoredDuringExecution:
         - labelSelector:
             matchExpressions:
             - key: app
               operator: In
               values: ["perftest"]
           topologyKey: "kubernetes.io/hostname"
     containers:
     - name: perftest
       image: IMAGE_URI
       command: ["sleep", "infinity"]
       securityContext:
         capabilities:
           add: ["IPC_LOCK"]
       resources:
         claims:
         - name: irdma
     resourceClaims:
     - name: irdma
       resourceClaimTemplateName: irdma-template
   ---
   apiVersion: v1
   kind: Pod
   metadata:
     name: rdma-client
     labels:
       app: perftest
       role: client
   spec:
     restartPolicy: Never
     affinity:
       podAntiAffinity:
         requiredDuringSchedulingIgnoredDuringExecution:
         - labelSelector:
             matchExpressions:
             - key: app
               operator: In
               values: ["perftest"]
           topologyKey: "kubernetes.io/hostname"
     containers:
     - name: perftest
       image: IMAGE_URI
       command: ["sleep", "infinity"]
       securityContext:
         capabilities:
           add: ["IPC_LOCK"]
       resources:
         claims:
         - name: irdma
     resourceClaims:
     - name: irdma
       resourceClaimTemplateName: irdma-template
   

   מחליפים את שני המופעים של IMAGE_URI ב-URI של קובץ האימג' של קונטיינר Rocky Linux 8 RDMA.

   במניפסט הזה:

   • ‫metadata.labels: מוסיף לכל Pod תווית עם app: perftest ותווית role. שני ה-Pods חולקים את התווית app: perftest, כך שכלל האנטי-אפיניות חל עליהם. התווית role מבדילה בין Pod של rdma-server (role: server) לבין Pod של rdma-client (role: client), כדי שתוכלו לבדוק את הקישוריות של RDMA בין Pod ל-Pod בצמתים שונים.
   • ‫affinity.podAntiAffinity: מונע מ-Kubernetes לתזמן Pods שחולקים את התווית app: perftest באותו צומת. מכיוון שלשני ה-Pods יש את התווית הזו, הם פועלים במארחים פיזיים נפרדים לבדיקת RDMA בין צמתים, גם כש-ResourceClaimTemplate מבקש רק ממשק אחד (count: 1). למאגר הצמתים צריכים להיות לפחות שני צמתים כדי לתזמן את שני ה-Pods.
   • ‫securityContext.capabilities.add: ["IPC_LOCK"]: מאפשר למאגר לנעול דפי זיכרון, שנדרשים לספריות של מרחב המשתמשים של RDMA כדי לרשום אזורי זיכרון לגישה ישירה לזיכרון.
   • ‫spec.resourceClaims: יוצר ResourceClaim ספציפי ל-Pod (בשם irdma) מ-irdma-template ResourceClaimTemplate.
   • ‫containers.resources.claims: מעניקה לקונטיינר perftest גישה לממשקים שהוקצו על ידי ההצהרה irdma.

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

   kubectl apply -f irdma-pods.yaml
   

5. מוודאים שממשקי ה-RDMA שהוקצו (rdma0 ו-rdma1) גלויים בתוך ה-Pod של השרת:

   kubectl exec rdma-server -- ip -br addr show
   

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

   lo               UNKNOWN        127.0.0.1/8
   rdma1            UP             10.5.0.3/32
   rdma0            UP             10.31.0.3/32
   eth0@if18        UP             10.120.2.6/32
   

כדי לאמת את תעבורת הנתונים של RDMA בין שני ה-Pods, מריצים את rping בין rdma-server ל-rdma-client:

1. מפעילים את שרת rping ב-Pod של השרת:

   kubectl exec -it rdma-server -- rping -s -a RDMA_IP -v -d
   

   מחליפים את RDMA_IP בכתובת ה-IP של rdma0 או rdma1 של ה-Pod של השרת, למשל 10.31.0.3.

2. במסוף שני, מריצים את הלקוח rping ב-Pod של הלקוח:

   kubectl exec -it rdma-client -- rping -c -a RDMA_IP -C 5 -v -d
   

   בפלט של הלקוח, בודקים את האינדיקטורים הבאים לחיבור RDMA תקין:

   • ‫RDMA_CM_EVENT_ADDR_RESOLVED ו-RDMA_CM_EVENT_ROUTE_RESOLVED: מאשרים שמנהל התקשורת של RDMA פתר את כתובת ה-IP והמסלול של RDMA.
   • ‫ESTABLISHED ו-rdma_connect successful: אישור שהלקוח יצר את צמד התורים (qp), את תור ההשלמה (cq) ואת דומיין ההגנה (pd), ושהוא יצר את חיבור ה-RDMA.
   • חמש רשומות של send completion,‏ recv completion ו-ping data: rdma-ping-: מאשרות שחמש איטרציות של קריאה וכתיבה של RDMA הלוך ושוב הושלמו בממשק ה-RDMA לפני סגירת החיבור (destroy cm_id).

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

כדי להשתמש ב-DRANET בניהול GKE באשכולות Autopilot או עם הקצאת צמתים אוטומטית (NAP) באשכולות 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
       # Omit the gpu section for storage-optimized VMs (such as Z4M).
       gpu:
         count: GPU_COUNT
         type: GPU_TYPE
       acceleratorNetworkProfile: auto
   

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

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

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

   kubectl apply -f COMPUTE_CLASS_FILENAME.yaml
   

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

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

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

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

בדוגמה הבאה נשלחת בקשה לשני התקני רשת 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

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

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