Elastische regionenübergreifende Hochverfügbarkeit konfigurieren

In diesem Dokument wird beschrieben, wie Sie mit dem Google Kubernetes Engine (GKE) Multi-Cluster Inference Gateway und der GKE-Autoscaling-Funktion eine elastische regionsübergreifende Hochverfügbarkeit für KI-Inferenzarbeitslasten 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 Informationen zum 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. Prüfen Sie, ob Sie die IAM-Rollen roles/container.admin und roles/iam.serviceAccountAdmin (Identity and Access Management) für das Projekt haben.

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

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

Cluster und Knotenpools erstellen

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

1. Erstellen Sie den ersten Cluster:

   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 Festplattentyp 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 der Knoten für das Autoscaling im Knotenpool, z. B. 1.
   • MAX_NUM_NODES: die maximale Anzahl der 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 der Knoten für das Autoscaling im Knotenpool, z. B. 1.
   • MAX_NUM_NODES: die maximale Anzahl der Knoten für das Autoscaling im Knotenpool, z. B. 10.

6. Rufen Sie die 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 Folgendes. 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 die Funktion „Multi-Cluster-Ingress“ 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 Mit kann jedes VPC-Netzwerk nur ein Nur-Proxy-Subnetz pro Region haben. Wenn die Zielregion bereits ein Nur-Proxy-Subnetz mit der Einstellung purpose=REGIONAL_MANAGED_PROXY enthält, schlägt das Erstellen des GLOBAL_MANAGED_PROXY-Subnetzes 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 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 Nur-Proxy-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 Nur-Proxy-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 das folgende 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
   

Regionsü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 folgenden 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 auf jeden Cluster an:

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

   Definitionen von 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. Diese Richtlinie definiert, wie Traffic basierend auf benutzerdefinierten Messwerten und regionalen Einstellungen auf Ihre Inferenzpools verteilt wird. Mit der folgenden Konfiguration wird us-east4 als bevorzugte Region festgelegt. Traffic wird nur dann auf andere Regionen verteilt, wenn der benutzerdefinierte Messwert gke.named_metrics.kv-cache in der Region us-east4 eine Auslastung von 80% erreicht.

• 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 folgenden 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 steigende Last bewältigen kann, bevor Traffic auf andere Regionen verteilt wird, müssen Sie das horizontale Pod-Autoscaling (Horizontal Pod Autoscaler, HPA) für Ihre Modellserverbereitstellungen konfigurieren.

Wichtige Konfigurationsprinzipien

• Dieselben benutzerdefinierten Messwerte verwenden: Das HPA sollte so konfiguriert sein, dass es auf der Grundlage derselben benutzerdefinierten Messwerte skaliert wird, die Sie in der GCPBackendPolicy für das Multi-Cluster Inference Gateway verwenden (z. B. vllm:kv_cache_usage_perc). So wird sichergestellt, dass sowohl Load-Balancing- als auch Skalierungsentscheidungen durch dasselbe Signal von Ihren Inferenzservern gesteuert werden. Die von Ihnen 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 vom Load-Balancer als 100% Auslastung interpretiert, was zu unerwartetem Routing-Verhalten führen kann.

• Niedrigeres HPA-Ziel festlegen: Der Zielwert für den Messwert in der HPA Konfiguration muss niedriger als die maxUtilizationPercent Einstellung sein, die in der GCPBackendPolicy definiert ist. Wenn Sie die Zielauslastung des HPA niedriger festlegen (z. B. skaliert das HPA bei einer durchschnittlichen Auslastung von 50 %), kann der Cluster mehr Replikate hinzufügen, bevor der Grenzwert des Load-Balancers (z. B. 80% Auslastung) erreicht wird. So lässt sich die Kapazität in der bevorzugten Region maximieren. Ein niedrigeres Auslastungsziel trägt auch dazu bei, eine vorzeitige Traffic-Verteilung zu verhindern, indem die elastische regionsübergreifende Hochverfügbarkeit für den Fall reserviert wird, dass die aktuelle Region tatsächlich 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 sind im Abschnitt Install the required custom resources 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 das folgende 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 das folgende 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 ist 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 ist im Abschnitt Erforderliche benutzerdefinierte Ressourcen installieren definiert.

3. Senden Sie aus dem curly-Pod eine Testanfrage:

   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.

Lasttest für das Gateway

1. Wenden Sie mit einem Lastgenerator 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) bewältigen kann.

3. Erhöhen Sie allmählich die Anfragerate oder die Parallelität Ihres Lasttests.

4. Beobachten Sie während des Lasttests das System 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): Beobachten 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 0.10.2 und höher) oder den Messwert vllm:gpu_cache_usage_perc (für vLLM-Versionen unter 0.10.2) in Monitoring für Modellserverbereitstellungen in beiden Clustern.
   • Load-Balancer-Messwerte: Untersuchen Sie die Messwerte für den Load-Balancer, der mit dem cross-region-gateway in Monitoring verknüpft ist.

Wenn Sie die Last erhöhen, steigt die Auslastung in us-east4. Wenn das HPA im gke-east-Cluster skaliert und die durchschnittliche Auslastung den in der GCPBackendPolicy definierten Wert maxUtilization (80%) erreicht, leitet der Load-Balancer Anfragen an den gke-west-Cluster in europe-west3 weiter.

Nächste Schritte

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