הגדרת GKE או Kubernetes בניהול עצמי

אתם יכולים להגדיר את פלטפורמת ML Diagnostics לעומסי עבודה של למידת מכונה שפועלים ב-Google Kubernetes Engine ‏(GKE) או ב-Kubernetes בניהול עצמי.

התכונות הבאות של "אבחון באמצעות למידת מכונה" זמינות לכלל המשתמשים:

  • מעקב אוטומטי אחרי עומסי עבודה ואיסוף מדדי מערכת: כדי לעקוב באופן אוטומטי אחרי עומסי עבודה ולאסוף מדדי מערכת ב-GKE, לא צריך להוסיף לקוד כלים או לבצע הגדרות נוספות. מעקב אחרי עומסי עבודה ואיסוף מדדי מערכת מופעלים כברירת מחדל, ואין צורך לבצע את השלבים במדריך הזה. הכלי למעקב אחרי עומסי עבודה תומך בסוגי העבודה JobSet ו-Job ב-GKE, והוא תואם לגרסאות 1.36.4-gke.1247000 ואילך של GKE.
  • מדדים של ML Diagnostics SDK ופרופיילינג פרוגרמטי: אם אתם רוצים להשתמש ב-ML Diagnostics SDK כדי לאסוף מדדים ולהריץ פרופיילינג פרוגרמטי, התקינו את תרשים ה-Helm של injection-webhook, תייגו את עומס העבודה והשתמשו ב-ML Diagnostics SDK. ב-GKE, אתם יכולים להשתמש בפקודה אחת של Google Cloud CLI אם אתם משתמשים בגרסה נתמכת של GKE, או לבצע התקנה ידנית. ב-Kubernetes בניהול עצמי, צריך להתקין את ה-webhook באופן ידני.
  • יצירת פרופילים על פי דרישה: אם אתם רוצים ליצור פרופילים על פי דרישה, התקינו את תרשים ה-Helm של connection-operator. ב-GKE, אתם יכולים להשתמש בפקודה אחת של ה-CLI של gcloud אם אתם משתמשים בגרסה נתמכת של GKE, או לבצע התקנה ידנית. ב-Kubernetes בניהול עצמי, צריך להתקין את האופרטור באופן ידני.

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

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

פריסת Diagon DaemonSet

אם אתם מריצים עומסי עבודה בקונטיינרים ב-GKE או באשכולות Kubernetes בניהול עצמי, אתם יכולים לפרוס את ה-daemon של Diagon כ-DaemonSet. כך אפשר לוודא שעותק של הדימון פועל בכל צומתי ה-GPU וה-TPU באשכול, או בצמתים נבחרים.

מאגר קובצי אימג' של קונטיינרים

הדמון של Diagon מתפרסם כקובץ אימג' של Docker, והוא זמין בנתיב הבא של Artifact Registry:

us-central1-docker.pkg.dev/hypercomputediagon-release/daemon-docker/mldiagnostics-daemon:latest

שלבי הפריסה

כדי לפרוס את Diagon DaemonSet באשכול, מבצעים את השלבים הבאים:

  1. יוצרים את הגדרת ה-DaemonSet: שומרים את הגדרת ה-YAML הבאה בתור diagon-daemonset.yaml. ההגדרה הזו מריצה את הדימון Diagon במצב הרשאות, כדי שהוא יוכל לאסוף מדדי אבחון ופרופילים ממכשירי ה-GPU וה-TPU המארחים.

    # diagon-daemonset.yaml
    apiVersion: apps/v1
    kind: DaemonSet
    metadata:
      name: diagon-daemon
      namespace: diagon
      labels:
        app.kubernetes.io/name: diagon-daemon
        app.kubernetes.io/part-of: diagon
    spec:
      selector:
        matchLabels:
          name: diagon-daemon
      template:
        metadata:
          labels:
            name: diagon-daemon
        spec:
          hostNetwork: true
          dnsPolicy: ClusterFirstWithHostNet
          serviceAccountName: SERVICE_ACCOUNT_NAME
          terminationGracePeriodSeconds: 30
          tolerations:
          - operator: Exists
            effect: NoSchedule
          - operator: Exists
            effect: NoExecute
          containers:
          - name: diagon-daemon
            image: us-central1-docker.pkg.dev/hypercomputediagon-release/daemon-docker/mldiagnostics-daemon:latest
            imagePullPolicy: Always
            command:
            - /mldiagnostics_extension_files/bin/mldiagnostics_extension
            - -standalone=true
            - -channel=hypercomputecluster.googleapis.com/diagnostics
            - -alsologtostderr=true
            securityContext:
              privileged: true
            resources:
              requests:
                cpu: 10m
                memory: 32Mi
              limits:
                memory: 256Mi  # No CPU limit.
    
  2. פריסת ה-DaemonSet באשכול: מריצים את הפקודה הבאה כדי לפרוס את ה-daemon בהקשר הפעיל של Kubernetes.

    kubectl apply -f diagon-daemonset.yaml
    
  3. בדיקת הפריסה והתקינות של ה-daemon: בתחנת העבודה האדמינסטרטיבית או ב-Cloud Shell, מוודאים שכל ה-pods של ה-daemon מתוזמנים בצמתים העובדים והגיעו למצב Running:

    kubectl get pods -n diagon -l name=diagon-daemon -o wide
    

    בודקים את יומני הסטרימינג כדי לוודא שיש חיבור למישור הבקרה של Google Cloud ML Diagnostics ושהאותות הפעילים תקינים:

    kubectl logs -n diagon -l name=diagon-daemon --tail=50
    

    הפלט כולל את החתימות הצפויות הבאות ביומן:

    Stream established.
    Received successful DaemonRegistrationResponse from backend
    Sending DaemonHeartbeatRequest
    
  4. עדכון קובץ האימג' של DaemonSet: כדי לעדכן לגרסה חדשה יותר של ה-daemon או לחזור לגרסה קודמת, מעדכנים את תג קובץ האימג' בקובץ ה-YAML, או מריצים ישירות את הפקודה הבאה.

    kubectl set image daemonset/diagon-daemon diagon-daemon=us-docker.pkg.dev/hypercomputediagon-release/daemon/diagon-daemon:v2.1.0 --namespace=kube-system
    

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

    kubectl rollout status daemonset/diagon-daemon --namespace=kube-system
    

הגדרת מפעיל ו-webhook

כדי להגדיר את האופרטור ואת ה-webhook, אתם יכולים לבחור באחת מהאפשרויות הבאות:

  • אם אתם משתמשים בגרסה של GKE שחדשה יותר מ-1.35.0-gke.3065000, אתם יכולים להגדיר את אשכול GKE ל-ML Diagnostics באמצעות פקודה אחת של ה-CLI של gcloud, דרך מסוף Google Cloud או באמצעות Terraform.

  • בגרסאות GKE שקודמות ל-1.35.0-gke.3065000 וב-Kubernetes בניהול עצמי, צריך להגדיר את האשכול באופן ידני כדי להתקין את פריטי המידע שנוצרו בתהליך הפיתוח (artifacts) של cert-manager,‏ injection-webhook ו-connection-operator. מידע נוסף זמין במאמר התקנה ידנית.

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

אם אתם משתמשים בסביבת Kubernetes בניהול עצמי במקום ב-GKE, התקינו את ה-webhook ל-SDK ופרסו את Diagon DaemonSet. בסביבת Kubernetes בניהול עצמי, מעקב אחרי עומסי עבודה לא פועל. יש תמיכה רק במדדי SDK, ביצירת פרופילים פרוגרמטית, ביצירת פרופילים על פי דרישה וביצירת פרופילים רציפה.

בגרסאות GKE שחדשות יותר מ-1.35.0-gke.3065000, צריך להשתמש באחת מהשיטות הבאות כדי לפרוס את רכיבי האבחון הנדרשים של ML (גם connection-operator וגם injection-webhook) באשכול GKE.

gcloud

באשכולות GKE חדשים:

gcloud beta container clusters create CLUSTER_NAME --enable-managed-mldiagnostics

באשכולות GKE קיימים:

gcloud beta container clusters update CLUSTER_NAME --enable-managed-mldiagnostics

כדי להשבית את אבחון ה-ML, משתמשים בפקודה הבאה:

gcloud beta container clusters update CLUSTER_NAME --no-enable-managed-mldiagnostics

למידע נוסף על פקודות ה-CLI של gcloud להגדרת אשכול GKE ל-ML Diagnostics, עיינו בדגל enable-managed-mldiagnostics בדפי העזר הבאים של ה-API:

המסוף

  • באשכולות GKE חדשים, עוברים אל Feature Manager > Managed Machine Learning Diagnostics.

    מעבר אל GKE Managed Machine Learning Diagnostics

  • באשכולות GKE קיימים, עוברים אל Clusters, בוחרים את שם האשכול, עוברים אל Edit ועורכים את Managed Machine Learning Diagnostics בקטע Features.

Terraform

אם אתם משתמשים ב-Terraform כדי להקצות את התשתית של GKE, אתם יכולים להשתמש בספק terraform-provider-google-beta (גרסה v7.28.0 ואילך) או במודול terraform-google-modules/kubernetes-engine/google (גרסה v45.0.0 ואילך).

שימוש ב Google Cloud ספק Terraform

כדי להפעיל את Managed ML Diagnostics באשכול חדש באמצעות המשאב google_container_cluster, מוסיפים את הבלוק managed_machine_learning_diagnostics_config עם enabled = true באמצעות הספק google-beta (גרסה v7.28.0 ואילך):

terraform {
  required_providers {
    google-beta = {
      source  = "hashicorp/google-beta"
      version = ">= 7.28.0"
    }
  }
}

resource "google_container_cluster" "primary" {
  provider = google-beta
  name     = "CLUSTER_NAME"
  location = "LOCATION"

  # ... other cluster configuration ...

  managed_machine_learning_diagnostics_config {
    enabled = true
  }
}

כדי להשבית את Managed ML Diagnostics באשכול באמצעות המשאב של Terraform, מגדירים את enabled = false בבלוק managed_machine_learning_diagnostics_config:

resource "google_container_cluster" "primary" {
  provider = google-beta
  name     = "CLUSTER_NAME"
  location = "LOCATION"

  # ... other cluster configuration ...

  managed_machine_learning_diagnostics_config {
    enabled = false
  }
}

שימוש במודול Terraform של GKE

כדי להפעיל את Managed ML Diagnostics באשכול באמצעות המודול terraform-google-modules/kubernetes-engine/google (כמו מודול המשנה beta-public-cluster), מגדירים את enable_managed_machine_learning_diagnostics = true:

module "gke" {
  source  = "terraform-google-modules/kubernetes-engine/google//modules/beta-public-cluster"
  version = ">= 45.0"

  project_id = "PROJECT_ID"
  name       = "CLUSTER_NAME"
  region     = "LOCATION"

  # ... other cluster configuration ...

  enable_managed_machine_learning_diagnostics = true
}

כדי להשבית את Managed ML Diagnostics באשכול באמצעות המודול של Terraform, מגדירים את enable_managed_machine_learning_diagnostics = false:

module "gke" {
  source  = "terraform-google-modules/kubernetes-engine/google//modules/beta-public-cluster"
  version = ">= 45.0"

  # ... other cluster configuration ...

  enable_managed_machine_learning_diagnostics = false
}

אחרי שמעדכנים את ההגדרות, מחילים את השינויים:

terraform apply

מידע נוסף על השימוש ב-Terraform עם GKE זמין במאמר תמיכה של Terraform ב-GKE.

התקנה ידנית

בגרסאות GKE שקודמות ל-1.35.0-gke.3065000, צריך להגדיר ידנית את אשכול GKE כדי להתקין את הרכיבים הבאים:

  • ‫cert-manager: דרישה מוקדמת ל-injection-webhook.
  • ‫injection-webhook: מספק ל-SDK את המטא-נתונים הנדרשים. הוא תומך בעומסי עבודה נפוצים של למידת מכונה ב-Kubernetes, כמו JobSet,‏ RayJob ו-LeaderWorkerSet.
  • ‫connection-operator: לפרופיילינג על פי דרישה ב-GKE. פריסת connection-operator יחד עם injection-webhook באשכול GKE מפעילה בקשות ליצירת פרופילים ל-Pods ייעודיים, עם שרתי פרופילים שפועלים כשמפעילים תיעוד לפי דרישה.

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

Cert-manager

התוסף cert-manager פועל כבקר האישורים של האשכול, כדי לוודא שהאפליקציות מאובטחות ושהאישורים לא יפוגו בטעות.

משתמשים ב-Helm כדי להתקין את הרכיבים הבאים:

helm repo add jetstack https://charts.jetstack.io
helm repo update

helm install \
  cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --create-namespace \
  --version v1.13.0 \
  --set installCRDs=true \
  --set global.leaderElection.namespace=cert-manager \
  --timeout 10m

Injection-webhook

תרשים ה-Helm של injection-webhook מעביר מטא-נתונים ל-SDK. משתמשים ב-helm upgrade --install כדי להתקין בפעם הראשונה או לשדרג התקנה קיימת.

helm upgrade --install mldiagnostics-injection-webhook \
  --namespace=gke-mldiagnostics \
  --create-namespace \
  --version 0.25.0 \
  oci://us-docker.pkg.dev/ai-on-gke/mldiagnostics-webhook-and-operator-helm/mldiagnostics-injection-webhook

מפעיל החיבור

תרשים ה-Helm של connection-operator מאפשר יצירת פרופילים על פי דרישה ב-GKE. בטבלה הבאה מפורטות הגרסאות של mldiagnostics-connection-operator:

גרסת JAX גרסת תרשים Helm
0.8.x 0.24.0
0.9.x ומעלה 0.24.0+

משתמשים ב-Helm כדי להתקין את הגרסה הנדרשת.

ב-JAX 0.8.x:

helm upgrade --install mldiagnostics-connection-operator \
  --namespace=gke-mldiagnostics \
  --create-namespace \
  --version 0.24.0 \
  oci://us-docker.pkg.dev/ai-on-gke/mldiagnostics-webhook-and-operator-helm/mldiagnostics-connection-operator \
  --set 'mldiagnosticsConnectionOperator.controller.args={--metrics-bind-address=:8443,--health-probe-bind-address=:8081,--sidecar-timeout=65m,--disable-hostname-override}'

ב-JAX 0.9.x ואילך:

helm upgrade --install mldiagnostics-connection-operator \
  --namespace=gke-mldiagnostics \
  --create-namespace \
  --version 0.24.0 \
  oci://us-docker.pkg.dev/ai-on-gke/mldiagnostics-webhook-and-operator-helm/mldiagnostics-connection-operator

עומס העבודה של התווית

כדי לבצע יצירת פרופילים פרוגרמטית, צריך להפעיל את injection-webhook כדי להוסיף מטא-נתונים ל-pods. לפני שפורסים את עומס העבודה, צריך לתייג את עומס העבודה או את מרחב השמות שלו בתווית managed-mldiagnostics-gke=true:

  • הוספת תווית לעומס עבודה: הוספת תווית לעומס עבודה מסוג JobSet,‏ LeaderWorkerSet או RayJob, שמפעילה את ה-webhook לעומס העבודה הספציפי הזה. דוגמה לעומס עבודה ב-JobSet:

    apiVersion: jobset.x-k8s.io/v1alpha2
    kind: JobSet
    metadata:
      name: single-host-tpu-v3-jobset2
      namespace: default
      labels:
        managed-mldiagnostics-gke: "true"
    
  • הוספת תווית למרחב שמות: הפעולה הזו מפעילה את ה-webhook לכל עומסי העבודה של JobSet, LeaderWorkerSet ו-RayJob במרחב השמות הזה.

    kubectl create namespace ai-workloads
    kubectl label namespace ai-workloads managed-mldiagnostics-gke=true