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

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

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

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

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

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

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

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

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

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

כדי להשתמש בהקצאת משאבים עם גמישות בתזמון ההפעלה באמצעות הקצאת משאבים בתור, צריך להוסיף את הדגלים --flex-start ו---enable-queued-provisioning כשיוצרים את מאגר הצמתים.

שיטה מומלצת:

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

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

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

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

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

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

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

שימוש במאגרי צמתים עם 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  \
    --reservation-affinity=none  \
    --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 כדי להגדיל את מהירות תעבורת הרשת.

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

• הדגל --flex-start בשילוב עם הדגל --enable-queued-provisioning מורה ל-GKE ליצור מאגר צמתים עם הקצאת משאבים בתור מופעלת, ולהוסיף את ה-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:

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

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

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

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

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

שיטה מומלצת:

משתמשים ב-Kueue כדי להריץ את עומסי העבודה של אצווה ו-AI עם הקצאת משאבים בתור.

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

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

• התחלה גמישה (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. מידע נוסף על התקנת Kueue זמין במאמר התקנה.

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

באמצעות המניפסט הבא, יוצרים תור ברמת האשכול בשם dws-cluster-queue ומרחב שמות של LocalQueue בשם dws-local-queue. משימות שמתייחסות לתור dws-cluster-queue במרחב השמות הזה משתמשות בהפעלה גמישה עם הקצאת משאבים בתור כדי לקבל את משאבי ה-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
---

לצביר הזה יש מכסות גבוהות, ורק השילוב של flex-start עם הקצאת משאבים בתור מופעל. מידע נוסף על ממשקי ה-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

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

לצביר הזה יש מכסות גבוהות, ורק השילוב של flex-start עם הקצאת משאבים בתור מופעל. מידע נוסף על ממשקי ה-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

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

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

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

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

   kubectl apply -f provisioning-request.yaml
   

הגדרת הפודים

בקטע הזה נעשה שימוש ב-Kubernetes Jobs כדי להגדיר את ה-Pods. אבל אפשר גם להשתמש ב-Kubernetes JobSet או בכל מסגרת אחרת כמו Kubeflow,‏ Ray או בקרי התאמה אישית. במפרט Job, מקשרים את ה-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, כדי למנוע מהמידרוג האוטומטי של האשכול מלהעביר Podים בין צמתים ולהפריע לחישובים של Batch. אפשר לשנות את ההתנהגות הזו על ידי ציון safe-to-evict: true בהערות של ה-Pod.

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

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

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

הפעלת ה-Pods

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

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

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

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

kubectl delete provreq PROVISIONING_REQUEST_NAME -n NAMESPACE

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

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

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

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

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