Elastische regionenübergreifende Hochverfügbarkeit konfigurieren

In diesem Dokument wird beschrieben, wie Sie die elastische regionsübergreifende Hochverfügbarkeit für KI-Inferenzarbeitslasten mithilfe von Google Kubernetes Engine (GKE) Multi-Cluster Inference Gateway und der GKE-Autoscaling-Funktion konfigurieren. Mit dieser Einrichtung können Sie Arbeitslasten intelligent auf mehrere GKE-Cluster in verschiedenen Regionen verteilen.

Weitere Informationen zum GKE Multi-Cluster Inference Gateway finden Sie unter GKE Multi-Cluster Inference Gateway.

Hinweis

1. Aktivieren Sie die Google Kubernetes Engine API.

   Google Kubernetes Engine API aktivieren

2. Installieren und initialisieren Sie die Google Cloud CLI, wenn Sie sie für diese Aufgabe verwenden möchten.

3. Prüfen Sie, ob Ihr Projekt ein ausreichendes Kontingent für H100-GPUs hat. Weitere Informationen finden Sie unter GPU-Kontingent und Ressourcenzuweisung.

4. Verwenden Sie die GKE-Version 1.34.1-gke.1127000 oder höher.

5. Verwenden Sie die gcloud CLI-Version 480.0.0 oder höher.

6. Prüfen Sie, ob das von Ihren Knoten verwendete Dienstkonto die Berechtigungen roles/monitoring.metricWriter und roles/stackdriver.resourceMetadata.writer hat.

7. Sie benötigen die IAM-Rollen (Identity and Access Management) roles/container.admin und roles/iam.serviceAccountAdmin für das Projekt.

8. Erfüllen Sie die folgenden Hugging Face-Voraussetzungen:

   1. Erstellen Sie ein Hugging Face-Konto.
   2. Zugriff auf das Llama 3.1-Modell auf Hugging Face anfordern und genehmigen lassen.
   3. Unterzeichnen Sie die Lizenz-Einwilligungsvereinbarung auf der Seite des Modells auf Hugging Face.
   4. Generieren Sie ein Hugging Face-Zugriffstoken mit mindestens Leseberechtigung.

Cluster und Knotenpools erstellen

So erstellen Sie zwei GKE-Cluster in verschiedenen Regionen und konfigurieren ihre Knotenpools:

1. Ersten Cluster erstellen:

   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
   

   Ersetzen Sie Folgendes:

   • PROJECT_ID: Ihre Projekt-ID.
   • CLUSTER_1_ZONE: Die Zone für den ersten Cluster, z. B. europe-west3-c
   • GKE_VERSION: Die zu verwendende GKE-Version, z. B. 1.34.1-gke.1127000.
   • MACHINE_TYPE: der Maschinentyp für die Clusterknoten, z. B. c2-standard-16
   • DISK_TYPE: der Laufwerkstyp für die Clusterknoten, z. B. pd-standard

2. Erstellen Sie einen H100-Knotenpool im ersten Cluster:

   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
   

   Ersetzen Sie Folgendes:

   • PROJECT_ID: Ihre Projekt-ID.
   • CLUSTER_1_ZONE: Die Zone für den ersten Cluster, z. B. europe-west3-c
   • CLUSTER_1_NAME: der Name des ersten Clusters, z. B. gke-west
   • NODE_POOL_MACHINE_TYPE: der Maschinentyp für den Knotenpool, z. B. a3-highgpu-2g
   • NUM_NODES: die Anzahl der Knoten im Knotenpool, z. B. 3
   • MIN_NUM_NODES: die Mindestanzahl von Knoten für das Autoscaling im Knotenpool, z. B. 1
   • MAX_NUM_NODES: die maximale Anzahl von Knoten für das Autoscaling im Knotenpool, z. B. 10

3. Rufen Sie die Anmeldedaten ab und erstellen Sie ein Hugging Face-Token-Secret im ersten Cluster:

   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
   

   Ersetzen Sie Folgendes:

   • PROJECT_ID: Ihre Projekt-ID.
   • CLUSTER_1_NAME: der Name des ersten Clusters, z. B. gke-west
   • CLUSTER_1_ZONE: die Zone für den ersten Cluster, z. B. europe-west3-c
   • HF_TOKEN: Ihr Hugging Face-Zugriffstoken

4. Erstellen Sie den zweiten Cluster in einer anderen Region als den ersten Cluster:

   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
   

   Ersetzen Sie CLUSTER_2_ZONE durch die Zone für den zweiten Cluster, z. B. us-east4-a.

5. Erstellen Sie einen H100-Knotenpool für den zweiten Cluster:

   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
   

   Ersetzen Sie Folgendes:

   • PROJECT_ID: Ihre Projekt-ID.
   • CLUSTER_2_ZONE: die Zone für den zweiten Cluster, z. B. us-east4-a
   • CLUSTER_2_NAME: der Name des zweiten Clusters, z. B. gke-east
   • NODE_POOL_MACHINE_TYPE: der Maschinentyp für den Knotenpool, z. B. a3-highgpu-2g
   • NUM_NODES: die Anzahl der Knoten im Knotenpool, z. B. 3
   • MIN_NUM_NODES: die Mindestanzahl von Knoten für das Autoscaling im Knotenpool, z. B. 1
   • MAX_NUM_NODES: die maximale Anzahl von Knoten für das Autoscaling im Knotenpool, z. B. 10

6. Rufen Sie Anmeldedaten ab und erstellen Sie ein Secret für das Hugging Face-Token im zweiten Cluster:

   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
   

   Ersetzen Sie Folgendes. Definitionen anderer Variablen finden Sie in den vorherigen Schritten:

   • HF_TOKEN: Ihr Hugging Face-Zugriffstoken

Cluster bei einer Flotte registrieren

1. Registrieren Sie Ihre Cluster in der Flotte Ihres Projekts:

   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
   

   Ersetzen Sie die folgenden Variablen. Definitionen anderer Variablen finden Sie in den vorherigen Schritten:

   • CLUSTER_1_NAME: der Name des ersten Clusters, z. B. gke-west
   • CLUSTER_2_NAME: der Name des zweiten Clusters, z. B. gke-east

2. Aktivieren Sie das Multi-Cluster-Ingress-Feature und legen Sie einen Konfigurationscluster fest:

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

   Ersetzen Sie Folgendes. Definitionen anderer Variablen finden Sie in den vorherigen Schritten:

   • PROJECT_ID: Ihre Projekt-ID.
   • CLUSTER_1_NAME: der Name des ersten Clusters, z. B. gke-west

Nur-Proxy-Subnetze erstellen

Warnung: Cloud de Confiance by S3NS lässt pro VPC-Netzwerk nur ein Nur-Proxy-Subnetz pro Region zu. Wenn die Zielregion bereits ein Nur-Proxy-Subnetz mit der Einstellung purpose=REGIONAL_MANAGED_PROXY enthält, schlägt das Erstellen des Subnetzes GLOBAL_MANAGED_PROXY fehl. Sie müssen zuerst das vorhandene regionale Nur-Proxy-Subnetz löschen. Das Löschen eines regionalen Nur-Proxy-Subnetzes wirkt sich auf alle regionalen Envoy-basierten Load Balancer in dieser Region aus, die es verwenden. Planen Sie die Änderung daher entsprechend.

1. Erstellen Sie ein Subnetz in der Region des ersten Clusters:

   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
   

   Ersetzen Sie Folgendes:

   • PROJECT_ID: Ihre Projekt-ID.
   • CLUSTER_1_REGION: Die Region für den ersten Cluster, z. B. europe-west3
   • SUBNET_RANGE_1: Der Subnetz-IP-Bereich für das Proxy-only-Subnetz in der Region des ersten Clusters, z. B. 10.0.0.0/23

2. Erstellen Sie ein Subnetz in der Region des zweiten Clusters:

   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
   

   Ersetzen Sie Folgendes:

   • PROJECT_ID: Ihre Projekt-ID.
   • CLUSTER_2_REGION: die Region für den zweiten Cluster, z. B. us-east4
   • SUBNET_RANGE_2: Der Subnetz-IP-Bereich für das Proxy-only-Subnetz in der Region des zweiten Clusters, z. B. 10.5.0.0/23.

Erforderliche benutzerdefinierte Ressourcen installieren

1. Definieren Sie Kontextvariablen für Ihre Cluster:

   CLUSTER1_CONTEXT="gke_PROJECT_ID_CLUSTER_1_ZONE_CLUSTER_1_NAME"
   CLUSTER2_CONTEXT="gke_PROJECT_ID_CLUSTER_2_ZONE_CLUSTER_2_NAME"
   

   Ersetzen Sie Folgendes:

   • PROJECT_ID: Ihre Projekt-ID.
   • CLUSTER_1_ZONE: Die Zone für den ersten Cluster, z. B. europe-west3-c
   • CLUSTER_1_NAME: der Name des ersten Clusters, z. B. gke-west
   • CLUSTER_2_ZONE: die Zone für den zweiten Cluster, z. B. us-east4-a
   • CLUSTER_2_NAME: der Name des zweiten Clusters, z. B. gke-east

2. Installieren Sie die benutzerdefinierten Ressourcen „InferencePool“ und „InferenceObjective“ in beiden Clustern:

   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
   

Ressourcen in den Zielclustern bereitstellen

1. Stellen Sie die Modellserver in beiden Clustern bereit:

   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. Speichern Sie folgendes Manifest in einer Datei mit dem Namen 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. Wenden Sie das Manifest auf beide Cluster an:

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

4. Stellen Sie die InferencePool-Ressourcen mit Helm in beiden Clustern bereit:

   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. Markieren Sie in beiden Clustern die InferencePool-Ressourcen als exportiert:

   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
   

Regionenübergreifendes Inference Gateway bereitstellen

1. Speichern Sie das folgende Manifest als 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. Wenden Sie das Manifest auf den Konfigurationscluster an:

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

   Ersetzen Sie Folgendes:

   • CLUSTER1_CONTEXT: der Kontext für den ersten Cluster, z. B. gke_my-project_europe-west3-c_gke-west

Berichterstellung für benutzerdefinierte Messwerte aktivieren

1. Erstellen Sie eine Datei mit dem Namen metrics.yaml und dem folgendem Inhalt:

   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. Wenden Sie die Messwertkonfiguration für jeden Cluster an:

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

   Definitionen für CLUSTER1_CONTEXT und CLUSTER2_CONTEXT finden Sie unter Erforderliche benutzerdefinierte Ressourcen installieren.

Load-Balancing-Richtlinie konfigurieren

In diesem Abschnitt wird beschrieben, wie Sie die Load-Balancing-Richtlinie konfigurieren. In dieser Richtlinie wird festgelegt, wie Traffic basierend auf benutzerdefinierten Messwerten und regionalen Einstellungen auf Ihre Inferenzpools verteilt wird. In der folgenden Konfiguration wird us-east4 als bevorzugte Region festgelegt. Traffic wird nur dann auf andere Regionen übertragen, wenn der benutzerdefinierte Messwert gke.named_metrics.kv-cache in der Region us-east4 zu 80% ausgelastet ist.

• Verwenden Sie für vLLM-Versionen ab v0.10.2 den Messwert gke.named_metrics.kv-cache.
• Verwenden Sie für frühere Versionen den Messwert gke.named_metrics.kv-cache-old.

1. Erstellen Sie eine Datei mit dem Namen backend-policy.yaml und dem folgendem Inhalt:

   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. Wenden Sie die neue Richtlinie an:

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

   Ersetzen Sie CLUSTER1_CONTEXT durch den Kontext für den ersten Cluster, z. B. gke_my-project_europe-west3-c_gke-west.

Autoscaling konfigurieren

Damit jeder Cluster eine zunehmende Last bewältigen kann, bevor der Traffic auf andere Regionen überläuft, müssen Sie den Horizontal-Pod-Autoscaler (HPA) für Ihre Modell-Server-Bereitstellungen konfigurieren.

Wichtige Konfigurationsprinzipien

• Dieselben benutzerdefinierten Messwerte verwenden: Der HPA sollte so konfiguriert werden, dass er auf Grundlage derselben benutzerdefinierten Messwerte skaliert wird, die Sie im GCPBackendPolicy für das Multi-Cluster Inference Gateway verwenden (z. B. vllm:kv_cache_usage_perc). So wird sichergestellt, dass sowohl die Entscheidungen zum Load-Balancing als auch die Skalierungsentscheidungen auf demselben Signal von Ihren Inferenzservern basieren. Die ausgewählten Messwerte müssen einen Wert zwischen 0 und 1 haben, um die Auslastung darzustellen. Wenn der Messwert größer als 1 ist, wird er als 100-prozentige Auslastung durch den Load Balancer interpretiert, was zu unerwartetem Routingverhalten führen kann.

• Niedrigeres HPA-Ziel festlegen: Der Zielwert für den Messwert in der HPA-Konfiguration muss niedriger sein als die maxUtilizationPercent-Einstellung, die in der GCPBackendPolicy definiert ist. Wenn Sie die Zielauslastung des HPA niedriger festlegen (z. B. skaliert der HPA bei einer durchschnittlichen Auslastung von 50 %), kann der Cluster mehr Replikate hinzufügen, bevor der Schwellenwert des Load-Balancers (z. B. 80% Auslastung) erreicht wird. Dieser Ansatz trägt dazu bei, die Kapazität in der bevorzugten Region zu maximieren. Ein niedrigeres Auslastungsziel trägt auch dazu bei, einen vorzeitigen Traffic-Spillover zu verhindern, da die elastische regionenübergreifende Hochverfügbarkeit für den Fall reserviert wird, dass die aktuelle Region wirklich an ihre Grenzen stößt.

1. Ermöglichen Sie dem Nutzer, die erforderlichen Autorisierungsrollen zu erstellen:

   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
   

   Die Variablen CLUSTER1_CONTEXT und CLUSTER2_CONTEXT werden im Abschnitt Erforderliche benutzerdefinierte Ressourcen installieren definiert.

2. Wenden Sie das Manifest auf jeden Cluster an:

   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. Erlauben Sie dem Dienstkonto custom-metrics-stackdriver-adapter, Cloud Monitoring-Messwerte zu lesen:

   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
   

   Ersetzen Sie PROJECT_ID durch Ihre Projekt-ID.

4. Speichern Sie folgendes Manifest in einer Datei mit dem Namen 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. Wenden Sie das Manifest auf beide Cluster an:

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

6. Speichern Sie folgendes Manifest in einer Datei mit dem Namen 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. Wenden Sie das Manifest auf beide Cluster an:

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

Deployment prüfen

1. Rufen Sie die IP-Adresse des Gateways ab:

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

   Die Variable CLUSTER1_CONTEXT wird im Abschnitt Erforderliche benutzerdefinierte Ressourcen installieren definiert.

2. Starten Sie eine interaktive sh-Sitzung in einem temporären Pod:

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

   Die Variable CLUSTER1_CONTEXT wird im Abschnitt Erforderliche benutzerdefinierte Ressourcen installieren definiert.

3. Senden Sie eine Testanfrage aus dem 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
   }'
   

   Ersetzen Sie GW_IP durch die Gateway-IP-Adresse aus dem vorherigen Schritt.

Gateway-Lasttest durchführen

1. Wenden Sie mit einem Load Generator im selben VPC-Netzwerk eine anhaltende Last auf die Gateway-IP-Adresse an.

2. Beginnen Sie mit einer moderaten Last, die die bevorzugte Region (us-east4) voraussichtlich bewältigen kann.

3. Erhöhen Sie die Anforderungsrate oder Nebenläufigkeit Ihres Lasttests schrittweise.

4. Beobachten Sie das System während des Lasttests in der Cloud de Confiance -Konsole oder mit kubectl:

   • Pod-Skalierung (HPA): Prüfen Sie die Anzahl der Pods im vllm-llama3-8b-instruct-Deployment in beiden Clustern.
   • Knotenskalierung (Cluster Autoscaler): Überwachen Sie die Anzahl der Knoten in den h100-Knotenpools in beiden Clustern.
   • Benutzerdefinierte Messwerte: Beobachten Sie den Messwert vllm:kv_cache_usage_perc (für vllm-Version v0.10.2 und höher) oder den Messwert vllm:gpu_cache_usage_perc (für vllm-Versionen unter v.0.10.2) im Monitoring für Modell-Server-Bereitstellungen in beiden Clustern.
   • Load-Balancer-Messwerte: Untersuchen Sie die Messwerte für den Load Balancer, der mit der cross-region-gateway in Monitoring verknüpft ist.

Wenn Sie die Last erhöhen, steigt die Auslastung in us-east4. Wenn die HPA im Cluster gke-east horizontal skaliert wird und die durchschnittliche Auslastung sich dem in GCPBackendPolicy definierten Wert maxUtilization (80%) nähert, beginnt der Load Balancer, Anfragen an den Cluster gke-west in europe-west3 weiterzuleiten.

Nächste Schritte

• Weitere Informationen zur GKE Gateway API
• Weitere Informationen zum GKE Multi-Cluster Inference Gateway
• Weitere Informationen zu Multi-Cluster-Ingress