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

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

Standard

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

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

למה כדאי להשתמש בפריסה דינמית עם מתזמן מותאם אישית?

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

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

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

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

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

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

דרישות

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

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

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

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

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

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

הפעלת בקר הפרוסות

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

מעדכנים את האשכול:
```
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 שלכם למאגרי צמתים של קבוצת 16 צמתים של TPU VM, או בלוקים משניים. ‫GKE מקצה את מאגרי הצמתים האלה גם אם הוא לא מצליח למצוא את כל 16 המכונות הווירטואליות התקינות, על ידי הצבת צמתים בחלקים תקינים של המכונה המארחת והקצאה מצטברת של מכונות לא תקינות בזמן שהן מתוקנות.

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

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

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

כדי ליצור מאגר צמתים של חלקי 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.

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

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

טירגוט של בלוק: כל מאגר צמתים משתמש בקיבולת מבלוק ספציפי. ‫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 כדי ליצור פרוסה דינמית גדולה יותר או פרוסת משנה דינמית קטנה יותר. משאב בהתאמה אישית מסוג Slice מגדיר את הטופולוגיה שצוינה, שהבקר של ה-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. כדי להשתמש בטופולוגיות הקטנות יותר, צריך להשתמש בגרסה 1.36.0-gke.3712000 ואילך של GKE.
  - לפילוח דינמי מתקדם: אפשר לציין טופולוגיות ששווה ל-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 (חלוקה דינמית לפרוסות-על), צריך לספק ארבעה מזהי מחיצות ייחודיים.
```
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: אם המשאב המותאם אישית של הפרוסה נמחק או אם מתרחשת תקלה קריטית במצב פעיל או במצב של תקלה, הפרוסה מתחילה להתפרק.
‫INCOMPLETE: השלב האחרון לפני שהמשאב נמחק לחלוטין.

תנאי סטטוס לשימוש בטכניקת Super-slicing דינמית

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

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

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

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

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

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

שומרים את קובץ המניפסט לדוגמה הבא בשם 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 ואילך. כדי להשתמש ב-dynamic super-slicing, צריך להשתמש ב-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
```

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

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

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

אם אתם משתמשים ב-dynamic super-slicing, מחקו את הפרוסות הפעילות לפני שתבצעו תחזוקה ידנית:
```
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

מחיקת הפלח

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

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

השבתת בקר הפרוסות

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

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