הגדרת 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 באשכול, מבצעים את השלבים הבאים:
יוצרים את הגדרת ה-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.פריסת ה-DaemonSet באשכול: מריצים את הפקודה הבאה כדי לפרוס את ה-daemon בהקשר הפעיל של Kubernetes.
kubectl apply -f diagon-daemonset.yamlבדיקת הפריסה והתקינות של ה-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עדכון קובץ האימג' של 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 קיימים, עוברים אל 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