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 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, für hohe Verfügbarkeit zu sorgen und die Ressourcennutzung für Ihre Bereitstellungen für die Bereitstellung von Modellen 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:
  • Dienste
  • GKE Multi-Cluster-Ingress
  • Gateway API
• Load-Balancing inCloud de Confiance, insbesondere die Interaktion von Load-Balancern mit GKE.

Dieses Dokument richtet sich an die folgenden Personen:

• Entwickler für maschinelles Lernen (ML), 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 inCloud de Confiance by S3NS 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.

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 Cloud de Confiance by S3NS . 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.

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.

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
   

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 trägt zur Verbesserung der Leistung und Reaktionsfähigkeit Ihrer Inferenzdienste bei.

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.

Im folgenden Manifest wird das Load-Balancer-Zeitlimit beispielsweise auf 100 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: 100
    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.

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

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