הפעלת עומס עבודה רחב היקף עם הפעלה גמישה באמצעות הקצאת משאבים בתור

טייס אוטומטי רגילה

הערה: התחלה גמישה עם הקצאת משאבים בהמתנה תומכת בדגלים חדשים שמהווים חלק מהשקת גרסת טרום-השקה (Preview) של התחלה גמישה (Flex-start).

בדף הזה מוסבר איך לבצע אופטימיזציה של הגמישות, היעילות והזמינות של יחידות GPU לחישובים עבור עומסי עבודה של AI ועיבוד באצווה בקנה מידה גדול, באמצעות התחלה גמישה (Flex-start) עם הקצאת משאבים בהמתנה, שמבוססת על Dynamic Workload Scheduler.

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

• מידע על יחידות GPU ב-GKE
• מידע על הגמישות, היעילות והזמינות של קיבולת המחשוב של מעבדי GPU ב-GKE

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

איך עובד תהליך אספקת שירות עם התחלה גמישה (Flex-start) והקצאת משאבים בהמתנה

בשיטה של הקצאת משאבים בתור עם התחלה גמישה, GKE מקצה את כל המשאבים המבוקשים בו-זמנית. התחלה גמישה (Flex-start) עם הקצאת משאבים בהמתנה משתמשת בכלים הבאים:

• התחלה גמישה עם הקצאת משאבים בהמתנה מבוססת על Dynamic Workload Scheduler בשילוב עם הגדרת משאב מותאם אישית (CRD) של בקשת הקצאת משאבים. הכלים האלה מנהלים את הקיבולת שהוקצתה על סמך המשאבים הזמינים והדרישות של עומס העבודה.
• (אופציונלי) Kueue מבצע אוטומציה של מחזור החיים של התחלה גמישה (Flex-start) עם בקשות הקצאת משאבים בהמתנה. ‫Kueue מטמיע תור של משימות ומטפל אוטומטית במחזור החיים של בקשת ההקצאה.

כדי להשתמש בהתחלה גמישה (Flex-start) עם הקצאת משאבים בהמתנה, צריך להוסיף את הדגלים --flex-start ו---enable-queued-provisioning כשיוצרים את מאגר הצמתים.

שיטה מומלצת:

כדאי להשתמש בהתחלה גמישה עם הקצאת משאבים בהמתנה לעומסי עבודה גדולים של עיבוד באצווה ו-AI, אם עומסי העבודה עומדים בקריטריונים הבאים:

• עומסי העבודה שלכם מתחילים בשעות גמישות.
• עומסי העבודה שלכם צריכים לפעול בכמה צמתים בו-זמנית.

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

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

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

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

• מוודאים שיש לכם אשכול GKE בגרסה ‎1.32.2-gke.1652000 ואילך.
• מוודאים שיש לכם מספיק מכסה של מכונות וירטואליות זמניות למכונות הווירטואליות שיוקצו.
• כדי למנוע שיבושים בעומסי עבודה, חשוב לוודא שאתם מנהלים שיבושים בעומסי עבודה שמשתמשים ב-Dynamic Workload Scheduler.
• חשוב לוודא שאתם מכירים את המגבלות של התחלה גמישה (Flex-start) עם הקצאת משאבים בהמתנה.
• כשמשתמשים באשכול Standard, צריך לוודא שיש לפחות מאגר צמתים אחד ללא התחלה גמישה (Flex-start), עם הקצאת משאבים בהמתנה מופעלת באשכול, כדי שהאשכול יפעל בצורה תקינה.

שימוש במאגרי צמתים עם התחלה גמישה (Flex-start) עם הקצאת משאבים בהמתנה

הקטע הזה רלוונטי רק לאשכולות רגילים.

אפשר להשתמש בכל אחת מהשיטות הבאות כדי לציין שהתחלה גמישה (Flex-start) עם הקצאת משאבים בהמתנה יכולה לעבוד עם מאגרי צמתים ספציפיים באשכול:

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

יצירת מאגר צמתים

כדי ליצור מאגר צמתים עם התחלה גמישה (Flex-start) ותכונת הקצאת משאבים בהמתנה (queued provisioning) באמצעות ה-CLI של gcloud:

gcloud container node-pools create NODEPOOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --enable-queued-provisioning \
    --accelerator type=GPU_TYPE,count=AMOUNT,gpu-driver-version=DRIVER_VERSION \
    --machine-type=MACHINE_TYPE \
    --flex-start \
    --enable-autoscaling  \
    --num-nodes=0   \
    --total-max-nodes TOTAL_MAX_NODES  \
    --location-policy=ANY  \
    --no-enable-autorepair

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

• NODEPOOL_NAME: השם שבוחרים למאגר הצמתים.
• ‫CLUSTER_NAME: שם האשכול.
• ‫LOCATION: האזור של Compute Engine שבו נמצא האשכול, למשל us-central1.
• ‫GPU_TYPE: סוג ה-GPU.
• ‫AMOUNT: מספר יחידות ה-GPU לצירוף לצמתים במאגר הצמתים.
• ‫DRIVER_VERSION: גרסת הדרייבר של NVIDIA להתקנה. יכול להיות אחת מהאפשרויות הבאות:
  • ‫default: התקנת גרסת ברירת המחדל של הדרייבר לגרסת GKE.
  • ‫latest: התקנת הגרסה האחרונה של מנהל ההתקן שזמינה לגרסת GKE שלכם. האפשרות זמינה רק לצמתים שמשתמשים במערכת הפעלה שמותאמת לקונטיינרים.
• ‫TOTAL_MAX_NODES: המספר המקסימלי של הצמתים שניתן להרחבה אוטומטית עבור כל מאגר הצמתים.

• ‫MACHINE_TYPE: סוג המכונה של Compute Engine עבור הצמתים.

  שיטה מומלצת:

  כדי לשפר את הביצועים והיעילות של עומסי עבודה של AI/ML, מומלץ להשתמש בסוג מכונה שעבר אופטימיזציה להאצה.

אפשר גם להשתמש בדגלים הבאים:

• ‫--node-locations=COMPUTE_ZONES: רשימה מופרדת בפסיקים של אזור אחד או יותר שבהם GKE יוצר את צומתי ה-GPU. האזורים צריכים להיות באותו אזור שבו נמצא האשכול. בוחרים אזורים שבהם יש GPU זמין.
• ‫--enable-gvnic: הדגל הזה מפעיל את gVNIC במאגרי צמתים של GPU כדי להגדיל את מהירות תעבורת הרשת.
• ‫--request-valid-for-duration: הדגל הזה מורה ל-GKE להמתין ללא הגבלת זמן עד שהבקשה ל-GPU תתמלא. אם לא מציינים את הדגל הזה, זמן ההמתנה המוגדר כברירת מחדל ל-GPU הוא עד 14 ימים. לעומת זאת, עומסי עבודה של TPU יכולים לחכות לפרק זמן לא מוגדר.

הפקודה הזו יוצרת מאגר צמתים עם ההגדרות הבאות:

• השילוב של הדגל --flex-start עם הדגל --enable-queued-provisioning מורה ל-GKE ליצור מאגר צמתים עם התחלה גמישה (Flex-start) עם הקצאת משאבים בהמתנה מופעלת, ולהוסיף את הדחייה (taint) cloud.google.com/gke-queued למאגר הצמתים.
• ב-GKE מופעלות הקצאת משאבים בהמתנה והתאמה אוטומטית של גודל האשכול.
• במאגר הצמתים אין צמתים בהתחלה.
• הדגל --no-enable-autorepair משבית תיקונים אוטומטיים, שיכולים לשבש עומסי עבודה שמופעלים בצמתים שתוקנו.

הפעלת הקצאת צמתים אוטומטית (NAP) כדי ליצור מאגרי צמתים להתחלה גמישה (Flex-start) עם הקצאת משאבים בהמתנה

אפשר להשתמש בהקצאת צמתים אוטומטית (NAP) כדי לנהל מאגרי צמתים להתחלה גמישה (Flex-start) עם הקצאת משאבים בהמתנה לאשכולות שמריצים את גרסה 1.29.2-gke.1553000 ואילך. כשמפעילים הקצאת צמתים אוטומטית (NAP), מערכת GKE יוצרת מאגרי צמתים עם המשאבים הנדרשים לעומס העבודה המשויך.

כדי להפעיל הקצאת צמתים אוטומטית (NAP), כדאי לעיין בהגדרות הבאות ולבצע את השלבים שמפורטים במאמר הגדרת מגבלות על יחידות GPU:

• כשמפעילים את התכונה, צריך לציין את המשאבים הנדרשים להתחלה גמישה (Flex-start) עם הקצאת משאבים בהמתנה. כדי לראות רשימה של resourceTypes זמינים, מריצים את הפקודה gcloud compute accelerator-types list.
• משתמשים בדגל --no-enable-autoprovisioning-autorepair כדי להשבית את התיקון האוטומטי של הצומת.
• מאפשרים ל-GKE להתקין באופן אוטומטי מנהלי התקנים של GPU בצמתי GPU שהוקצו באופן אוטומטי. מידע נוסף זמין במאמר בנושא התקנת דרייברים באמצעות הקצאת משאבים אוטומטית של צמתים עם GPU.

הפעלת עומסי עבודה של AI ושל עיבוד באצווה עם הקצאת משאבים בהמתנה

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

• התחלה גמישה (Flex-start) עם הקצאת משאבים בהמתנה למשימות עם Kueue: אפשר להשתמש בהתחלה גמישה (Flex-start) עם הקצאת משאבים בהמתנה עם Kueue כדי להפוך את מחזור החיים של בקשות הקצאת המשאבים בהמתנה לאוטומטי. ‫Kueue מטמיע תור של משימות ומנטר את הסטטוס של ההתחלה הגמישה (Flex-start) עם הקצאת משאבים בהמתנה. מערכת Kueue מחליטה מתי עבודות צריכות להמתין ומתי הן צריכות להתחיל, על סמך מכסות והיררכיה לשיתוף משאבים באופן הוגן בין צוותים.

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

שיטה מומלצת:

אפשר להשתמש ב-Kueue כדי להריץ את עומסי העבודה של אצווה ו-AI עם התחלה גמישה (Flex-start) עם הקצאת משאבים בהמתנה.

התחלה גמישה עם הקצאת משאבים בהמתנה למשימות עם Kueue

בקטעים הבאים מוסבר איך להגדיר את התכונה 'התחלה גמישה (Flex-start)' עם הקצאת משאבים בהמתנה למשימות עם Kueue:

• התחלה גמישה (Flex-start) עם הגדרה של מאגר צמתים עם הקצאת משאבים בהמתנה.
• מקום שמור והתחלה גמישה (Flex-start) עם הגדרת מאגר צמתים להקצאת משאבים בהמתנה.

בקטע הזה נעשה שימוש בדוגמאות בספרייה dws-examples ממאגר ai-on-gke. פרסמנו את הדוגמאות בספרייה dws-examples תחת רישיון Apache2.

כדי להתקין את Kueue, צריכות להיות לכם הרשאות אדמין. כדי לקבל את ההרשאות האלה, צריך לוודא שמוקצה לכם תפקיד ה-IAM‏ roles/container.admin. מידע נוסף על תפקידי IAM ב-GKE זמין במאמר יצירת מדיניות הרשאות ב-IAM.

הכנת הסביבה

1. ב-Cloud Shell, מריצים את הפקודה הבאה:

   git clone https://github.com/GoogleCloudPlatform/ai-on-gke
   cd ai-on-gke/tutorials-and-examples/workflow-orchestration/dws-examples
   

2. מתקינים את הגרסה העדכנית של Kueue באשכול:

   VERSION=KUEUE_VERSION
   kubectl apply --server-side -f https://github.com/kubernetes-sigs/kueue/releases/download/$VERSION/manifests.yaml
   

   מחליפים את KUEUE_VERSION בגרסה העדכנית של Kueue.

אם אתם משתמשים ב-Kueue בגרסה מוקדמת יותר מ-0.7.0, אתם צריכים לשנות את ההגדרה של Feature Gate ב-Kueue. לשם כך, מגדירים את Feature Gate‏ ProvisioningACC לערך true. במאמר Kueue's feature gates מופיע הסבר מפורט יותר וערכי ברירת המחדל של השערים. מידע נוסף על התקנת Kueue זמין במאמר התקנה.

פתרון בעיות בהתקנה של Kueue: אם נתקלים בשגיאות הרשאה במהלך ההתקנה, צריך לוודא שלמשתמש יש את התפקיד cluster-admin. אם נתקלתם בשגיאות מסוג 'החיבור ל-webhook נדחה' כשניסיתם ליצור תורים בהמשך המדריך הזה, ודאו את הדברים הבאים:

• ה-Pods של kueue-controller-manager פועלים באופן מלא במרחב השמות kueue-system.
• כללי חומת האש של האשכול מאפשרים תקשורת בין רמת הבקרה לבין הצומת ביציאה 8443.

יצירת משאבי Kueue להגדרה של מאגר צמתים של מתזמן עומסי עבודה דינמי בלבד

באמצעות המניפסט הבא, יוצרים תור ברמת האשכול בשם dws-cluster-queue ומרחב שמות של LocalQueue בשם dws-local-queue. משימות שמתייחסות לתור dws-cluster-queue במרחב השמות הזה משתמשות בהתחלה גמישה (Flex-start) עם הקצאת משאבים בהמתנה כדי לקבל את משאבי ה-GPU.

apiVersion: kueue.x-k8s.io/v1beta1
kind: ResourceFlavor
metadata:
  name: "default-flavor"
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: AdmissionCheck
metadata:
  name: dws-prov
spec:
  controllerName: kueue.x-k8s.io/provisioning-request
  parameters:
    apiGroup: kueue.x-k8s.io
    kind: ProvisioningRequestConfig
    name: dws-config
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: ProvisioningRequestConfig
metadata:
  name: dws-config
spec:
  provisioningClassName: queued-provisioning.gke.io
  managedResources:
    - nvidia.com/gpu
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: ClusterQueue
metadata:
  name: "dws-cluster-queue"
spec:
  namespaceSelector: {}
  resourceGroups:
    - coveredResources: ["cpu", "memory", "nvidia.com/gpu", "ephemeral-storage"]
      flavors:
        - name: "default-flavor"
          resources:
            - name: "cpu"
              nominalQuota: 1000000000 # "Infinite" quota
            - name: "memory"
              nominalQuota: 1000000000Gi # "Infinite" quota
            - name: "nvidia.com/gpu"
              nominalQuota: 1000000000 # "Infinite" quota
            - name: "ephemeral-storage"
              nominalQuota: 1000000000Ti # "Infinite" quota
  admissionChecks:
    - dws-prov
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: LocalQueue
metadata:
  namespace: "default"
  name: "dws-local-queue"
spec:
  clusterQueue: "dws-cluster-queue"
---
apiVersion: monitoring.googleapis.com/v1
kind: PodMonitoring
metadata:
  labels:
    control-plane: controller-manager
  name: controller-manager-metrics-monitor
  namespace: kueue-system
spec:
  endpoints:
    - path: /metrics
      port: 8080
      scheme: http
      interval: 30s
  selector:
    matchLabels:
      control-plane: controller-manager
---

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

פורסים את LocalQueue:

kubectl create -f ./dws-queues.yaml

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

resourceflavor.kueue.x-k8s.io/default-flavor created
admissioncheck.kueue.x-k8s.io/dws-prov created
provisioningrequestconfig.kueue.x-k8s.io/dws-config created
clusterqueue.kueue.x-k8s.io/dws-cluster-queue created
localqueue.kueue.x-k8s.io/dws-local-queue created

אם רוצים להריץ משימות שמשתמשות בהתחלה גמישה (Flex-start) עם הקצאת משאבים בהמתנה במרחבי שמות אחרים, אפשר ליצור עוד LocalQueues באמצעות התבנית הקודמת.

הפעלת המשימה

במניפסט הבא, עבודת הדוגמה משתמשת ב-flex-start עם הקצאת משאבים בהמתנה:

apiVersion: batch/v1
kind: Job
metadata:
  name: sample-job
  namespace: default
  labels:
    kueue.x-k8s.io/queue-name: dws-local-queue
  annotations:
    provreq.kueue.x-k8s.io/maxRunDurationSeconds: "600"
spec:
  parallelism: 1
  completions: 1
  suspend: true
  template:
    spec:
      nodeSelector:
        cloud.google.com/gke-nodepool: NODEPOOL_NAME
      tolerations:
        - key: "nvidia.com/gpu"
          operator: "Exists"
          effect: "NoSchedule"
      containers:
        - name: dummy-job
          image: gcr.io/k8s-staging-perf-tests/sleep:v0.0.3
          args: ["120s"]
          resources:
            requests:
              cpu: "100m"
              memory: "100Mi"
              nvidia.com/gpu: 1
            limits:
              cpu: "100m"
              memory: "100Mi"
              nvidia.com/gpu: 1
      restartPolicy: Never

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

• התווית kueue.x-k8s.io/queue-name: dws-local-queue מציינת ל-GKE ש-Kueue אחראי על תזמור העבודה הזו. התווית הזו גם מגדירה את התור שבו העבודה מתווספת.
• הדגל suspend: true אומר ל-GKE ליצור את משאב ה-Job, אבל לא לתזמן את ה-Pods עדיין. מערכת Kueue משנה את הדגל ל-false כשהצמתים מוכנים להרצת העבודה.
• ‫nodeSelector אומר ל-GKE לתזמן את העבודה רק במאגר הצמתים שצוין. הערך צריך להיות זהה לערך NODEPOOL_NAME, שהוא השם של מאגר הצמתים עם הקצאת משאבים בתור.

1. מריצים את המשימה:

   kubectl create -f ./job.yaml
   

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

   job.batch/sample-job created
   

2. כדי לבדוק את הסטטוס של המשרה:

   kubectl describe job sample-job
   

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

   Events:
     Type    Reason            Age    From                        Message
     ----    ------            ----   ----                        -------
     Normal  Suspended         5m17s  job-controller              Job suspended
     Normal  CreatedWorkload   5m17s  batch/job-kueue-controller  Created Workload: default/job-sample-job-7f173
     Normal  Started           3m27s  batch/job-kueue-controller  Admitted by clusterQueue dws-cluster-queue
     Normal  SuccessfulCreate  3m27s  job-controller              Created pod: sample-job-9qsfd
     Normal  Resumed           3m27s  job-controller              Job resumed
     Normal  Completed         12s    job-controller              Job completed
   

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

• RayJob
• ‫JobSet גרסה v0.5.2 ואילך
• ‫Kubeflow MPIJob, ‏ TFJob, ‏ PyTorchJob.
• ‫Kubernetes Pods שנמצאים בשימוש תדיר על ידי כלי תזמור של תהליכי עבודה
• אשכול מיני של Flux

מידע נוסף על התמיכה הזו זמין במאמר בנושא משתמש אצווה של Kueue.

יצירה של משאבי Kueue להגדרה של מאגר צמתים של Reservation ו-Dynamic Workload Scheduler

עם המניפסט הבא, יוצרים שני ResourceFlavors שמקושרים לשני מאגרי צמתים שונים: reservation-nodepool ו-dws-nodepool. השמות של מאגרי הצמתים האלה הם רק שמות לדוגמה. משנים את השמות האלה בהתאם להגדרות של מאגר הצמתים. בנוסף, בהגדרה ClusterQueue, משימות נכנסות מנסות להשתמש ב-reservation-nodepool, ואם אין קיבולת, המשימות האלה משתמשות ב-Dynamic Workload Scheduler כדי לקבל את משאבי ה-GPU.

apiVersion: kueue.x-k8s.io/v1beta1
kind: ResourceFlavor
metadata:
  name: "reservation"
spec:
  nodeLabels:
    cloud.google.com/gke-nodepool: "reservation-nodepool" # placeholder value
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: ResourceFlavor
metadata:
  name: "dws"
spec:
  nodeLabels:
    cloud.google.com/gke-nodepool: "dws-nodepool" # placeholder value
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: ClusterQueue
metadata:
  name: "cluster-queue"
spec:
  namespaceSelector: {} # match all.
  resourceGroups:
    - coveredResources: ["cpu", "memory", "nvidia.com/gpu"]
      flavors:
        - name: "reservation" # first we try reservation
          resources:
            - name: "cpu"
              nominalQuota: 9
            - name: "memory"
              nominalQuota: 36Gi
            - name: "nvidia.com/gpu"
              nominalQuota: 9
        - name: "dws" # if reservation is saturated we try dws
          resources:
            - name: "cpu"
              nominalQuota: 1000000000 # "Infinite" quota
            - name: "memory"
              nominalQuota: 1000000000Gi # "Infinite" quota
            - name: "nvidia.com/gpu"
              nominalQuota: 1000000000 # "Infinite" quota
  admissionChecksStrategy:
    admissionChecks:
      - name: "dws-prov"
        onFlavors: [dws]
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: LocalQueue
metadata:
  namespace: "default"
  name: "user-queue"
spec:
  clusterQueue: "cluster-queue"
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: AdmissionCheck
metadata:
  name: dws-prov
spec:
  controllerName: kueue.x-k8s.io/provisioning-request
  parameters:
    apiGroup: kueue.x-k8s.io
    kind: ProvisioningRequestConfig
    name: dws-config
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: ProvisioningRequestConfig
metadata:
  name: dws-config
spec:
  provisioningClassName: queued-provisioning.gke.io
  managedResources:
    - nvidia.com/gpu

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

מפעילים את קובץ המניפסט באמצעות הפקודה הבאה:

kubectl create -f ./dws_and_reservation.yaml

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

resourceflavor.kueue.x-k8s.io/reservation created
resourceflavor.kueue.x-k8s.io/dws created
clusterqueue.kueue.x-k8s.io/cluster-queue created
localqueue.kueue.x-k8s.io/user-queue created
admissioncheck.kueue.x-k8s.io/dws-prov created
provisioningrequestconfig.kueue.x-k8s.io/dws-config created

הפעלת המשימה

בניגוד להגדרה הקודמת, המניפסט הזה לא כולל את השדה nodeSelector כי הוא מתמלא על ידי Kueue, בהתאם לקיבולת הפנויה ב-ClusterQueue.

apiVersion: batch/v1
kind: Job
metadata:
  generateName: sample-job-
  namespace: default
  labels:
    kueue.x-k8s.io/queue-name: user-queue
  annotations:
    provreq.kueue.x-k8s.io/maxRunDurationSeconds: "600"
spec:
  parallelism: 1
  completions: 1
  suspend: true
  template:
    spec:
      tolerations:
        - key: "nvidia.com/gpu"
          operator: "Exists"
          effect: "NoSchedule"
      containers:
        - name: dummy-job
          image: gcr.io/k8s-staging-perf-tests/sleep:v0.0.3
          args: ["120s"]
          resources:
            requests:
              cpu: "100m"
              memory: "100Mi"
              nvidia.com/gpu: 1
            limits:
              cpu: "100m"
              memory: "100Mi"
              nvidia.com/gpu: 1
      restartPolicy: Never

1. מריצים את המשימה:

   kubectl create -f ./job-without-node-selector.yaml
   

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

   job.batch/sample-job-v8xwm created
   

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

פתרון בעיות

מידע נוסף על פתרון בעיות ב-Kueue זמין במאמר פתרון בעיות בבקשות הקצאה ב-Kueue.

התחלה גמישה עם הקצאת משאבים בהמתנה למשימות בלי Kueue

הגדרת אובייקט ProvisioningRequest

יוצרים בקשה דרך בקשת הקצאת הרשאות לכל משרה. התחלה גמישה (Flex-start) עם הקצאת משאבים בהמתנה לא מתחילה את ה-Pods, אלא רק מקצה את הצמתים.

1. יוצרים את קובץ המניפסט provisioning-request.yaml הבא:

   רגילה

   apiVersion: v1
   kind: PodTemplate
   metadata:
     name: POD_TEMPLATE_NAME
     namespace: NAMESPACE_NAME
     labels:
       cloud.google.com/apply-warden-policies: "true"
   template:
     spec:
       nodeSelector:
         cloud.google.com/gke-nodepool: NODEPOOL_NAME
         cloud.google.com/gke-flex-start: "true"
       tolerations:
         - key: "nvidia.com/gpu"
           operator: "Exists"
           effect: "NoSchedule"
       containers:
         - name: pi
           image: perl
           command: ["/bin/sh"]
           resources:
             limits:
               cpu: "700m"
               nvidia.com/gpu: 1
             requests:
               cpu: "700m"
               nvidia.com/gpu: 1
       restartPolicy: Never
   ---
   apiVersion: autoscaling.x-k8s.io/API_VERSION
   kind: ProvisioningRequest
   metadata:
     name: PROVISIONING_REQUEST_NAME
     namespace: NAMESPACE_NAME
   spec:
     provisioningClassName: queued-provisioning.gke.io
     parameters:
       maxRunDurationSeconds: "MAX_RUN_DURATION_SECONDS"
     podSets:
     - count: COUNT
       podTemplateRef:
         name: POD_TEMPLATE_NAME
   

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

   • ‫API_VERSION: גרסת ה-API, ‏v1 או v1beta1. מומלץ להשתמש בגרסה v1 כדי ליהנות מיציבות וגישה לתכונות העדכניות ביותר.
   • ‫NAMESPACE_NAME: השם של מרחב השמות של Kubernetes. מרחב השמות חייב להיות זהה למרחב השמות של ה-Pods.
   • ‫PROVISIONING_REQUEST_NAME: השם של ProvisioningRequest. תצטרכו להשתמש בשם הזה בהערה של ה-Pod.
   • ‫MAX_RUN_DURATION_SECONDS: אופציונלי, זמן הריצה המקסימלי של צומת בשניות, עד ברירת המחדל של שבעה ימים. למידע נוסף, ראה איך עובד תהליך ההקצאה עם התחלה גמישה (Flex-start) והקצאת משאבים בהמתנה. אי אפשר לשנות את הערך הזה אחרי יצירת הבקשה. השדה הזה זמין ב-GKE בגרסה 1.28.5-gke.1355000 ואילך.
   • ‫COUNT: מספר ה-Pods שהתבקשו. הצמתים מתוזמנים באופן אטומי בתחום אחד.
   • ‫POD_TEMPLATE_NAME: השם של PodTemplate.
   • NODEPOOL_NAME: השם שבוחרים למאגר הצמתים. מסירים אם רוצים להשתמש במאגר צמתים שהוקצה אוטומטית.

   יכול להיות ש-GKE יחיל אימותים ושינויים על ה-Pods במהלך היצירה שלהם. התווית cloud.google.com/apply-warden-policies מאפשרת ל-GKE להחיל את אותם אימותים ושינויים על אובייקטים של PodTemplate. התווית הזו נחוצה כדי ש-GKE יוכל לחשב את דרישות המשאבים של הצמתים עבור ה-Pods.

   אזהרה: השילוב של התחלה גמישה (Flex-start) עם הקצאת משאבים בהמתנה תומך רק ב-PodSetspec אחד. אם רוצים לשלב תבניות שונות של Pod, צריך להשתמש בתבנית שמבקשת את הכי הרבה משאבים. אין תמיכה בשילוב של סוגי מכונות שונים, כמו מכונות וירטואליות עם סוגים שונים של GPU.

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

   apiVersion: v1
   kind: PodTemplate
   metadata:
     name: POD_TEMPLATE_NAME
     namespace: NAMESPACE_NAME
     labels:
       cloud.google.com/apply-warden-policies: "true"
   template:
     spec:
       nodeSelector:
         cloud.google.com/gke-accelerator: GPU_TYPE
         cloud.google.com/gke-flex-start: "true"
       tolerations:
         - key: "nvidia.com/gpu"
           operator: "Exists"
           effect: "NoSchedule"
       containers:
         - name: pi
           image: perl
           command: ["/bin/sh"]
           resources:
             limits:
               cpu: "700m"
               nvidia.com/gpu: 1
             requests:
               cpu: "700m"
               nvidia.com/gpu: 1
       restartPolicy: Never
   ---
   apiVersion: autoscaling.x-k8s.io/API_VERSION
   kind: ProvisioningRequest
   metadata:
     name: PROVISIONING_REQUEST_NAME
     namespace: NAMESPACE_NAME
   spec:
     provisioningClassName: queued-provisioning.gke.io
     parameters:
       maxRunDurationSeconds: "MAX_RUN_DURATION_SECONDS"
     podSets:
     - count: COUNT
       podTemplateRef:
         name: POD_TEMPLATE_NAME
   

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

   • ‫API_VERSION: גרסת ה-API, ‏v1 או v1beta1. מומלץ להשתמש בגרסה v1 כדי ליהנות מיציבות וגישה לתכונות העדכניות ביותר.
   • ‫NAMESPACE_NAME: השם של מרחב השמות של Kubernetes. מרחב השמות חייב להיות זהה למרחב השמות של ה-Pods.
   • ‫PROVISIONING_REQUEST_NAME: השם של ProvisioningRequest. תצטרכו להשתמש בשם הזה בהערה של ה-Pod.
   • ‫MAX_RUN_DURATION_SECONDS: באופן אופציונלי, זמן הריצה המקסימלי של צומת בשניות, עד ברירת המחדל של שבעה ימים. למידע נוסף, ראה איך עובד תהליך ההקצאה עם התחלה גמישה (Flex-start) והקצאת משאבים בהמתנה. אי אפשר לשנות את הערך הזה אחרי יצירת הבקשה. השדה הזה זמין ב-GKE בגרסה 1.28.5-gke.1355000 ואילך.
   • ‫COUNT: מספר ה-Pods שהתבקשו. הצמתים מתוזמנים באופן אטומי בתחום אחד.
   • ‫POD_TEMPLATE_NAME: השם של PodTemplate.
   • ‫GPU_TYPE: סוג חומרת ה-GPU.

   יכול להיות ש-GKE יחיל אימותים ושינויים על ה-Pods במהלך היצירה שלהם. התווית cloud.google.com/apply-warden-policies מאפשרת ל-GKE להחיל את אותם אימותים ושינויים על אובייקטים של PodTemplate. התווית הזו נחוצה כדי ש-GKE יוכל לחשב את דרישות המשאבים של הצמתים עבור ה-Pods.

   אזהרה: השילוב של התחלה גמישה (Flex-start) עם הקצאת משאבים בהמתנה תומך רק במפרט PodSet אחד. אם רוצים לשלב תבניות שונות של Pod, צריך להשתמש בתבנית שמבקשת את הכי הרבה משאבים, או להשתמש באפשרות IdenticalWorkloadSchedulingRequirements בתכונה podSetMergePolicy כדי למזג תבניות של Pod עם דרישות תזמון זהות. אין תמיכה בשילוב של סוגי מכונות שונים, כמו מכונות וירטואליות עם סוגים שונים של GPU.

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

   kubectl apply -f provisioning-request.yaml
   

הגדרת ה-Pods

בקטע הזה נעשה שימוש ב-Kubernetes Jobs כדי להגדיר את קבוצות ה-Pod. אבל אפשר גם להשתמש ב-JobSet של Kubernetes או בכל מסגרת אחרת כמו Kubeflow,‏ Ray או בקרי התאמה אישית. במפרט העבודה, מקשרים את ה-Pods אל ProvisioningRequest באמצעות ההערות הבאות:

apiVersion: batch/v1
kind: Job
spec:
  template:
    metadata:
      annotations:
        autoscaling.x-k8s.io/consume-provisioning-request: PROVISIONING_REQUEST_NAME
        autoscaling.x-k8s.io/provisioning-class-name: "queued-provisioning.gke.io"
    spec:
      ...

מפתח ההערה של ה-Pod‏ consume-provisioning-request מגדיר את ה-ProvisioningRequest שייצרך. ‫GKE משתמש בהערות consume-provisioning-request ו-provisioning-class-name כדי לבצע את הפעולות הבאות:

• כדי להקצות את ה-Pods רק בצמתים שהוקצו על ידי התחלה גמישה (Flex-start) עם הקצאת משאבים בהמתנה.
• כדי למנוע ספירה כפולה של בקשות משאבים בין Pods לבין התחלה גמישה (Flex-start) עם הקצאת משאבים בהמתנה ב-Cluster Autoscaler.
• כדי להוסיף הערה safe-to-evict: false, כדי למנוע מהכלי לשינוי גודל האשכול באופן אוטומטי להעביר Pods בין צמתים ולהפריע לחישובים של אצווה. אפשר לשנות את ההתנהגות הזו על ידי ציון safe-to-evict: true בהערות של ה-Pod.

צפייה בסטטוס של בקשת הקצאת הרשאות

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

סטטוס בקשת הקצאת הרשאות	תיאור	תוצאה אפשרית
בהמתנה	הבקשה עדיין לא נראתה ולא עברה עיבוד.	אחרי העיבוד, הבקשה עוברת למצב Accepted או Failed.
Accepted=true	הבקשה מתקבלת וממתינה עד שהמשאבים יהיו זמינים.	הבקשה אמורה לעבור למצב Provisioned אם נמצאו משאבים והוקצו צמתים, או למצב Failed אם זה לא היה אפשרי. כברירת מחדל, מערכת GKE ממתינה עד 14 ימים לבקשות ל-GPU, ופרק זמן לא מוגדר לבקשות ל-TPU. אם הבקשה לא תטופל בפרק הזמן הזה, היא תעבור למצב Failed.
Provisioned=true	הצמתים מוכנים.	יש לכם 10 דקות להפעיל את ה-Pods כדי להשתמש במשאבים שהוקצו. אחרי פרק הזמן הזה, המידרוג האוטומטי של האשכול מחשיב את הצמתים כלא נחוצים ומסיר אותם.
Failed=true	אי אפשר להקצות את הצמתים בגלל שגיאות. ‫Failed=true הוא מצב סופי.	פתרון בעיות של התנאי על סמך המידע בשדות Reason ו-Message של התנאי. יוצרים בקשה חדשה להקצאת הרשאות ומנסים שוב.
Provisioned=false	הצמתים עדיין לא הוקצו.	אם הערך הוא Reason=NotProvisioned, זהו מצב זמני לפני שכל המשאבים יהיו זמינים. אם Reason=QuotaExceeded, פותרים את הבעיה במצב על סמך הסיבה הזו והמידע בשדה Message של המצב. יכול להיות שתצטרכו לבקש להגדיל את המכסה. פרטים נוספים זמינים בקטע בדיקה אם בקשת ההקצאה מוגבלת על ידי מכסה. התכונה הזו Reason זמינה רק בגרסה ‎1.29.2-gke.1181000 של GKE ואילך. אם Reason=ResourcePoolExhausted והאזור Message מכיל Expected time is indefinite, צריך לבחור אזור או תחום אחרים, או לשנות את המשאבים המבוקשים.

הפעלת ה-Pods

כשהבקשה להקצאת משאבים מגיעה לסטטוס Provisioned=true, אפשר להפעיל את המשימה כדי להפעיל את ה-Pods. כך נמנעת התרבות של Pods שלא ניתן לתזמן לבקשות בהמתנה או לבקשות שנכשלו, דבר שיכול להשפיע על הביצועים של kube-scheduler ושל המידרוג האוטומטי של האשכול.

לחלופין, אם לא חשוב לכם שיהיה אפשר לתזמן את ה-Pods, אתם יכולים ליצור אותם במקביל לבקשת ההקצאה.

ביטול הבקשה להקצאת הרשאות

כדי לבטל את הבקשה לפני שהיא מוקצית, אפשר למחוק את ProvisioningRequest:

kubectl delete provreq PROVISIONING_REQUEST_NAME -n NAMESPACE

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

פתרון בעיות שקשורות למכסות

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

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

בדיקת המכסה במסוף Google Cloud

כדי לבדוק את השם של מכסת השימוש ואת השימוש הנוכחי בGoogle Cloud מסוף, פועלים לפי השלבים הבאים:

1. נכנסים לדף Quotas במסוף Google Cloud :

   לפתיחת הדף Quotas

2. בתיבה Filter, בוחרים במאפיין Metric, מזינים active_resize_requests ולוחצים על Enter.

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

בדיקה אם בקשת ההקצאה מוגבלת על ידי מכסה

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

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

kubectl describe provreq PROVISIONING_REQUEST_NAME \
    --namespace NAMESPACE

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

…
Last Transition Time:  2024-01-03T13:56:08Z
    Message:               Quota 'NVIDIA_P4_GPUS' exceeded. Limit: 1.0 in region europe-west4.
    Observed Generation:   1
    Reason:                QuotaExceeded
    Status:                False
    Type:                  Provisioned
…

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

העברת מאגרי צמתים מהקצאת משאבים בהמתנה להתחלה גמישה (Flex-start)

אפשרות הצריכה flex-start יוצרת מכונות וירטואליות מסוג Flex-start. כדי להעביר מאגרי צמתים קיימים שנוצרו באמצעות הדגל --enable-queued-provisioning לשימוש ב-flex-start, מבצעים את השלבים הבאים:

1. מוודאים שמאגר הצמתים ריק:

   kubectl get nodes -l cloud.google.com/gke-nodepool=NODEPOOL_NAME
   

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

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

2. מעדכנים את מאגר הצמתים למכונות וירטואליות מסוג Flex-start:

   gcloud container node-pools update NODEPOOL_NAME \
     --cluster=CLUSTER_NAME --flex-start
   

הפעולה הזו מבצעת את הפעולות הבאות:

• מעדכנים את מאגר הצמתים למאגר צמתים של מכונות וירטואליות עם הפעלה גמישה.
• החלת התמחור של צמתים שמשתמשים במכונות וירטואליות מסוג Flex-start.

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

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

• מידע נוסף על יחידות GPU ב-GKE
• איך פורסים עומסי עבודה של GPU ב-Autopilot
• איך מפעילים יחידות GPU ב-Confidential GKE Nodes
• איך מריצים עומס עבודה קטן של אצווה באמצעות מעבדים גרפיים ומצב הקצאת משאבים עם הפעלה גמישה