הגדרת זמינות גבוהה גמישה בין אזורים

במאמר הזה נסביר איך להגדיר זמינות גבוהה אלסטית בין אזורים לעומסי עבודה של הסקת מסקנות מ-AI באמצעות Multi-Cluster Inference Gateway (שער הסקת מסקנות מרובה אשכולות) של Google Kubernetes Engine ‏(GKE) והתכונה 'שינוי גודל אוטומטי' של GKE. ההגדרה הזו מאפשרת לכם לאזן עומסי עבודה בצורה חכמה בין כמה אשכולות GKE באזורים שונים.

מידע נוסף על GKE Multi-Cluster Inference Gateway זמין במאמר מידע על GKE Multi-Cluster Inference Gateway.

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

  1. מפעילים את Google Kubernetes Engine API.

    הפעלת Google Kubernetes Engine API

  2. אם אתם מתכננים להשתמש ב-Google Cloud CLI למשימה הזו, אתם צריכים להתקין ולהפעיל אותו.

  3. מוודאים שיש בפרויקט מכסה מספיקה לשימוש ב-GPU מדגם H100. מידע נוסף זמין במאמרים בנושא מכסת GPU והקצאת משאבים.

  4. משתמשים בגרסה ‎1.34.1-gke.1127000 של GKE ואילך.

  5. משתמשים ב-CLI של gcloud בגרסה 480.0.0 ואילך.

  6. מוודאים שלחשבון השירות שבו משתמשים הצמתים יש את ההרשאות roles/monitoring.metricWriter ו-roles/stackdriver.resourceMetadata.writer.

  7. מוודאים שיש לכם תפקידים ב-IAM (המערכת לניהול הזהויות והרשאות הגישה) roles/container.admin וroles/iam.serviceAccountAdmin בפרויקט.

  8. צריך להשלים את הדרישות המוקדמות הבאות של Hugging Face:

    1. יוצרים חשבון ב-Hugging Face.
    2. שליחת בקשה וקבלת אישור לגישה למודל Llama 3.1 ב-Hugging Face.
    3. חותמים על הסכם הרישיון בדף של המודל ב-Hugging Face.
    4. יוצרים אסימון גישה ל-Hugging Face עם הרשאות קריאה לפחות.

יצירת אשכולות ומאגרי צמתים

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

  1. יוצרים את האשכול הראשון:

    gcloud container clusters create gke-west --zone \
    CLUSTER_1_ZONE \
    --project=PROJECT_ID \
    --gateway-api=standard \
    --cluster-version=GKE_VERSION \
    --machine-type="MACHINE_TYPE" \
    --disk-type="DISK_TYPE" \
    --enable-managed-prometheus --monitoring=SYSTEM,DCGM \
    --hpa-profile=performance \
    --workload-pool=PROJECT_ID.s3ns.svc.id.goog \
    --async

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

    • ‫PROJECT_ID: מזהה הפרויקט
    • ‫CLUSTER_1_ZONE: האזור של האשכול הראשון, לדוגמה europe-west3-c
    • ‫GKE_VERSION: גרסת GKE לשימוש, לדוגמה 1.34.1-gke.1127000
    • ‫MACHINE_TYPE: סוג המכונה של צמתי האשכול, לדוגמה c2-standard-16
    • ‫DISK_TYPE: סוג הדיסק של צמתי האשכול, לדוגמה pd-standard

  2. יוצרים מאגר צמתים מסוג H100 באשכול הראשון:

    gcloud container node-pools create h100 \
    --accelerator "type=nvidia-h100-80gb,count=2,gpu-driver-version=latest" \
    --project=PROJECT_ID \
    --location=CLUSTER_1_ZONE \
    --node-locations=CLUSTER_1_ZONE \
    --cluster=CLUSTER_1_NAME \
    --machine-type=NODE_POOL_MACHINE_TYPE \
    --num-nodes=NUM_NODES \
    --spot \
    --min-nodes=MIN_NUM_NODES \
    --max-nodes=MAX_NUM_NODES \
    --enable-autoscaling \
    --async

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

    • ‫PROJECT_ID: מזהה הפרויקט
    • ‫CLUSTER_1_ZONE: האזור של האשכול הראשון, לדוגמה europe-west3-c
    • ‫CLUSTER_1_NAME: השם של האשכול הראשון, למשל gke-west
    • ‫NODE_POOL_MACHINE_TYPE: סוג המכונה של מאגר הצמתים, לדוגמה a3-highgpu-2g
    • ‫NUM_NODES: מספר הצמתים במאגר הצמתים, לדוגמה 3
    • ‫MIN_NUM_NODES: מספר הצמתים המינימלי להרחבה אוטומטית במאגר הצמתים, לדוגמה 1
    • ‫MAX_NUM_NODES: המספר המקסימלי של הצמתים להרחבה אוטומטית במאגר הצמתים, לדוגמה 10

  3. מקבלים פרטי כניסה ויוצרים סוד של טוקן Hugging Face באשכול הראשון:

    gcloud container clusters get-credentials CLUSTER_1_NAME \
    --location CLUSTER_1_ZONE \
    --project=PROJECT_ID

kubectl create secret generic hf-token \
    --from-literal=token=HF_TOKEN

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

    • ‫PROJECT_ID: מזהה הפרויקט
    • ‫CLUSTER_1_NAME: השם של האשכול הראשון, למשל gke-west
    • ‫CLUSTER_1_ZONE: האזור של האשכול הראשון, לדוגמה europe-west3-c
    • ‫HF_TOKEN: טוקן הגישה שלכם ל-Hugging Face

  4. יוצרים את האשכול השני באזור אחר מהאזור של האשכול הראשון:

    gcloud container clusters create gke-east --zone CLUSTER_2_ZONE \
    --project=PROJECT_ID \
    --gateway-api=standard \
    --cluster-version=GKE_VERSION \
    --machine-type="MACHINE_TYPE" \
    --disk-type="DISK_TYPE" \
    --enable-managed-prometheus \
    --monitoring=SYSTEM,DCGM \
    --hpa-profile=performance \
    --workload-pool=PROJECT_ID.s3ns.svc.id.goog \
    --async

    מחליפים את CLUSTER_2_ZONE באזור של האשכול השני, לדוגמה us-east4-a.

  5. יוצרים מאגר צמתים מסוג H100 עבור האשכול השני:

    gcloud container node-pools create h100 \
    --accelerator "type=nvidia-h100-80gb,count=2,gpu-driver-version=latest" \
    --project=PROJECT_ID \
    --location=CLUSTER_2_ZONE \
    --node-locations=CLUSTER_2_ZONE \
    --cluster=CLUSTER_2_NAME \
    --machine-type=NODE_POOL_MACHINE_TYPE \
    --num-nodes=NUM_NODES \
    --spot \
    --min-nodes=MIN_NUM_NODES \
    --max-nodes=MAX_NUM_NODES \
    --enable-autoscaling \
    --async

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

    • ‫PROJECT_ID: מזהה הפרויקט
    • ‫CLUSTER_2_ZONE: האזור של האשכול השני, למשל us-east4-a
    • ‫CLUSTER_2_NAME: השם של האשכול השני, למשל gke-east
    • ‫NODE_POOL_MACHINE_TYPE: סוג המכונה של מאגר הצמתים, לדוגמה a3-highgpu-2g
    • ‫NUM_NODES: מספר הצמתים במאגר הצמתים, לדוגמה 3
    • ‫MIN_NUM_NODES: מספר הצמתים המינימלי להרחבה אוטומטית במאגר הצמתים, לדוגמה 1
    • ‫MAX_NUM_NODES: המספר המקסימלי של הצמתים להרחבה אוטומטית במאגר הצמתים, לדוגמה 10

  6. מקבלים פרטי כניסה ויוצרים סוד עבור אסימון Hugging Face באשכול השני:

    gcloud container clusters get-credentials CLUSTER_2_NAME \
    --location CLUSTER_2_ZONE \
    --project=PROJECT_ID
kubectl create secret generic hf-token --from-literal=token=HF_TOKEN

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

    • ‫HF_TOKEN: טוקן הגישה שלכם ל-Hugging Face

רישום אשכולות ב-Fleet

  1. רושמים את האשכולות ב-Fleet של הפרויקט:

    gcloud container fleet memberships register CLUSTER_1_NAME \
    --gke-cluster CLUSTER_1_ZONE/CLUSTER_1_NAME \
    --location=global \
    --project=PROJECT_ID

gcloud container fleet memberships register CLUSTER_2_NAME \
    --gke-cluster CLUSTER_2_ZONE/CLUSTER_2_NAME \
    --location=global \
    --project=PROJECT_ID

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

    • ‫CLUSTER_1_NAME: השם של האשכול הראשון, למשל gke-west
    • ‫CLUSTER_2_NAME: השם של האשכול השני, למשל gke-east

  2. מפעילים את התכונה Multi-Cluster Ingress ומגדירים אשכול תצורה:

    gcloud container fleet ingress enable \
    --config-membership=projects/PROJECT_ID/locations/global/memberships/CLUSTER_1_NAME

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

    • ‫PROJECT_ID: מזהה הפרויקט
    • ‫CLUSTER_1_NAME: השם של האשכול הראשון, למשל gke-west

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

אזהרה: Cloud de Confiance by S3NS מאפשרת לכל רשת VPC להכיל רק תת-רשת אחת של שרת proxy בלבד לכל אזור. אם אזור היעד כבר מכיל רשת משנה (subnet) עם הגדרה של purpose=REGIONAL_MANAGED_PROXY שמוגדרת כפרוקסי בלבד, יצירת רשת המשנה GLOBAL_MANAGED_PROXY תיכשל. קודם צריך למחוק את רשת המשנה הקיימת של פרוקסי אזורי בלבד. מחיקה של רשת משנה אזורית מסוג proxy-only משפיעה על כל מאזני העומסים האזוריים שמבוססים על Envoy באותו אזור שמשתמשים בה, ולכן חשוב לתכנן את השינוי בהתאם.

  1. יוצרים רשת משנה באזור של האשכול הראשון:

    gcloud compute networks subnets create CLUSTER_1_REGION-subnet \
    --purpose=GLOBAL_MANAGED_PROXY \
    --role=ACTIVE \
    --region=CLUSTER_1_REGION \
    --network=default \
    --range=SUBNET_RANGE_1 \
    --project=PROJECT_ID

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

    • ‫PROJECT_ID: מזהה הפרויקט
    • ‫CLUSTER_1_REGION: האזור של האשכול הראשון, למשל europe-west3
    • ‫SUBNET_RANGE_1: טווח כתובות ה-IP של רשת המשנה של הפרוקסי באזור של האשכול הראשון, לדוגמה 10.0.0.0/23

  2. יוצרים תת-רשת באזור של האשכול השני:

    gcloud compute networks subnets create CLUSTER_2_REGION-subnet \
    --purpose=GLOBAL_MANAGED_PROXY \
    --role=ACTIVE \
    --region=CLUSTER_2_REGION \
    --network=default \
    --range=SUBNET_RANGE_2 \
    --project=PROJECT_ID

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

    • ‫PROJECT_ID: מזהה הפרויקט
    • ‫CLUSTER_2_REGION: האזור של האשכול השני, למשל us-east4
    • ‫SUBNET_RANGE_2: טווח כתובות ה-IP של רשת המשנה של הפרוקסי בלבד באזור של האשכול השני, לדוגמה 10.5.0.0/23

התקנה של משאבים מותאמים אישית נדרשים

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

    CLUSTER1_CONTEXT="gke_PROJECT_ID_CLUSTER_1_ZONE_CLUSTER_1_NAME"
CLUSTER2_CONTEXT="gke_PROJECT_ID_CLUSTER_2_ZONE_CLUSTER_2_NAME"

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

    • ‫PROJECT_ID: מזהה הפרויקט
    • ‫CLUSTER_1_ZONE: האזור של האשכול הראשון, לדוגמה europe-west3-c
    • ‫CLUSTER_1_NAME: השם של האשכול הראשון, למשל gke-west
    • ‫CLUSTER_2_ZONE: האזור של האשכול השני, למשל us-east4-a
    • ‫CLUSTER_2_NAME: השם של האשכול השני, למשל gke-east

  2. מתקינים את המשאב המותאם אישית InferencePool ואת המשאב המותאם אישית InferenceObjective בשני האשכולות:

    kubectl apply -f https://github.com/kubernetes-sigs/gateway-api-inference-extension/releases/download/v1.0.1/manifests.yaml --context=$CLUSTER1_CONTEXT

kubectl apply -f https://github.com/kubernetes-sigs/gateway-api-inference-extension/releases/download/v1.0.1/manifests.yaml --context=$CLUSTER2_CONTEXT

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

  1. פורסים את שרתי המודלים לשני האשכולות:

    kubectl apply -f \
https://raw.githubusercontent.com/kubernetes-sigs/gateway-api-inference-extension/release-1.0/config/manifests/vllm/gpu-deployment.yaml \
--context=$CLUSTER1_CONTEXT

kubectl apply -f \
https://raw.githubusercontent.com/kubernetes-sigs/gateway-api-inference-extension/release-1.0/config/manifests/vllm/gpu-deployment.yaml \
--context=$CLUSTER2_CONTEXT

  2. שומרים את המניפסט הבא בקובץ בשם inference-objective.yaml:

    apiVersion: inference.networking.x-k8s.io/v1alpha2
kind: InferenceObjective
metadata:
  name: food-review
spec:
  priority: 10
  poolRef:
    name: llama3-8b-instruct
    group: "inference.networking.k8s.io"

  3. מחילים את המניפסט על שני האשכולות:

    kubectl apply -f inference-objective.yaml --context=$CLUSTER1_CONTEXT
kubectl apply -f inference-objective.yaml --context=$CLUSTER2_CONTEXT

  4. פורסים את משאבי InferencePool לשני האשכולות באמצעות Helm:

    helm install vllm-llama3-8b-instruct \
  --kube-context $CLUSTER1_CONTEXT \
  --set inferencePool.modelServers.matchLabels.app=vllm-llama3-8b-instruct \
  --set provider.name=gke \
  --set inferenceExtension.monitoring.gke.enabled=true \
  --version v1.0.1 \
  oci://registry.k8s.io/gateway-api-inference-extension/charts/inferencepool

helm install vllm-llama3-8b-instruct \
  --kube-context $CLUSTER2_CONTEXT \
  --set inferencePool.modelServers.matchLabels.app=vllm-llama3-8b-instruct \
  --set provider.name=gke \
  --set inferenceExtension.monitoring.gke.enabled=true \
  --version v1.0.1 \
  oci://registry.k8s.io/gateway-api-inference-extension/charts/inferencepool

  5. בשני האשכולות, מסמנים את המשאבים InferencePool כמיוצאים בשני האשכולות:

    kubectl annotate inferencepool vllm-llama3-8b-instruct networking.gke.io/export="True" \
    --context=$CLUSTER1_CONTEXT

kubectl annotate inferencepool vllm-llama3-8b-instruct networking.gke.io/export="True" \
    --context=$CLUSTER2_CONTEXT

פריסת שער היקשים חוצה אזורים

  1. שומרים את קובץ המניפסט הבא בשם mygateway.yaml:

    ---
kind: Gateway
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: cross-region-gateway
  namespace: default
spec:
  gatewayClassName: gke-l7-cross-regional-internal-managed-mc
  addresses:
  -   type: networking.gke.io/ephemeral-ipv4-address/europe-west3
    value: "europe-west3"
  -   type: networking.gke.io/ephemeral-ipv4-address/us-east4
    value: "us-east4"
  listeners:
  -   name: http
    protocol: HTTP
    port: 80
    allowedRoutes:
      kinds:
      -   kind: HTTPRoute
      namespaces:
        from: All
---
apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: vllm-llama3-8b-instruct-default
spec:
  parentRefs:
  -   name: cross-region-gateway
    kind: Gateway
  rules:
  -   backendRefs:
    -   group: networking.gke.io
      kind: GCPInferencePoolImport
      name: vllm-llama3-8b-instruct
---
kind: HealthCheckPolicy
apiVersion: networking.gke.io/v1
metadata:
  name: health-check-policy
  namespace: default
spec:
  targetRef:
    group: "networking.gke.io"
    kind: GCPInferencePoolImport
    name: vllm-llama3-8b-instruct
  default:
    config:
      type: HTTP
      httpHealthCheck:
          requestPath: /health
          port: 8000

  2. מחילים את המניפסט על אשכול ההגדרות:

    kubectl apply -f mygateway.yaml --context=CLUSTER1_CONTEXT

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

    • ‫CLUSTER1_CONTEXT: ההקשר של האשכול הראשון, לדוגמה gke_my-project_europe-west3-c_gke-west

הפעלת דיווח על מדדים מותאמים אישית

  1. יוצרים קובץ בשם metrics.yaml עם התוכן הבא:

    apiVersion: autoscaling.gke.io/v1beta1
kind: AutoscalingMetric
metadata:
  name: gpu-cache
  namespace: default
spec:
  selector:
    matchLabels:
      app: vllm-llama3-8b-instruct
  endpoints:
  -   port: 8000
    path: /metrics
    metrics:
    -   name: vllm:kv_cache_usage_perc
      exportName: kv-cache
    -   name: vllm:gpu_cache_usage_perc
      exportName: kv-cache-old

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

    kubectl apply -f metrics.yaml --context=CLUSTER1_CONTEXT
kubectl apply -f metrics.yaml --context=CLUSTER2_CONTEXT

    הגדרות של CLUSTER1_CONTEXT ו-CLUSTER2_CONTEXT מפורטות במאמר התקנת משאבים מותאמים אישית נדרשים.

הגדרת מדיניות איזון העומסים

בקטע הזה מוסבר איך להגדיר את מדיניות איזון העומסים. במדיניות הזו מוגדרת שיטת חלוקת התנועה בין מאגרי ההסקות על סמך מדדים מותאמים אישית והעדפות אזוריות. ההגדרה הבאה קובעת את us-east4 כאזור המועדף. התנועה עוברת לאזורים אחרים רק כשgke.named_metrics.kv-cache המדד המותאם אישית באזור us-east4 מגיע ל-80% ניצול.

  • בגרסאות vLLM‏ v0.10.2 ואילך, משתמשים במדד gke.named_metrics.kv-cache.
  • בגרסאות קודמות, משתמשים במדד gke.named_metrics.kv-cache-old.

  1. יוצרים קובץ בשם backend-policy.yaml עם התוכן הבא:

    kind: GCPBackendPolicy
apiVersion: networking.gke.io/v1
metadata:
  name: my-backend-policy
spec:
  targetRef:
    group: "networking.gke.io"
    kind: GCPInferencePoolImport
    name: vllm-llama3-8b-instruct
  default:
    timeoutSec: 600
    balancingMode: CUSTOM_METRICS
    trafficDuration: LONG
    customMetrics:
    -   name: gke.named_metrics.kv-cache
      maxUtilizationPercent: 80
      dryRun: false
    scopes:
    -   selector:
        gke.io/region: "us-east4"
      backendPreference: PREFERRED

  2. החלת המדיניות החדשה:

    kubectl apply -f backend-policy.yaml --context=CLUSTER1_CONTEXT

    מחליפים את CLUSTER1_CONTEXT בהקשר של האשכול הראשון, לדוגמה gke_my-project_europe-west3-c_gke-west

הגדרת התאמה אוטומטית לעומס

כדי לוודא שכל אשכול יכול להתמודד עם עומס גדל והולך לפני שהתנועה עוברת לאזורים אחרים, צריך להגדיר את Horizontal-Pod-Autoscaler ‏ (HPA) לפריסות של שרת המודל.

עקרונות מרכזיים להגדרה

  • שימוש באותם מדדים בהתאמה אישית: צריך להגדיר את ה-HPA כך שהוא יתבסס על אותם מדדים בהתאמה אישית שבהם משתמשים ב-GCPBackendPolicy עבור Multi-Cluster Inference Gateway (לדוגמה, vllm:kv_cache_usage_perc). הגישה הזו עוזרת לוודא שהאיזון בעומס וההחלטות לגבי שינוי הגודל מבוססים על אותו אות משרתי ההסקה. הערך של המדדים שבוחרים צריך להיות בין 0 ל-1 כדי לייצג את רמת הניצול. אם ערך המדד גדול מ-1, הוא מתפרש כניצול של 100% על ידי מאזן העומסים, וזה עלול לגרום להתנהגויות לא צפויות של ניתוב.

  • הגדרת יעד HPA נמוך יותר: ערך היעד של המדד בהגדרת ה-HPA צריך להיות נמוך יותר מההגדרה maxUtilizationPercent שמוגדרת ב-GCPBackendPolicy. אם מגדירים את יעד הניצול של HPA לערך נמוך יותר (לדוגמה, HPA מבצע מידרוג ב-50% ניצול ממוצע), מאפשרים לאשכול להוסיף עוד רפליקות לפני שמגיעים לסף של מאזן העומסים (לדוגמה, 80% ניצול). הגישה הזו עוזרת למקסם את הקיבולת באזור המועדף. הגדרת יעד ניצול נמוך יותר עוזרת גם למנוע מעבר תנועה מוקדם מדי, כי היא מאפשרת לשמור את הזמינות הגבוהה האלסטית בין אזורים למקרים שבהם האזור הנוכחי באמת מתקרב למגבלות שלו.

  1. נותנים למשתמש את היכולת ליצור את תפקידי ההרשאה הנדרשים:

    kubectl create clusterrolebinding cluster-admin-binding \
    --clusterrole cluster-admin --user "$(gcloud config get-value account)" --context=CLUSTER1_CONTEXT

kubectl create clusterrolebinding cluster-admin-binding \
    --clusterrole cluster-admin --user "$(gcloud config get-value account)" --context=CLUSTER2_CONTEXT

    המשתנים CLUSTER1_CONTEXT ו-CLUSTER2_CONTEXT מוגדרים בקטע התקנה של משאבים מותאמים אישית נדרשים.

  2. לכל אשכול, מפעילים את המניפסט:

    kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/k8s-stackdriver/master/custom-metrics-stackdriver-adapter/deploy/production/adapter_new_resource_model.yaml --context=CLUSTER1_CONTEXT

kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/k8s-stackdriver/master/custom-metrics-stackdriver-adapter/deploy/production/adapter_new_resource_model.yaml --context=CLUSTER2_CONTEXT

  3. מתן הרשאה לחשבון השירות custom-metrics-stackdriver-adapter לקרוא מדדים של Cloud Monitoring:

    PROJECT_NUMBER=$(gcloud projects describe PROJECT_ID --format="value(projectNumber)")

gcloud projects add-iam-policy-binding projects/PROJECT_ID \
  --role roles/monitoring.viewer \
  --member=principal://iam.googleapis.com/projects/$PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.s3ns.svc.id.goog/subject/ns/custom-metrics/sa/custom-metrics-stackdriver-adapter

    מחליפים את PROJECT_ID במזהה הפרויקט.

  4. שומרים את המניפסט הבא בקובץ בשם pod-monitoring.yaml:

    apiVersion: monitoring.googleapis.com/v1
kind: PodMonitoring
metadata:
  name: inference-server-podmon
spec:
  selector:
    matchLabels:
      app: vllm-llama3-8b-instruct
  endpoints:
  -   port: 8000
    path: /metrics
    interval: 5s

  5. מחילים את המניפסט על שני האשכולות:

    kubectl apply -f pod-monitoring.yaml --context=CLUSTER1_CONTEXT
kubectl apply -f pod-monitoring.yaml --context=CLUSTER2_CONTEXT

  6. שומרים את המניפסט הבא בקובץ בשם hpa.yaml:

    apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: inference-server-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: vllm-llama3-8b-instruct
  minReplicas: 1
  maxReplicas: 10
  metrics:
  -   type: Pods
    pods:
      metric:
        name: prometheus.googleapis.com|vllm:gpu_cache_usage_perc|gauge
      target:
        type: AverageValue
        averageValue: "0.5"

  7. מחילים את המניפסט על שני האשכולות:

    kubectl apply -f hpa.yaml --context=CLUSTER1_CONTEXT
kubectl apply -f hpa.yaml --context=CLUSTER2_CONTEXT

אימות הפריסה

  1. משיגים את כתובת ה-IP של השער:

    export GW_IP=$(kubectl get gateway/cross-region-gateway -n default --context=CLUSTER1_CONTEXT -o jsonpath='{.status.addresses[0].value}')

echo ${GW_IP}

    המשתנה CLUSTER1_CONTEXT מוגדר בקטע התקנת משאבים מותאמים אישית נדרשים.

  2. איך מתחילים סשן אינטראקטיבי ב-Pod זמני:sh

    kubectl run -it --rm --image=curlimages/curl curly --context=CLUSTER1_CONTEXT -- /bin/sh

    המשתנה CLUSTER1_CONTEXT מוגדר בקטע התקנת משאבים מותאמים אישית נדרשים.

  3. מתוך curly Pod, שולחים בקשת בדיקה:

    curl -i -X POST <var>GW_IP</var>:80/v1/completions \
-H 'Content-Type: application/json' \
-d '{
  "model": "food-review-1",
  "prompt": "What is the best pizza in the world?",
  "max_tokens": 100,
  "temperature": 0
}'

    מחליפים את GW_IP בכתובת ה-IP של השער מהשלב הקודם.

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

  1. מפעילים עומס מתמשך על כתובת ה-IP של שער הרשת באמצעות מחולל עומסים באותה רשת VPC.

  2. מתחילים עם עומס בינוני שצפוי שהאזור המועדף (us-east4) יטפל בו.

  3. להגדיל בהדרגה את קצב הבקשות או את מספר הבקשות המקבילות בבדיקת העומס.

  4. בזמן הפעלת בדיקת העומס, עוקבים אחרי המערכת במסוף Cloud de Confiance או באמצעות kubectl:

    • Pod scaling (HPA): check the number of Pods in the vllm-llama3-8b-instruct Deployment in both clusters.
    • שינוי גודל הצמתים (Cluster Autoscaler): מעקב אחרי מספר הצמתים ב-h100 מאגרי הצמתים בשני האשכולות.
    • מדדים בהתאמה אישית: כדאי לעקוב אחרי המדד vllm:kv_cache_usage_perc (בגרסה v0.10.2 ואילך של vllm) או אחרי המדד vllm:gpu_cache_usage_perc (בגרסה נמוכה מ-v.0.10.2 של vllm) ב-Monitoring לגבי פריסות של שרת מודלים בשני האשכולות.
    • מדדים של מאזן עומסים: בודקים את המדדים של מאזן העומסים שמשויך ל-cross-region-gateway ב-Monitoring.

ככל שתגדילו את העומס, הניצול ב-us-east4 יגדל. כש-HPA באשכול gke-east מתרחב והניצול הממוצע מתקרב לערך maxUtilization (80%) שמוגדר ב-GCPBackendPolicy, מאזן העומסים מתחיל לנתב בקשות לאשכול gke-west ב-europe-west3.

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