‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

שימוש בחלוקה דינמית עם מתזמן מותאם אישית

רגילה

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

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

למה כדאי להשתמש בחלוקה דינמית עם מתזמן מותאם אישית?

אם יש לכם דרישות מורכבות לתזמון או אם אתם רוצים לשלב חלוקה דינמית עם תשתית התזמון הקיימת שלכם, אתם יכולים להשתמש בכלי תזמון משלכם כדי לנהל משאבים מותאמים אישית של Slice.

אם אתם מעדיפים להשתמש בכלי לתזמון במקום לנהל ישירות משאבים מותאמים אישית של Slice, ‏ GKE מספק שילוב עם Kueue ועם Topology Aware Scheduling‏ (TAS). מידע נוסף זמין במאמר בנושא תזמון פילוחים דינמיים באמצעות Kueue ו-TAS.

סקירה כללית של תהליך העבודה

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

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

מידע נוסף על השדות והסטטוס של המשאב המותאם אישית Slice זמין במאמר בנושא המשאב המותאם אישית Slice.

דרישות

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

משתמשים באשכול Standard בערוץ מהיר באחת מהגרסאות הבאות:
- כדי להגדיר חלוקה דינמית של סופר-סלייס (טופולוגיות ששווה ל-4x4x4 או גדולות ממנו), צריך להשתמש בגרסה 1.35.2-gke.1842000 ואילך.
- כדי להגדיר חלוקה דינמית למקטעי משנה (טופולוגיות קטנות מ-4x4x4), צריך להשתמש בגרסה 1.36.0-gke.3712000 ואילך.
שימוש בגרסת Ironwood‏ (TPU7x).
משתמשים בקובץ אימג' של מערכת הפעלה שמותאמת לקונטיינרים עבור הצמתים.
כדי להשתמש בהקצאת משאבים מצטברת, צריך להשתמש בהזמנות במצב 'כל הקיבולת'. כל מצב הקיבולת הוא תכונה שמופעלת על ידי TPU Cluster Director.
כדי להשתמש בחלוקת משנה דינמית, צריך לוודא שיש בצמתים אירועי תחזוקה בהמתנה. מעקב אחר אירועי תחזוקה בהמתנה במכונות שלכם. אם יש לכם צמתים עם אירוע תחזוקה בהמתנה שזמן הסיום שלו הוא בין 18 בספטמבר 2026 ל-30 בספטמבר 2026, תצטרכו להפעיל ידנית את אירוע התחזוקה של המארח בצמתים האלה כדי שתוכלו להשתמש בחלוקת משנה.

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

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

מפעילים את ממשק Google Kubernetes Engine API.

הפעלת 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. יכול להיות שתצטרכו לציין את המיקום בפקודות מסוימות אם המיקום של האשכול שונה מברירת המחדל שהגדרתם.

מוודאים שיש לכם אשכול קיים מסוג Standard בגרסה 1.35.2-gke.1842000 ואילך, בערוץ מהיר. כדי ליצור אשכול חדש, אפשר לעיין במאמר בנושא יצירת אשכול אזורי.
מוודאים שיש לכם מספיק מכסת שימוש ב-Ironwood ‏ (TPU7x) באזור שלכם.
אם אתם מתכננים להריץ עומסי עבודה של multislice, תצטרכו להתקין את JobSet בגרסה 0.10.1 ואילך.
בקשה לקיבולת TPU במצב 'כל הקיבולת'.

הפעלת אמצעי הבקרה של התבנית

כדי להשתמש בפילוח דינמי, צריך להפעיל את בקר הפילוח באשכול.

מעדכנים את האשכול:
```
gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --enable-slice-controller
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫CLUSTER_NAME: השם של האשכול.
- ‫LOCATION: האזור שבו נמצא קיבולת ה-TPU הזמינה.

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

gcloud config set container/cluster CLUSTER_NAME
gcloud container clusters get-credentials CLUSTER_NAME \
    --location=LOCATION

בפלט של הפקודה הבאה, מוודאים שהערך slices.accelerator.gke.io מופיע:
```
kubectl get crd slices.accelerator.gke.io
```
הפלט אמור להיראות כך:
```
slices.accelerator.gke.io                2026-01-09T23:58:02Z
```

יצירת מאגרי צמתים עם הקצאת משאבים מצטברת

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

אתם יכולים לטרגט את מאגר הצמתים כך שישתייך לאחת מהקטגוריות הבאות:

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

יצירת מדיניות של עומס עבודה

כדי ליצור מאגר צמתים של פרוסת TPU עם Ironwood‏ (TPU7x), קודם צריך ליצור מדיניות של עומס עבודה עם השדה accelerator-topology-mode שמוגדר לערך provision_only. ההגדרה הזו מפעילה את תהליך ההקצאה המצטבר.

יוצרים מדיניות לעומסי עבודה:

gcloud compute resource-policies create workload-policy WORKLOAD_POLICY_NAME \
        --project=PROJECT_ID \
        --region=REGION  \
        --type=HIGH_THROUGHPUT \
        --accelerator-topology=4x4x4 \
        --accelerator-topology-mode=provision_only

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

‫WORKLOAD_POLICY_NAME: שם למדיניות של עומס העבודה.
‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
‫REGION: האזור של מדיניות עומס העבודה.

בפקודה הזו, מבצעים את הפעולות הבאות:

תמיד מגדירים את השדה accelerator-topology לערך 4x4x4 כדי להתאים למספר הכולל של הצ'יפים בתוך בלוק משנה יחיד.
כדי להפעיל את תהליך ההקצאה המצטבר, צריך תמיד להגדיר את השדה accelerator-topology-mode לערך provision_only. כשמגדירים את השדה provision_only, מאגר הצמתים מספק צמתי TPU בלי ליצור קישורי ICI או OCS.

טירגוט מאגר הצמתים כך שישתייך לבלוק או לתת-בלוק

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

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

חסימה

כדי לאחזר את השם של הבלוק בהזמנה ואת מספר תתי הבלוקים הזמינים בבלוק, צריך לבצע את השלבים הבאים במסמך View the topology and health status of All Capacity Mode reservations:
1. מזהים את שם הבלוק על ידי הצגת רשימה של כל בלוקי ההזמנות והעתקת הערך בשדה name:. הערך הזה הוא שם הבלוק או BLOCK_NAME במסמך הזה.
2. כדי לקבוע כמה מאגרי צמתים צריך ליצור, מתארים בלוק של הזמנה ומזהים את הערך בשדה reservationSubBlockCount. הערך הזה הוא מספר תתי-הבלוקים הזמינים. לדוגמה, הערך reservationSubBlockCount: 4 מציין שיש ארבעה בלוקים משניים זמינים בבלוק, וצריך ליצור ארבעה מאגרי צמתים נפרדים.
מגדירים את נתיב ההזמנה:
```
export RESERVATION_PATH="projects/PROJECT_ID/reservations/RESERVATION_NAME/reservationBlocks/BLOCK_NAME"
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫RESERVATION_NAME: השם של הזמנת ה-TPU.
- ‫BLOCK_NAME: השם של הבלוק.
יוצרים מאגר צמתים לכל תת-בלוק שזוהה בשלב הקודם. לדוגמה, אם המספר הוא 4, מריצים את הפקודה הזו ארבע פעמים. צריך להשתמש בשם ייחודי לכל מאגר צמתים.
```
gcloud container node-pools create NODE_POOL_NAME \
      --cluster=CLUSTER_NAME \
      --node-locations=ZONE \
      --machine-type=tpu7x-standard-4t \
      --num-nodes=16 \
      --placement-policy=WORKLOAD_POLICY_NAME \
      --reservation-affinity=specific \
      --reservation=${RESERVATION_PATH}
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫NODE_POOL_NAME: השם של מאגר הצמתים החדש.
- ‫CLUSTER_NAME: השם של אשכול GKE.
- ‫WORKLOAD_POLICY_NAME: השם של מדיניות עומס העבודה שיצרתם.
- ‫ZONE: האזור של מאגר הצמתים, לדוגמה, us-central1-a.

Sub-block

כדי לאחזר את השם של הבלוק ואת המזהים של תתי הבלוקים הזמינים, צריך לבצע את השלבים הבאים במסמך View the topology and health status of All Capacity Mode reservations (הצגת הטופולוגיה וסטטוס התקינות של כל ההזמנות במצב קיבולת):
1. כדי לזהות את השם של הבלוק, מציגים רשימה של כל בלוקי ההזמנות ומעתיקים את הערך בשדה name:. הערך הזה הוא השם של הבלוק או של BLOCK_NAME במסמך הזה.
2. כדי לזהות את השם של תת-הבלוקים, צריך לרשום את כל תת-הבלוקים של בלוק ולהעתיק את הערך בשדה name: לכל רשומה בקטע reservationSubBlocks. הערך הזה הוא השם של בלוק המשנה או SUBBLOCK_NAME במסמך הזה.
מגדירים את נתיב ההזמנה:
```
export RESERVATION_PATH="projects/PROJECT_ID/reservations/RESERVATION_NAME/reservationBlocks/BLOCK_NAME/reservationSubBlocks/SUBBLOCK_NAME"
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫RESERVATION_NAME: השם של הזמנת ה-TPU.
- ‫BLOCK_NAME: השם של הבלוק.
- ‫SUBBLOCK_NAME: השם של בלוק המשנה.
יוצרים את מאגר הצמתים:
```
gcloud container node-pools create NODE_POOL_NAME \
        --project=PROJECT_ID \
        --cluster=CLUSTER_NAME \
        --node-locations=ZONE \
        --machine-type=tpu7x-standard-4t \
        --num-nodes=16 \
        --placement-policy=WORKLOAD_POLICY_NAME \
        --reservation-affinity=specific \
        --reservation=${RESERVATION_PATH}
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫NODE_POOL_NAME: שם ייחודי למאגר הצמתים החדש, לדוגמה, sub-block-pool-1.
- ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
- ‫CLUSTER_NAME: השם של אשכול GKE.
- ‫ZONE: האזור של מאגר הצמתים, לדוגמה, us-central2-b.
- WORKLOAD_POLICY_NAME: השם של מדיניות העומס שיצרתם.

בשלב הזה, הצמתים נוצרים, אבל הקישורים שלהם ל-Inter-Chip Interconnect (ICI) עדיין לא פעילים. לכן, אי אפשר להריץ עומסי עבודה במאגרי הצמתים האלה באופן ישיר.

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

יוצרים משאב מותאם אישית של Slice. במקום Pods, משתמשים במשאב מותאם אישית מסוג Slice כדי להגדיר את הטופולוגיה שצוינה, והבקר של ה-Slice מפעיל אותה.
תזמון עומסי עבודה ב-GKE באמצעות Kueue ו-TAS. ‫Kueue מטפל אוטומטית ביצירה ובמחיקה של משאבים מותאמים אישית מסוג Slice. מומלץ להימנע משינוי ידני של משאבים מותאמים אישית של Slice שנוצרו על ידי Kueue.

יצירת פלח דינמי באמצעות פילוח-על או פילוח משנה

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

חלוקה דינמית של נתחים

המחיצות מספקות את הטופולוגיות שזמינות ליצירת פלח דינמי לעומסי העבודה. במחיצה מוצגות כל הטופולוגיות הזמינות לכל צומת, כולל 2x2x1,‏ 2x2x2,‏ 2x2x4,‏ 2x4x4 ו-4x4x4. טופולוגיות קטנות מ-4x4x4 דורשות GKE בגרסה ‎1.36.0-gke.3712000 ואילך.

לכל פלח שגדול מ-4x4x4 אין תווית מחיצה, כי הוא נוצר על ידי שיוך של כמה מחיצות של 4x4x4.

לכל צומת TPU במאגר צמתים עם הקצאת משאבים מצטברת צריך להיות כל מזהה מחיצה שצוין ותווית צומת של מצב המחיצה.

אימות הסטטוס של הצמתים והמחיצות

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

kubectl get nodes -l cloud.google.com/gke-nodepool=${NODE_POOL_NAME}

התוצאה אמורה להיראות כך:

NAME                                 STATUS   ROLES    AGE    VERSION
gke-np-status-update-7b4c890c-0jhp   Ready    <none>   2d1h   v1.35.1-gke.1396002
gke-np-status-update-7b4c890c-377r   Ready    <none>   2d1h   v1.35.1-gke.1396002
gke-np-status-update-7b4c890c-gb51   Ready    <none>   2d1h   v1.35.1-gke.1396002

בודקים את מודל ההקצאה של הצומת:

kubectl describe node NODE_NAME | grep "cloud.google.com/gke-accelerator-topology-mode"

התוצאה אמורה להיראות כך:

cloud.google.com/gke-accelerator-topology-mode: PROVISION_ONLY

מאחזרים את פרטי התווית של הצומת עבור מחיצת הטופולוגיה שרוצים לטרגט:

kubectl describe node NODE_NAME | grep -E "cloud.google.com/gke-tpu-partition-.*-id"

מחליפים את NODE_NAME בשם של אחד מהצמתים במאגר הצמתים.

התוצאה אמורה להיראות כך:

cloud.google.com/gke-tpu-partition-4x4x4-id=fba785f80d18552357dcdef6d3d16c27
cloud.google.com/gke-tpu-partition-2x4x4-id=e18372d627ac412cb24d5ea8ab8912c9
cloud.google.com/gke-tpu-partition-2x2x4-id=7fbd4e29dc1839217fae41a9dd8211b4
cloud.google.com/gke-tpu-partition-2x2x2-id=a9476d1b02bd4f4e75ffffae3bd23c01
cloud.google.com/gke-tpu-partition-2x2x1-id=0bcfe937d1bb3914a8bdcd94e9f73319

מוודאים שהצומת כולל את ההערה node.gke.io/created-by-mig:
```
kubectl describe node NODE_NAME | grep "node.gke.io/created-by-mig"
```
מחליפים את NODE_NAME בשם של אחד מהצמתים במאגר הצמתים.

התוצאה אמורה להיראות כך:
```
node.gke.io/created-by-mig: projects/735972712744/zones/us-central1-ai1a/team/string
```
הפלט כולל את ההערה node.gke.io/created-by-mig, שמאפשרת למישור הבקרה של GKE לקשר בין צמתי Kubernetes לבין משאבי Compute Engine הבסיסיים שלהם.
מאחזרים את פרטי התווית של הצומת עבור מצב מחיצת הטופולוגיה שרוצים לאמת:
```
kubectl describe node NODE_NAME | grep -E "cloud.google.com/gke-tpu-partition-.*-state"
```
התוצאה אמורה להיראות כך:
```
cloud.google.com/gke-tpu-partition-4x4x4-state=HEALTHY
cloud.google.com/gke-tpu-partition-2x4x4-state=HEALTHY
cloud.google.com/gke-tpu-partition-2x2x4-state=HEALTHY
cloud.google.com/gke-tpu-partition-2x2x2-state=HEALTHY
cloud.google.com/gke-tpu-partition-2x2x1-state=HEALTHY
```
התווית cloud.google.com/gke-tpu-partition-[shape]-state (כאשר [shape] תואמת לטופולוגיה של מזהה המחיצה) מציינת אם המחיצה זמינה ליצירת פלח דינמי. בתווית המדינה הזו אפשר להשתמש בערכים הבאים:
- ‫HEALTHY: המחיצה תקינה ופועלת באופן מלא.
- ‫DEGRADED: המחיצה פגומה אבל עדיין אפשר להשתמש בה ליצירת פרוסות דינמיות. הסטטוס הזה רלוונטי רק לטופולוגיה 4x4x4 ברמה העליונה. בטופולוגיות קטנות יותר אין מצב של ירידה ברמת השירות.
- ‫UNHEALTHY: המחיצה לא תקינה ואי אפשר להשתמש בה כדי ליצור פרוסה.
- ‫UNSET: המצב לא מוגדר בגלל אתחול לא מוצלח של בקר הפרוסות של GKE.
- ‫INCOMPLETE: לא כל הצמתים במחיצה הוקצו.

יצירת משאב מותאם אישית של Slice

יש הבדלים קלים בין משאב ה-Slice המותאם אישית שיוצרים כשמגדירים super-slice דינמי לבין משאב ה-Slice המותאם אישית שיוצרים כשמגדירים sub-slice דינמי.

מגדירים את המשאב המותאם אישית Slice:
```
apiVersion: accelerator.gke.io/v1beta1
kind: Slice
metadata:
  # Name of the slice resource
  name: SLICE_NAME
spec:
  # Specify the type of accelerator for this slice
  type: "tpu7x"
  # Define the desired topology for the accelerator slice
  topology: TOPOLOGY
  partitionIds:
    - PARTITION_ID # Example: a9476d1b02bd4f4e75ffffae3bd23c01
    - PARTITION_ID_2
    # ... add more partition IDs as needed
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫SLICE_NAME: שם לפרוסה. השם צריך לעמוד בתנאים של metadata.name ולהיות באורך של עד 49 תווים.
- ‫TOPOLOGY: הטופולוגיה של הפרוסה הדינמית. הטופולוגיה צריכה לעמוד בתנאים הבאים:
  - לפילוח דינמי של רשתות משנה: אפשר לציין טופולוגיות קטנות יותר מ-4x4x4, כמו 2x2x1, ‏2x2x2, ‏2x2x4 או 2x4x4. כדי להשתמש בטופולוגיות הקטנות האלה, צריך GKE בגרסה ‎1.36.0-gke.3712000 ואילך.
  - לפילוח דינמי מתקדם: אפשר לציין טופולוגיות ששווות ל-4x4x4 או גדולות ממנו. כדי להגדיר חלוקה דינמית, כל מאפיין בטופולוגיה המבוקשת צריך להיות כפולה של ארבע, לדוגמה 4A x 4B x 4C. שלושת הערכים במאפייני הטופולוגיה, AxBxC, צריכים להיות בסדר לא יורד (A ≤ B ≤ C). לדוגמה, 4x4x8 הוא ערך תקין, אבל 4x8x4 הוא לא. הסדר הזה עוזר להבטיח יצירה עקבית של פלחים ולמנוע התנהגות לא צפויה. המכפלה של שלושת הערכים במאפייני המימדים של הטופולוגיה, A × B × C, לא יכולה להיות גדולה מ-9,216.
- ‫PARTITION_ID: רשימה של מחרוזות שמזהות את המחיצות שמרכיבות את הפרוסה.
  - לפילוח דינמי של נתונים: צריך לציין מזהה מחיצה אחד בלבד.
  - לפילוח דינמי: צריך לחשב את מספר המחיצות על סמך המספר הכולל של השבבים, כאשר כל מחיצה מורכבת מ-64 שבבים. מספר הפריטים ברשימה spec.partitionIds צריך להיות זהה למספר המחיצות המחושב ((A × B × C) / 64).
  - הרשימה partitionIds צריכה לעמוד בתנאים הבאים:
    - כל מחיצה צריכה להיות ממופה לתת-בלוק של הזמנה.
    - כל בלוקי המשנה המשויכים צריכים להיות שייכים לאותה הזמנה.
    - כל תתי-הבלוקים המשויכים צריכים להיות באותה הזמנה.
    - כל הצמתים במאגרי הצמתים המשויכים צריכים להיות במצב ready.
- הערך בשדה type חייב להיות tpu7x.
- אופציונלי: כדי לאפשר לבקר הפלחים לנסות שוב באופן אוטומטי במהלך יצירת הפלח, אפשר להוסיף את ההערה slice.gke.io/retry-on-failure: "true" למשאב המותאם אישית של הפלח. אם הפרוסה לא נוצרת בגלל סיבת הסטטוס SliceCreationFailed, הבקר ינסה שוב עד שהפרוסה תיווצר בהצלחה.
לדוגמה, כדי ליצור 4x8x8פלח (dynamic super-slicing), צריך לספק ארבעה מזהי מחיצות ייחודיים.
```
apiVersion: accelerator.gke.io/v1beta1
kind: Slice
metadata:
    name: test-super-slice-example
    annotations:
      slice.gke.io/retry-on-failure: "true"
spec:
    type: "tpu7x"
    topology: "4x8x8" # (4*8*8)/64 = 4 partitions
    partitionIds:
        - "p0-4x4x4"
        - "p1-4x4x4"
        - "p2-4x4x4"
        - "p3-4x4x4"
```
לדוגמה, כדי ליצור 2x2x2פלח (חלוקת משנה דינמית), צריך לספק מזהה מחיצה ייחודי אחד.
```
apiVersion: accelerator.gke.io/v1beta1
kind: Slice
metadata:
  name: test-sub-slice-example
  annotations:
      slice.gke.io/retry-on-failure: "true"
spec:
  type: "tpu7x"
  topology: "2x2x2"
  partitionIds:
    - "fba785f80d18552357dcdef6d3d16c27" # Only 1 partitionId for sub-slice
```
מחילים את משאב ה-Slice המותאם אישית:
```
kubectl apply -f test-slice-example.yaml
```
בשלב הזה, GKE מנסה ליצור את הפרוסה. אם מתרחשת אחת מהבעיות הבאות, יצירת הפרופיל נכשלת, והסיבה לסטטוס במשאב המותאם אישית Slice מתעדכנת ל-SliceCreationFailed או ל-FAILED:
- אם הצמתים שנבחרו במשאב המותאם אישית לא קיימים, הסיבה למצב היא SliceCreationFailed.
- אם צמתים במשאב המותאם אישית נמצאים בשימוש של פרוסה אחרת, סיבת הסטטוס היא SliceCreationFailed.
- אם הצמתים במשאב המותאם אישית לא שייכים לאותו תת-בלוק של הזמנה, סיבת הסטטוס היא FAILED.
- אם הצמתים לא נמצאים באותה הזמנה, הסיבה לסטטוס היא FAILED.
- אם הטופולוגיה לא תואמת למספר המחיצות, הסיבה לסטטוס היא SliceCreationFailed.
כדי לנסות ליצור את הפרוסה מחדש באופן אוטומטי כשהסטטוס הוא SliceCreationFailed, צריך להגדיר את ההערה slice.gke.io/retry-on-failure: "true" כמו שמתואר במאמר יצירת משאב מותאם אישית של Slice.

מידע נוסף על הסטטוס של המשאב המותאם אישית Slice זמין במאמר סטטוס Slice.

מעקב אחרי הסטטוס של משאב בהתאמה אישית מסוג Slice

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

kubectl describe slice SLICE_NAME

מחליפים את SLICE_NAME בשם הפרוסה.

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

Name:         test-slice
Namespace:
Labels:       <none>
Annotations:  <none>
API Version:  accelerator.gke.io/v1beta1
Kind:         Slice
Metadata:
  Creation Timestamp:  2026-01-11T23:45:15Z
  Finalizers:
    accelerator.gke.io/slice-finalizer
  Generation:        1
  Resource Version:  1768175347356335006
  UID:               d0b71e5c-be3f-4788-aead-930c7afec4f2
Spec:
  Partition Ids:
    2c79463990ff67c4e3c2648666bfedfa
    ba898ffcac0ad0946e8ff036d771ee53
    [more partition IDs]
  Topology:  8x16x16
  Type:      tpu7x
Status:
  Conditions:
    Last Transition Time:  2026-01-11T23:45:38Z
    Message:               ""
    
    Reason:                FAILED
    
    Status:                False
    Type:                  Ready
Events:

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

תנאי סטטוס לפילוח משנה דינמי

‫SliceNotCreated: בקר המדיניות מבצע אתחול ובדיקות של משאבים.
- אם לא מתקיימות הדרישות המוקדמות, המצב משתנה לSliceCreationFailed.
- אם האימות עובר בהצלחה, המצב משתנה לACTIVATING.
‫ACTIVATING: פרוסת ה-GKE נוצרת.
- אם הפעולה תצליח, המצב ישתנה ל-ACTIVE.
- אם יש ירידה ברמת השירות של תת-בלוקים אבל הפרוסה ניתנת לשימוש, המצב משתנה ל-ACTIVE_DEGRADED.
- אם ההקמה נכשלת, המצב משתנה לFAILED.
‫DEACTIVATING: אם משאב מותאם אישית מסוג Slice נמחק או אם מתרחש כשל קריטי במצב פעיל או במצב של כשל, מתחיל פירוק של ה-Slice.
‫INCOMPLETE: השלב האחרון לפני שהמשאב נמחק לחלוטין.

תנאי סטטוס לשימוש בטכניקת חיתוך דינמי של נתונים

‫SliceNotCreated: הפלח עדיין לא נוצר. הבקר של הפלח עובר אתחול ומבצע בדיקות לפני יצירת הפלח.
‫SliceCreationFailed: היצירה נכשלה כי לא התקיימו התנאים המוקדמים (לדוגמה, חסרים משאבים נדרשים של Compute Engine) או כי בדיקות לפני הפעלה נכשלו. כדי לנסות שוב ליצור פרוסות באופן אוטומטי במצב הזה, מגדירים את ההערה slice.gke.io/retry-on-failure: "true".
‫ACTIVATING: הפרוסה נמצאת בתהליך של יצירה (איחוי).
‫ACTIVE: הפרוסה נוצרה במלואה, תקינה ומוכנה להרצת עומסי עבודה.
‫ACTIVE_DEGRADED: הפרוסה נוצרת אבל כוללת קוביות באיכות ירודה, שנתמכות על ידי עמידות ICI. אפשר להפעיל עומסי עבודה, אבל יכול להיות שהביצועים ייפגעו. החלוקה הדינמית של ערוץ התקשורת עמידה בפני כשלים במתג אופטי יחיד (OCS). אם יחידת OCS אחת נכשלת, כל הקישורים האופטיים שעוברים דרך המתג הזה לא יהיו זמינים, ולכן כל הקוביות בסופר-פוד יפעלו במצב פגום.
‫DEACTIVATING: הפרוסה בתהליך של פירוק.
‫FAILED: הפרוסה כבר לא מוכנה להפעלת עומסי עבודה. המצב הזה מתרחש אם ההקמה הראשונית נכשלה או אם פרוסת רשת פעילה נתקלה בכשל קריטי בתוכנה או בחומרה.
‫INCOMPLETE: אין מספיק קוביות זמינות כדי להתחיל ביצירת חיתוך-על.

מידע נוסף על הסטטוס של המשאב המותאם אישית Slice זמין במאמר סטטוס Slice.

הפעלת עומסי עבודה בחלוקה דינמית

כשמשאב מותאם אישית מסוג Slice נמצא במצב ACTIVE, אפשר להריץ עליו עומסי עבודה. בקטע הבא יש דוגמאות לעומסי עבודה שמשתמשים בחלוקה דינמית. עומסי העבודה נשלחים כ-Jobs או כ-JobSets.

דוגמה 1: עומס עבודה יחיד משתמש בפרוסה יחידה

בדוגמה הבאה מוצגת עומס עבודה שמשתמש ב-4x4x4 דינמי יחיד.

שומרים את קובץ המניפסט לדוגמה הבא בשם tpu-job-jax-v7x-64.yaml:

# Copyright 2026 Google LLC
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#      http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

apiVersion: v1
kind: Service
metadata:
  name: headless-svc
spec:
  clusterIP: None
  selector:
    job-name: tpu-job-jax-v7x-64
---
apiVersion: batch/v1
kind: Job
metadata:
  name: tpu-job-jax-v7x-64
spec:
  backoffLimit: 0
  completions: 16
  parallelism: 16
  completionMode: Indexed
  template:
    metadata:
      annotations:
        cloud.google.com/gke-tpu-slice-topology: 4x4x4
    spec:
      nodeSelector:
        cloud.google.com/gke-tpu-topology: 4x4x4
        cloud.google.com/gke-tpu-accelerator: tpu7x
        cloud.google.com/gke-tpu-slice: test-slice
      subdomain: headless-svc
      restartPolicy: Never
      containers:
      - name: tpu-job-jax
        env:
        - name: TPU_ACCELERATOR_TYPE
          value: tpu7x-128
        image: python:3.12
        securityContext:
          privileged: false
        command:
        - bash
        - -c
        - |
          set -ex
          pip install -U --pre jax jaxlib libtpu requests -i https://us-python.pkg.dev/ml-oss-artifacts-published/jax/simple/ -f https://storage.googleapis.com/jax-releases/libtpu_releases.html
          pip list
          python -c 'import jax; print("Total TPU devices (cores):", jax.device_count())'
        resources:
          requests:
            google.com/tpu: 4
          limits:
            google.com/tpu: 4

במניפסט הזה:

‫cloud.google.com/gke-tpu-slice-topology ו-cloud.google.com/gke-tpu-topology מגדירים את הטופולוגיה של הפלח הדינמי.
‫env.value: tpu7x-128 הוא סוג מאיץ ה-TPU והמספר הכולל של ליבות בפרוסת ה-TPU. מספר הליבות מחושב על ידי הכפלת הממדים של הטופולוגיה במספר הליבות לכל שבב. לדוגמה, בטופולוגיה 4x4x4, החישוב הוא 4 × 4 × 4 × 2 = 128, כאשר 2 הוא מספר ליבות לכל שבב עבור tpu7x (Ironwood (TPU7x)). לכן, TPU_ACCELERATOR_TYPE הוא tpu7x-128.

החלת המניפסט tpu-job-jax-v7x-64.yaml:
```
kubectl apply -f tpu-job-jax-v7x-64.yaml
```

דוגמה 2: פריסת עומס עבודה במאגרי צמתים מרובי-פרוסות באמצעות JobSet

בדוגמה הזו נראה איך פורסים עומס עבודה במאגרי צמתים עם כמה פרוסות באמצעות JobSet.

מתקינים את JobSet:
```
kubectl apply --server-side -f https://github.com/kubernetes-sigs/jobset/releases/download/JOBSET_VERSION/manifests.yaml
```
מחליפים את JOBSET_VERSION בגרסה הנדרשת של JobSet. כדי להשתמש בחלוקת משנה דינמית, צריך להשתמש ב-JobSet בגרסה 0.12.0 ואילך. כדי להשתמש בפיצול דינמי של משימות, צריך להשתמש ב-JobSet מגרסה 0.11.1 ואילך.

שומרים את קובץ המניפסט לדוגמה הבא בשם tpu-multislice-jax.yaml:

# Copyright 2026 Google LLC
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#      http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

apiVersion: jobset.x-k8s.io/v1alpha2
kind: JobSet
metadata:
  name: tpu-multislice-jax
  annotations:
    alpha.jobset.sigs.k8s.io/exclusive-topology: cloud.google.com/gke-tpu-slice
spec:
  failurePolicy:
    maxRestarts: 3
  replicatedJobs:
  - name: slice-job
    replicas: 2
    template:
      spec:
        parallelism: 16
        completions: 16
        backoffLimit: 0
        completionMode: Indexed
        template:
          metadata:
            annotations:
              # The shape of the slice
              cloud.google.com/gke-tpu-slice-topology: 4x4x4
          spec:
            hostNetwork: true
            dnsPolicy: ClusterFirstWithHostNet
            nodeSelector:
              cloud.google.com/gke-tpu-topology: 4x4x4
              cloud.google.com/gke-tpu-accelerator: tpu7x
              # IMPORTANT: Do NOT put 'cloud.google.com/gke-tpu-slice' here manually.
              # The exclusive-topology annotation handles the slice assignment automatically.
            containers:
            - name: jax-worker
              image: python:3.12
              securityContext:
                privileged: true
              ports:
              - containerPort: 8471
              command:
              - bash
              - -c
              - |
                set -ex
                pip install -U --pre jax jaxlib libtpu requests -f https://storage.googleapis.com/jax-releases/libtpu_releases.html
                # Verify JobSet injected the specific slice ID for this worker
                echo "JobSet Index: $JOB_COMPLETION_INDEX"
                python -c 'import jax; print("Total TPU devices:", jax.device_count())'
              resources:
                requests:
                  google.com/tpu: 4
                limits:
                  google.com/tpu: 4

החלת המניפסט tpu-multislice-jax.yaml:
```
kubectl apply -f tpu-multislice-jax.yaml
```
במניפסט הזה:
- השדה replicas: 2 בקטע replicatedJobs מציין ש-JobSet יוצר שני ג'ובים נפרדים, שכל אחד מהם תואם ל-TPU slice‏ 4x4x4.
- ההערה alpha.jobset.sigs.k8s.io/exclusive-topology: cloud.google.com/gke-tpu-slice עוזרת להבטיח שכל משימה תוקצה לפרוסת TPU ייחודית.
- ההערה cloud.google.com/gke-tpu-slice-topology: 4x4x4 מגדירה את הטופולוגיה של כל פרוסת נתונים דינמית.
- במקרה הזה, משתנה הסביבה TPU_ACCELERATOR_TYPE לא מוגדר באופן מפורש, כי JobSet מטפל בהקצאת הפרוסות. קוד ה-JAX מזהה באופן אוטומטי את מכשירי ה-TPU הזמינים בתוך הפרוסה שהוקצתה לו.
חשוב: אל תערכו את התווית cloud.google.com/gke-tpu-slice באופן ידני.

מחיקת הפרוסה

מחיקת הפלח:

kubectl patch slice $SLICE_NAME --type json \
  -p='[{"op": "remove", "path": "/metadata/finalizers"}]'

מוודאים שהפרוסה נמחקה:
```
kubectl get slices
```

שדרוג מאגרי הצמתים

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

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

אם אתם משתמשים בפיצול דינמי של נתונים, עליכם למחוק את הפלחים הפעילים לפני שתבצעו תחזוקה ידנית:
```
kubectl delete slice SLICE_NAME
```
אם אתם משתמשים בחלוקת משנה דינמית, אתם לא צריכים למחוק קודם את הפרוסות הפעילות. עם זאת, אם יש תת-פרוסות שנשארות פעילות במהלך השדרוג, הן ייכשלו ויעברו למצב FAILED.
מעדכנים את פרמטרי השדרוג של מאגר הצמתים:
```
gcloud container node-pools update NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --project=PROJECT_ID \
    --location=LOCATION \
    --max-surge-upgrade=0 \
    --max-unavailable-upgrade=16
```
כדי למנוע מ-GKE לנסות להקצות עוד TPU במהלך השדרוג, מוודאים שהערך בשדה --max-surge-upgrade מוגדר ל-0. מומלץ להגדיר את השדה --max-unavailable-upgrade=16 כך שניתן יהיה לשדרג בו-זמנית תת-בלוק מלא של 16 צמתים.

משדרגים את מאגר הצמתים:

gcloud container clusters upgrade CLUSTER_NAME \
    --node-pool=NODE_POOL_NAME \
    --cluster-version=CLUSTER_VERSION \
    --project=PROJECT_ID \
    --location=LOCATION

תחזוקה של חומרה וכשלים בחומרה

אם מפעילים תחזוקה שמתבצעת ביוזמת הלקוח או אם מתרחש מעבר לגיבוי (failover) של חומרה, רק הצמתים הממוקדים מושפעים ולא כל מאגר הצמתים.

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

שינוי צורה אוטומטי: GKE משנה באופן אוטומטי את הצורה של הפרוסה הדינמית הפעילה כשמתחילים תחזוקה במארח משויך.
Slice custom resource failure: the Slice custom resource transitions to a FAILED state.
תצפית של מתזמן הפעולות: מתזמן הפעולות מתבונן במצב הכשל של המשאב המותאם אישית Slice.
תהליך השינוי: המתזמן מנסה ליצור מחדש באופן אוטומטי את הגדרות הפרוסות בצמתים זמינים אחרים תקינים.

השבתת כלי הבחירה

כדי להשבית את אמצעי הבקרה של הפרוסה, מסירים אותו מהאוסף.

בודקים שהמשאבים המותאמים אישית של Slice ריקים:
```
kubectl get slice -A
```

מעדכנים את האשכול כדי להשבית את בקר הפרוסות:

gcloud container clusters update ${CLUSTER_NAME} \
    --location=${REGION} \
    --no-enable-slice-controller

מחיקת המשאב המותאם אישית של Slice :
```
kubectl delete crd slices.accelerator.gke.io
```
מוודאים שהמשאב המותאם אישית של Slice נמחק:
```
kubectl get crd | grep slices.accelerator.gke.io
```
מסירים את התוויות שנוספו על ידי הכלי לבחירת פרוסות. צריך להסיר את התוויות האלה:
- cloud.google.com/gke-tpu-slice
- cloud.google.com/gke-tpu-topology
1. כדי להסיר מצומת ספציפי, מעדכנים את שם הצומת
```
export NODE_NAME="gke-tpu-bdac9600-3bdg"
kubectl label node $NODE_NAME cloud.google.com/gke-tpu-slice- cloud.google.com/gke-tpu-slice-topology-
```
1. אם רוצים להסיר את התוויות האלה מכל צומת באשכול:
```
kubectl label nodes --all cloud.google.com/gke-tpu-slice- cloud.google.com/gke-tpu-slice-topology-
```
1. בודקים את תוויות הצמתים ומוודאים שהן ריקות:
```
export NODE_NAME="gke-tpu-bdac9600-3bdg"
kubectl describe node $NODE_NAME | grep "cloud.google.com/gke-tpu-slice"
```

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

למה כדאי להשתמש בחלוקה דינמית עם מתזמן מותאם אישית?

סקירה כללית של תהליך העבודה

דרישות

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

הפעלת אמצעי הבקרה של התבנית

יצירת מאגרי צמתים עם הקצאת משאבים מצטברת

יצירת מדיניות של עומס עבודה

טירגוט מאגר הצמתים כך שישתייך לבלוק או לתת-בלוק

חסימה

Sub-block

יצירת פלח דינמי באמצעות פילוח-על או פילוח משנה

חלוקה דינמית של נתחים

אימות הסטטוס של הצמתים והמחיצות

יצירת משאב מותאם אישית של Slice

מעקב אחרי הסטטוס של משאב בהתאמה אישית מסוג Slice

הפעלת עומסי עבודה בחלוקה דינמית

דוגמה 1: עומס עבודה יחיד משתמש בפרוסה יחידה

דוגמה 2: פריסת עומס עבודה במאגרי צמתים מרובי-פרוסות באמצעות JobSet

מחיקת הפרוסה

שדרוג מאגרי הצמתים

תחזוקה של חומרה וכשלים בחומרה

השבתת כלי הבחירה

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

שימוש בחלוקה דינמית עם מתזמן מותאם אישית