Multi-Cluster-GKE Inference Gateway einrichten

In diesem Dokument wird beschrieben, wie Sie das Multi-Cluster-GKE-Inference Gateway (Google Kubernetes Engine) einrichten, um Ihre KI/ML-Inferenzarbeitslasten intelligent über mehrere GKE-Cluster hinweg auszugleichen, 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, für Hochverfügbarkeit zu sorgen und die Ressourcennutzung für Ihre Bereitstellungen für die Modellbereitstellung zu optimieren.

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

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. In früheren gcloud CLI-Versionen werden die Befehle in diesem Dokument möglicherweise nicht unterstützt.

  • 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 lassen Sie ihn genehmigen.
    • Unterzeichnen Sie die Lizenz-Einwilligungsvereinbarung auf der Seite des Modells bei 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 die Berechtigung haben, Messwerte in die Autoscaling API zu schreiben.
  • Sie benötigen die folgenden IAM-Rollen für das Projekt: roles/container.admin und roles/iam.serviceAccountAdmin.
  • Alle Cluster, die Sie in 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 Back-End-Dienste Google Cloud . Für jeden Port in jeder Zone wird eine eigene NEG erstellt. Ein regionaler Cluster mit drei Zonen und einem InferencePool, der mit acht Ports konfiguriert ist, verwendet beispielsweise 24 NEGs. Da ein Backend-Dienst auf 50 NEGs beschränkt ist, können Sie diesen InferencePool nur aus maximal zwei Clustern zusammenfassen, bevor Sie das Limit erreichen.

Multi-Cluster-Inference Gateway einrichten

So richten Sie das GKE Inference Gateway für mehrere Cluster ein:

Cluster und Knotenpools erstellen

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

  1. Erstellen Sie den ersten Cluster:

    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.

  2. 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.

  3. Anmeldedaten abrufen:

    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.

  4. 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.

  5. 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. Dies muss eine andere Region als der erste Cluster sein. 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.

  6. 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.

  7. 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.

  1. Legen Sie die Überschreibung des API-Endpunkt fest, um mTLS-Probleme während der Registrierung zu vermeiden.

    gcloud config set api_endpoint_overrides/container https://container.googleapis.com/

  2. 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.

  3. Damit ein einzelnes Gateway den Traffic über mehrere Cluster hinweg verwalten kann, aktivieren Sie das Multi-Cluster-Ingress-Feature und weisen Sie einen Konfigurationscluster zu:

    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 in Ihrem VPC-Netzwerk zu verarbeiten.

Warnung:Mit Google Cloud ist nur ein Nur-Proxy-Subnetz pro Region in jedem VPC-Netzwerk zulässig. 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. 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.

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

  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=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.

  1. 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.

  2. Installieren Sie die CustomResourceDefinition „InferenceObjective“ in 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 Modellserver und benutzerdefinierten InferenceObjective-Ressourcen bereit.

Hinweis:In den Beispielen in diesem Dokument wird vLLM verwendet. Das Multi-Cluster-Inference Gateway ist jedoch unabhängig von der Modellserverplattform und funktioniert auch mit anderen Modellservern 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 Modellservers fest. SGLang wird beispielsweise standardmäßig über Port 30000 statt über Port 8000 bereitgestellt.
  • Messwertnamen: Messwertnamen sind für jeden Modellserver spezifisch. In SGLang wird die KV-Cache-Auslastung beispielsweise als Messwert sglang:token_usage anstelle des Messwerts vllm:kv_cache_usage_perc gemeldet. Ordnen Sie die Messwerte Ihres Modellservers dem Exportnamen kv-cache in der Ressource AutoscalingMetric zu. Für das Extrahieren benutzerdefinierter Messwerte für andere Modellserver als vLLM ist ein kompatibles EPP-Image (Endpoint Picker) erforderlich. Verwenden Sie die aktuelle unterstützte Chart-Version.
  • Modellbereitstellung für mehrere Knoten: Wenn sich eine Modellreplik über mehrere Knoten erstreckt (z. B. wenn Sie die LeaderWorkerSet API zum Bereitstellen eines großen Modells verwenden), wird die API nur vom Leader-Pod (Rang 0) bereitgestellt. Konfigurieren Sie den InferencePool-modelServers.matchLabels-Selektor so, dass er nur Leader-Pods entspricht, z. B. durch Hinzufügen des Labels apps.kubernetes.io/pod-index: "0". Wenn der Selektor auch mit Worker-Pods übereinstimmt, leitet das Gateway Anfragen an Pods weiter, die sie nicht verarbeiten können. Diese Anfragen schlagen dann mit dem HTTP-Statuscode 404 Not Found fehl.

  1. 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

  2. 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"

  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

    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.

  4. 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 Version v1.5.0 des Helm-Charts verwendet, da sie für diese Einrichtung empfohlen wird. 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 Modellserver einen anderen Port überwacht (z. B. wird SGLang standardmäßig über Port 30000 bereitgestellt), überprü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

  5. 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

Um zu definieren, 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 dafür vorgesehenen Konfigurationscluster bereit, der in diesem Dokument gke-west ist.

  1. 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

  2. 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 aktivieren und das regionenübergreifende Load Balancing zu verbessern, exportieren Sie Messwerte zur KV-Cache-Nutzung aus allen Clustern. Der Load-Balancer verwendet diese exportierten KV-Cache-Nutzungsdaten als benutzerdefiniertes Lastsignal. Mit diesem benutzerdefinierten Lastsignal können intelligentere Load-Balancing-Entscheidungen auf Grundlage der tatsächlichen Arbeitslast jedes Clusters getroffen werden.

  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-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

  2. 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 eine Überlastung einzelner Cluster und verbessert die Leistung und Reaktionsfähigkeit Ihrer Inferenzdienste.

Zeitlimits konfigurieren

Wenn Ihre Anfragen voraussichtlich lange dauern, konfigurieren Sie ein längeres Zeitlimit für den Load Balancer. Legen Sie im GCPBackendPolicy das Feld timeoutSec auf mindestens das Doppelte Ihrer 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 Manifest wird das Zeitlimit für den Load Balancer beispielsweise 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 Laufende 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 Ihres GCPBackendPolicy fest.

  1. Erstellen Sie eine Datei mit dem Namen backend-policy.yaml und dem folgenden Inhalt, um den Lastenausgleich basierend auf der 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

  2. 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.

  1. 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

  2. Wenden Sie die neue Richtlinie an:

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

Deployment prüfen

Um den internen Load Balancer zu testen, müssen Sie Anfragen aus Ihrem VPC-Netzwerk senden, da interne Load Balancer private IP-Adressen verwenden. Führen Sie einen temporären Pod in einem der Cluster aus, um Anfragen von Ihrem VPC-Netzwerk zu senden und den internen Load Balancer zu prüfen:

  1. Rufen Sie in der neuen Shell die IP-Adresse des Gateways ab:

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

  2. Senden Sie eine Testanfrage von einem temporären Pod im Cluster:

    kubectl run -it --rm --image=curlimages/curl curly --context=$CLUSTER1_CONTEXT -- \
  curl -i -X POST ${GW_IP}:80/v1/completions -H 'Content-Type: application/json' -d '{
  "model": "Qwen/Qwen3-32B",
  "prompt": "What is the best pizza in the world?",
  "max_tokens": 100,
  "temperature": 0
  }'

Nächste Schritte