Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

Multi-Cluster-GKE Inference Gateway einrichten

Autopilot Standard

In diesem Dokument wird beschrieben, wie Sie das Multi-Cluster-GKE-Inference Gateway (Google Kubernetes Engine) einrichten, um Ihre KI-/ML-Inferenzarbeitslasten intelligent auf mehrere GKE-Cluster zu verteilen, die sich in verschiedenen Regionen befinden können. Bei dieser Einrichtung werden die Gateway API, Multi-Cluster-Ingress und benutzerdefinierte Ressourcen wie InferencePool und InferenceObjective verwendet, um die Skalierbarkeit zu verbessern, Hochverfügbarkeit zu gewährleisten und die Ressourcennutzung für Ihre Bereitstellungen zur Modellbereitstellung zu optimieren.

Um dieses Dokument zu verstehen, sollten Sie mit Folgendem vertraut sein:

KI‑/ML-Orchestrierung in GKE.
Terminologie für generative KI
GKE-Netzwerkkonzepte, einschließlich:
Load-Balancing in Google Cloud, insbesondere die Interaktion von Load Balancern mit GKE.

Dieses Dokument richtet sich an die folgenden Personen:

ML-Entwickler, Plattformadministratoren und ‑operatoren oder Daten- und KI-Spezialisten, die die Containerorchestrierungsfunktionen von GKE zum Bereitstellen von KI‑/ML-Arbeitslasten verwenden möchten.
Cloud-Architekten oder Netzwerkspezialisten, die mit GKE-Netzwerken interagieren.

Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die wir inGoogle Cloud Inhalten verweisen, finden Sie unter Häufig verwendete GKE Enterprise-Nutzerrollen und -Aufgaben.

Hinweis

Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:

Aktivieren Sie die Google Kubernetes Engine API.

Google Kubernetes Engine API aktivieren

Wenn Sie die Google Cloud CLI für diese Aufgabe verwenden möchten, müssen Sie die gcloud CLI installieren und dann initialisieren. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit dem Befehl gcloud components update ab. Ältere gcloud CLI-Versionen unterstützen möglicherweise nicht die Ausführung der Befehle in diesem Dokument.
Hinweis: Legen Sie für vorhandene Installationen der gcloud CLI das compute/region-Attribut fest. Wenn Sie hauptsächlich zonale Cluster verwenden, legen Sie stattdessen compute/zone fest. Wenn Sie einen standardmäßigen Speicherort festlegen, können Sie in der gcloud CLI Fehler wie diesen vermeiden: One of [--zone, --region] must be supplied: Please specify location. Bei bestimmten Befehlen müssen Sie möglicherweise den Speicherort angeben, wenn er sich von dem von Ihnen festgelegten Standard unterscheidet.

Aktivieren Sie die Compute Engine API, die Kubernetes Engine API, Model Armor und die Network Services API.

Rufen Sie Zugriff auf APIs aktivieren auf und folgen Sie der Anleitung.
Aktivieren Sie die Autoscaling API.

Rufen Sie die Autoscaling API auf und folgen Sie der Anleitung.
Aktivieren Sie die GKE Hub API.

Rufen Sie die GKE Hub API auf und folgen Sie der Anleitung.

Alternativ können Sie die Google Cloud CLI verwenden:
```
gcloud services enable gkehub.googleapis.com --project=PROJECT_ID
```
Voraussetzungen für Hugging Face:
- Erstellen Sie ein Hugging Face-Konto, falls Sie noch keines haben.
- Beantragen Sie den Zugriff auf das Qwen3-32B-Modell auf Hugging Face und warten Sie auf die Genehmigung.
- Unterzeichnen Sie die Lizenz-Einwilligungsvereinbarung auf der Seite des Modells auf Hugging Face.
- Generieren Sie ein Hugging Face-Zugriffstoken mit mindestens Read-Berechtigungen.

Voraussetzungen

Prüfen Sie, ob Ihr Projekt ein ausreichendes Kontingent für H100-GPUs hat. Weitere Informationen finden Sie unter GPU-Kontingent planen und Zuteilungskontingente.
Verwenden Sie die GKE-Version 1.34.1-gke.1127000 oder höher.
Verwenden Sie die gcloud CLI-Version 480.0.0 oder höher.
Die Dienstkonten Ihrer Knoten müssen Berechtigungen zum Schreiben von Messwerten in die Autoscaling API haben.
Sie benötigen die folgenden IAM-Rollen für das Projekt: roles/container.admin und roles/iam.serviceAccountAdmin.
Alle Cluster, die Sie bei der Flotte registrieren, einschließlich des Konfigurationsclusters, müssen sich im selben VPC-Netzwerk befinden. Multi-Cluster-Gateways unterstützen kein Load Balancing über Cluster in verschiedenen VPC-Netzwerken hinweg.

Multiport- und NEG-Limits

Wenn Sie InferencePool-Ressourcen mit mehreren Ports in einer Multi-Cluster-Einrichtung bereitstellen, beachten Sie das NEG-Limit für Backend-Dienste Google Cloud . Für jeden Port in jeder Zone wird eine eigene NEG erstellt. Beispiel: Ein regionaler Cluster mit drei Zonen und einem InferencePool, der mit acht Ports konfiguriert ist, verwendet 24 NEGs. Da ein Backend-Dienst auf 50 NEGs beschränkt ist, können Sie diesen spezifischen InferencePool nur aus maximal zwei Clustern aggregieren, bevor das Limit erreicht wird.

Multi-Cluster-Inference-Gateway einrichten

So richten Sie das Multi-Cluster-GKE Inference Gateway ein:

Cluster und Knotenpools erstellen

Um Ihre KI-/ML-Inferenzarbeitslasten zu hosten und regionsübergreifendes Load-Balancing zu ermöglichen, erstellen Sie zwei GKE-Cluster in verschiedenen Regionen, jeweils mit einem H100-GPU-Knotenpool.

Ersten Cluster erstellen:
```
gcloud container clusters create CLUSTER_1_NAME \
    --region LOCATION \
    --project=PROJECT_ID \
    --gateway-api=standard \
    --release-channel "rapid" \
    --cluster-version=GKE_VERSION \
    --machine-type="MACHINE_TYPE" \
    --disk-type="DISK_TYPE" \
    --enable-managed-prometheus --monitoring=SYSTEM,DCGM \
    --hpa-profile=performance \
    --async # Allows the command to return immediately
```
Ersetzen Sie Folgendes:
- CLUSTER_1_NAME: Der Name des ersten Clusters, z. B. gke-west.
- LOCATION: die Region für den ersten Cluster, z. B. europe-west3.
- PROJECT_ID: Ihre Projekt-ID.
- 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.
Hinweis: Mit dem Flag --async wird der Befehl sofort zurückgegeben, während GKE den Cluster im Hintergrund erstellt. Der nachfolgende get-credentials-Befehl wartet, bis der Cluster vollständig bereitgestellt wurde.
Erstellen Sie einen H100-Knotenpool für den ersten Cluster:
```
gcloud container node-pools create NODE_POOL_NAME \
    --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 \
    --async # Allows the command to return immediately
```
Ersetzen Sie Folgendes:
- NODE_POOL_NAME: der Name des Knotenpools, z. B. h100.
- 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.
Hinweis: Mit dem Flag --spot wird ein Spot-VM-Knotenpool erstellt, der vorzeitig beendet werden kann. Spot-VMs eignen sich oft für KI/ML-Inferenzarbeitslasten, da sie erhebliche Kosteneinsparungen bieten und Inferenzaufgaben oft so konzipiert werden können, dass sie unempfindlich gegenüber Unterbrechungen sind.
Rufen Sie die Anmeldedaten ab:
```
gcloud container clusters get-credentials CLUSTER_1_NAME \
    --location CLUSTER_1_ZONE \
    --project=PROJECT_ID
```
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.
Erstellen Sie im ersten Cluster ein Secret für das Hugging Face-Token:
```
kubectl create secret generic hf-token \
    --from-literal=token=HF_TOKEN
```
Ersetzen Sie HF_TOKEN durch Ihr Hugging Face-Zugriffstoken.
Erstellen Sie den zweiten Cluster in einer anderen Region als den ersten Cluster:
```
gcloud container clusters create gke-east --region LOCATION \
    --project=PROJECT_ID \
    --gateway-api=standard \
    --release-channel "rapid" \
    --cluster-version=GKE_VERSION \
    --machine-type="MACHINE_TYPE" \
    --disk-type="DISK_TYPE" \
    --enable-managed-prometheus \
    --monitoring=SYSTEM,DCGM \
    --hpa-profile=performance \
    --async # Allows the command to return immediately while the
cluster is created in the background.
```
Ersetzen Sie Folgendes:
- LOCATION: Die Region für den zweiten Cluster. Diese muss sich von der Region des ersten Clusters unterscheiden. Beispiel: us-east4.
- PROJECT_ID: Ihre Projekt-ID.
- 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.
Hinweis :Damit regionenübergreifendes Load Balancing aktiviert werden kann, muss sich der zweite Cluster in einer anderen Region als der erste Cluster befinden.

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 \
    --async # Allows the command to return immediately

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.

Rufen Sie für den zweiten Cluster Anmeldedaten ab und erstellen Sie ein Secret für das Hugging Face-Token:
```
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:
- CLUSTER_2_NAME: Der Name des zweiten Clusters, z. B. gke-east.
- CLUSTER_2_ZONE: die Zone für den zweiten Cluster, z. B. us-east4-a.
- PROJECT_ID: Ihre Projekt-ID.
- HF_TOKEN: Ihr Hugging Face-Zugriffstoken.

Cluster bei einer Flotte registrieren

Wenn Sie Multi-Cluster-Funktionen wie das Multi-Cluster-GKE-Inference-Gateway aktivieren möchten, registrieren Sie Ihre Cluster bei einer Flotte.

Legen Sie die Überschreibung des API-Endpunkt fest, um mTLS-Probleme bei der Registrierung zu vermeiden.
```
gcloud config set api_endpoint_overrides/container https://container.googleapis.com/
```
Registrieren Sie beide 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:
- 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.
- PROJECT_ID: Ihre Projekt-ID.
- CLUSTER_2_NAME: Der Name des zweiten Clusters, z. B. gke-east.
- CLUSTER_2_ZONE: Die Zone für den zweiten Cluster, z. B. us-east4-a.
Wenn Sie einem einzelnen Gateway erlauben möchten, den Traffic über mehrere Cluster hinweg zu verwalten, 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:
- PROJECT_ID: Ihre Projekt-ID.
- CLUSTER_1_NAME: Der Name des ersten Clusters, z. B. gke-west.

Nur-Proxy-Subnetze erstellen

Erstellen Sie für ein internes Gateway in jeder Region ein Nur-Proxy-Subnetz. Die Envoy-Proxys des internen Gateways verwenden diese dedizierten Subnetze, um Traffic innerhalb Ihres VPC-Netzwerk zu verarbeiten.

Warnung: Google Cloud lässt nur ein Nur-Proxy-Subnetz pro Region in jedem VPC-Netzwerk 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. Wenn Sie ein regionales Nur-Proxy-Subnetz löschen, wirkt sich das auf alle regionalen Envoy-basierten Load-Balancer in dieser Region aus, die es verwenden. Planen Sie die Änderung daher entsprechend.

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=10.0.0.0/23 \
    --project=PROJECT_ID

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=10.5.0.0/23 \
    --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.
CLUSTER_2_REGION: die Region für den zweiten Cluster, z. B. us-east4.

Erforderliche CustomResourceDefinitions installieren

Das Multi-Cluster-GKE Inference Gateway verwendet benutzerdefinierte Ressourcen wie InferencePool und InferenceObjective. Der GKE Gateway API-Controller verwaltet die CustomResourceDefinition „InferencePool“. Sie müssen die InferenceObjective-CustomResourceDefinition, die sich in der Alpha-Phase befindet, jedoch manuell in Ihren Clustern installieren.

Kontextvariablen für Ihre Cluster definieren:
```
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.

Installieren Sie die CustomResourceDefinition „InferenceObjective“ auf beiden Clustern:

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/gateway-api-inference-extension/v1.5.0/config/crd/bases/inference.networking.x-k8s.io_inferenceobjectives.yaml --context=$CLUSTER1_CONTEXT

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/gateway-api-inference-extension/v1.5.0/config/crd/bases/inference.networking.x-k8s.io_inferenceobjectives.yaml --context=$CLUSTER2_CONTEXT

Ressourcen in den Zielclustern bereitstellen

Damit Ihre KI-/ML-Inferenzarbeitslasten in jedem Cluster verfügbar sind, stellen Sie die erforderlichen Ressourcen wie die Modell-Server und die benutzerdefinierten Ressourcen InferenceObjective bereit.

Hinweis: In den Beispielen in diesem Dokument wird vLLM verwendet. Das Multi-Cluster-Inference-Gateway ist jedoch unabhängig von der Modell-Server-Plattform und funktioniert auch mit anderen Modell-Servern wie SGLang. Wenn Sie einen anderen Modellserver verwenden, passen Sie die folgenden Einstellungen an:

Bereitstellungsport Legen Sie den InferencePool-Zielport, den HealthCheckPolicy-Port und den AutoscalingMetric-Endpunktport auf den Bereitstellungsport Ihres Modell-Servers fest. SGLang wird beispielsweise standardmäßig über Port 30000 statt über Port 8000 bereitgestellt.
Messwertnamen: Messwertnamen sind für jeden Modellserver spezifisch. SGLang meldet beispielsweise die KV-Cache-Auslastung als Messwert sglang:token_usage anstelle des Messwerts vllm:kv_cache_usage_perc. Ordnen Sie den Messwert Ihres Modell-Servers dem Exportnamen kv-cache in der Ressource AutoscalingMetric zu. Für die benutzerdefinierte Messwertextraktion für andere Modell-Server als vLLM ist ein kompatibles EPP-Image (Endpoint Picker) erforderlich. Verwenden Sie die aktuelle unterstützte Chart-Version.
Modellbereitstellung auf mehreren Knoten. Wenn sich ein Modellreplikat über mehrere Knoten erstreckt (z. B. wenn Sie die LeaderWorkerSet API zum Bereitstellen eines großen Modells verwenden), stellt nur der Leader-Pod (Rang 0) die API bereit. Konfigurieren Sie den Selektor InferencePool modelServers.matchLabels so, dass er nur mit Leader-Pods übereinstimmt, z. B. durch Hinzufügen des Labels apps.kubernetes.io/pod-index: "0". Wenn die Auswahl auch mit Worker-Pods übereinstimmt, leitet das Gateway Anfragen an Pods weiter, die sie nicht verarbeiten können. Diese Anfragen schlagen mit dem HTTP-Statuscode 404 Not Found fehl.

Stellen Sie die Modellserver in beiden Clustern bereit:

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

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

Stellen Sie die InferenceObjective-Ressourcen in beiden Clustern bereit. Speichern Sie das folgende Beispielmanifest 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: vllm-qwen3-32b
    group: "inference.networking.k8s.io"

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
```
Ersetzen Sie Folgendes:
- $CLUSTER1_CONTEXT: Der Kontext für den ersten Cluster, z. B. gke_my-project_europe-west3-c_gke-west.
- $CLUSTER2_CONTEXT: Der Kontext für den zweiten Cluster, z. B. gke_my-project_us-east4-a_gke-east.

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

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

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

In den vorherigen Befehlen wird die Version v1.5.0 des Helm-Diagramms verwendet, da dies eine empfohlene Version für diese Einrichtung ist. Mit dem Helm-Diagramm werden auch eine benutzerdefinierte GCPBackendPolicy-Ressource und eine benutzerdefinierte HealthCheckPolicy-Ressource installiert, die für die Verwendung in einem einzelnen Cluster vorgesehen sind.

In Version v1.1.0 des InferencePool-Helm-Diagramms wird das Flag --set inferencePool.targetPortNumber möglicherweise ignoriert und der Zielport wird standardmäßig auf 8000 gesetzt. Wenn Ihr Modell-Server einen anderen Port überwacht (z. B. wird SGLang standardmäßig über Port 30000 bereitgestellt), prüfen Sie den Port nach der Installation:

kubectl get inferencepool POOL_NAME -o jsonpath='{.spec.targetPorts}' \
    --context=CLUSTER_CONTEXT

Wenn der Port falsch ist, patchen Sie die benutzerdefinierte Ressource InferencePool, bevor Sie sie exportieren:

kubectl patch inferencepool POOL_NAME --type=merge \
    -p '{"spec":{"targetPorts":[{"number":TARGET_PORT}]}}' \
    --context=CLUSTER_CONTEXT

Markieren Sie die InferencePool-Ressourcen in beiden Clustern als exportiert. Durch diese Annotation wird der InferencePool für den Import durch den Konfigurationscluster verfügbar gemacht. Dies ist ein erforderlicher Schritt für das Multi-Cluster-Routing.
```
kubectl annotate inferencepool vllm-qwen3-32b networking.gke.io/export="True" \
    --context=$CLUSTER1_CONTEXT
```
```
kubectl annotate inferencepool vllm-qwen3-32b networking.gke.io/export="True" \
    --context=$CLUSTER2_CONTEXT
```

Ressourcen im Konfigurationscluster bereitstellen

Wenn Sie definieren möchten, wie Traffic auf die InferencePool-Ressourcen in allen registrierten Clustern weitergeleitet und per Load-Balancing verteilt wird, stellen Sie die Ressourcen Gateway, HTTPRoute und HealthCheckPolicy bereit. Sie stellen diese Ressourcen nur im angegebenen Konfigurationscluster bereit, der in diesem Dokument gke-west ist.

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

---
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
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
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: vllm-qwen3-32b-default
spec:
  parentRefs:
  - name: cross-region-gateway
    kind: Gateway
  rules:
  - backendRefs:
    - group: networking.gke.io
      kind: GCPInferencePoolImport
      name: vllm-qwen3-32b
---
apiVersion: networking.gke.io/v1
kind: HealthCheckPolicy
metadata:
  name: health-check-policy
  namespace: default
spec:
  targetRef:
    group: "networking.gke.io"
    kind: GCPInferencePoolImport
    name: vllm-qwen3-32b
  default:
    config:
      type: HTTP
      httpHealthCheck:
        requestPath: /health
        port: 8000

Wenden Sie das Manifest an:

kubectl apply -f mcig.yaml --context=$CLUSTER1_CONTEXT

Berichterstellung für benutzerdefinierte Messwerte aktivieren

Um Berichte zu benutzerdefinierten Messwerten zu erstellen und das regionenübergreifende Load Balancing zu verbessern, exportieren Sie Messwerte zur KV-Cache-Nutzung aus allen Clustern. Der Load-Balancer verwendet diese exportierten Daten zur KV-Cache-Nutzung als benutzerdefiniertes Lastsignal. Mit diesem benutzerdefinierten Lastsignal können intelligentere Load-Balancing-Entscheidungen auf Grundlage der tatsächlichen Arbeitslast der einzelnen Cluster getroffen werden.

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-qwen3-32b
  endpoints:
  - port: 8000
    path: /metrics
    metrics:
    - name: vllm:kv_cache_usage_perc # For vLLM versions v0.10.2 and newer
      exportName: kv-cache
    - name: vllm:gpu_cache_usage_perc # For vLLM versions v0.6.2 and newer
      exportName: kv-cache-old

Wenden Sie die Messwertkonfiguration auf beide Cluster an:

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

Load-Balancing-Richtlinie konfigurieren

Konfigurieren Sie eine Load-Balancing-Richtlinie, um die Verteilung von Anfragen für KI-/ML-Inferenz auf Ihre GKE-Cluster zu optimieren. Ein geeigneter Balancing-Modus trägt zu einer effizienten Ressourcennutzung bei, verhindert die Überlastung einzelner Cluster und verbessert die Leistung und Reaktionsfähigkeit Ihrer Inferenzdienste.

Zeitlimits konfigurieren

Wenn Sie davon ausgehen, dass Ihre Anfragen lange dauern, konfigurieren Sie ein längeres Zeitlimit für den Load Balancer. Legen Sie im GCPBackendPolicy das Feld timeoutSec auf mindestens das Doppelte der geschätzten P99-Anfragelatenz fest. Bei Arbeitslasten mit Inferenz für lange Kontexte bei hoher Parallelität benötigen Sie möglicherweise ein Zeitlimit von bis zu 3600 Sekunden. Im folgenden Beispielmanifest wird das Zeitlimit für den Load Balancer auf 600 Sekunden festgelegt.

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
spec:
  targetRef:
    group: "networking.gke.io"
    kind: GCPInferencePoolImport
    name: vllm-qwen3-32b
  default:
    timeoutSec: 600
    balancingMode: CUSTOM_METRICS
    trafficDuration: LONG
    customMetrics:
      - name: gke.named_metrics.kv-cache
        dryRun: false
        maxUtilizationPercent: 60

Weitere Informationen finden Sie unter Einschränkungen für Multi-Cluster-Gateways.

Da sich die Load-Balancing-Modi Benutzerdefinierte Messwerte und In-Flight-Anfragen gegenseitig ausschließen, konfigurieren Sie nur einen dieser Modi in Ihrer GCPBackendPolicy.

Wählen Sie einen Load-Balancing-Modus für Ihre Bereitstellung aus.

Benutzerdefinierte Messwerte

Für ein optimales Load-Balancing sollten Sie mit einer Zielauslastung von 60 % beginnen. Um dieses Ziel zu erreichen, legen Sie maxUtilizationPercent: 60 in der customMetrics-Konfiguration von GCPBackendPolicy fest.

Erstellen Sie eine Datei mit dem Namen backend-policy.yaml und dem folgenden Inhalt, um das Load Balancing basierend auf dem benutzerdefinierten Messwert kv-cache zu aktivieren:

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
spec:
  targetRef:
    group: "networking.gke.io"
    kind: GCPInferencePoolImport
    name: vllm-qwen3-32b
  default:
    balancingMode: CUSTOM_METRICS
    trafficDuration: LONG
    customMetrics:
      - name: gke.named_metrics.kv-cache
        dryRun: false
        maxUtilizationPercent: 60

Wenden Sie die neue Richtlinie an:

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

Aktive Anfragen

Wenn Sie den In-Flight-Balancing-Modus verwenden möchten, schätzen Sie die Anzahl der In-Flight-Anfragen, die jedes Backend verarbeiten kann, und konfigurieren Sie explizit einen Kapazitätswert.

Erstellen Sie eine Datei mit dem Namen backend-policy.yaml und dem folgenden Inhalt, um den Lastenausgleich basierend auf der Anzahl der laufenden Anfragen zu aktivieren:

kind: GCPBackendPolicy
apiVersion: networking.gke.io/v1
metadata:
  name: my-backend-policy
spec:
  targetRef:
    group: "networking.gke.io"
    kind: GCPInferencePoolImport
    name: vllm-qwen3-32b
  default:
    balancingMode: IN_FLIGHT
    trafficDuration: LONG
    maxInFlightRequestsPerEndpoint: 1000
    dryRun: false