GKE Multi-Cluster Inference Gateway einrichten

Autopilot Standard

In diesem Dokument wird beschrieben, wie Sie das GKE-Multi-Cluster-Inference-Gateway (Google Kubernetes Engine) einrichten, um Ihre KI-/ML-Inferenzarbeitslasten intelligent über mehrere GKE-Cluster hinweg auszugleichen, die sich über verschiedene Regionen erstrecken 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 zum Bereitstellen 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:
Load-Balancing inGoogle Cloud, 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 inGoogle Cloud Inhalten verwiesen wird, finden Sie unter Häufig verwendete GKE Enterprise-Nutzerrollen und -Aufgaben.

Hinweise

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 diesen Task 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.
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 Google 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.
Voraussetzungen für Hugging Face:
- Erstellen Sie ein Hugging Face-Konto, falls Sie noch keines haben.
- Beantragen Sie den Zugriff auf das Llama 3.1-Modell auf Hugging Face und erhalten Sie 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 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.

Multi-Cluster-Inference-Gateway einrichten

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

Cluster und Knotenpools erstellen

Wenn Sie Ihre KI-/ML-Inferenzarbeitslasten hosten und regionsübergreifendes Load-Balancing aktivieren möchten, erstellen Sie zwei GKE-Cluster in verschiedenen Regionen, jeweils mit einem H100-GPU-Knotenpool.

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.
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 :Wenn Sie das Flag --spot verwenden, wird ein Knotenpool mit Spot-VMs erstellt, die unterbrochen werden können. 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 Unterbrechungen standhalten.
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.
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. 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.
Hinweis :Damit regionenübergreifendes Load Balancing möglich ist, 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 GKE Multi-Cluster Inference Gateway aktivieren möchten, registrieren Sie Ihre Cluster bei einer Flotte.

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

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

Das GKE Multi-Cluster Inference Gateway verwendet benutzerdefinierte Ressourcen wie InferencePool und InferenceObjective. Der GKE Gateway API-Controller verwaltet die benutzerdefinierte Ressourcendefinition (Custom Resource Definition, CRD) InferencePool. Sie müssen die InferenceObjective-CRD, die sich in der Alphaphase 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 InferenceObjective-CRD in beiden Clustern:

# Copyright 2025 Google LLC
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#      http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: restrict-toleration
spec:
  failurePolicy: Fail
  paramKind:
    apiVersion: v1
    kind: ConfigMap
  matchConstraints:
    # GKE will mutate any pod specifying a CC label in a nodeSelector
    # or in a nodeAffinity with a toleration for the CC node label.
    # Mutation hooks will always mutate the K8s object before validating
    # the admission request.  
    # Pods created by Jobs, CronJobs, Deployments, etc. will also be validated.
    # See https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#admission-control-phases for details
    resourceRules:
    - apiGroups:   [""]
      apiVersions: ["v1"]
      operations:  ["CREATE", "UPDATE"]
      resources:   ["pods"]
  matchConditions:
    - name: 'match-tolerations'
      # Validate only if compute class toleration exists
      # and the CC label tolerated is listed in the configmap.
      expression: > 
        object.spec.tolerations.exists(t, has(t.key) &&
        t.key == 'cloud.google.com/compute-class' &&
        params.data.computeClasses.split('\\n').exists(cc, cc == t.value))
  validations:
    # ConfigMap with permitted namespace list referenced via `params`.
    - expression: "params.data.namespaces.split('\\n').exists(ns, ns == object.metadata.namespace)"
      messageExpression: "'Compute class toleration not permitted on workloads in namespace ' + object.metadata.namespace"

---
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicyBinding
metadata:
  name: restrict-toleration-binding
spec:
  policyName: restrict-toleration
  validationActions: ["Deny"]
  paramRef:
    name: allowed-ccc-namespaces
    namespace: default
    parameterNotFoundAction: Deny
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: allowed-ccc-namespaces
  namespace: default
data:
  # Replace example namespaces in line-separated list below.
  namespaces: |
    foo
    bar
    baz
  # ComputeClass names to monitor with this validation policy.
  # The 'autopilot' and 'autopilot-spot' CCs are present on
  # all NAP Standard and Autopilot clusters.
  computeClasses: |
    MY_COMPUTE_CLASS
    autopilot
    autopilot-spot

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/gateway-api-inference-extension/v1.1.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.1.0/config/crd/bases/inference.networking.x-k8s.io_inferenceobjectives.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.

Ressourcen in den Zielclustern bereitstellen

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

Stellen Sie die Modellserver in beiden Clustern bereit:

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

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/gateway-api-inference-extension/v1.1.0/config/manifests/vllm/gpu-deployment.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 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: llama3-8b-instruct
    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-llama3-8b-instruct \
  --kube-context CLUSTER1_CONTEXT \
  --set inferencePool.modelServers.matchLabels.app=vllm-llama3-8b-instruct \
  --set provider.name=gke \
  --version v1.1.0 \
  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.1.0 \
  oci://registry.k8s.io/gateway-api-inference-extension/charts/inferencepool

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.

Markieren Sie die InferencePool-Ressourcen in beiden Clustern als exportiert. Durch diese Annotation wird InferencePool für den Import durch den Konfigurationscluster verfügbar. Dies ist ein erforderlicher Schritt für das Multi-Cluster-Routing.
```
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
```
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.

Ressourcen im Konfigurationscluster bereitstellen

Um festzulegen, wie Traffic über 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.

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-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
---
apiVersion: networking.gke.io/v1
kind: HealthCheckPolicy
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

Wenden Sie das Manifest an:
```
kubectl apply -f mcig.yaml --context=CLUSTER1_CONTEXT
```
Ersetzen Sie CLUSTER1_CONTEXT durch den Kontext für den ersten Cluster (den Konfigurationscluster), z. B. gke_my-project_europe-west3-c_gke-west.

Berichterstellung für benutzerdefinierte Messwerte aktivieren

Um Berichte zu benutzerdefinierten Messwerten zu erstellen und den regionenübergreifenden Lastenausgleich 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.

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

apiVersion: autoscaling.gke.io/v1beta1
kind: AutoscalingMetric
metadata:
  name: gpu-cache
  namespace: default
spec:
  selector:
    matchLabels:
      app: vllm-llama3-8b-instruct
  endpoints:
  - port: 8000
    path: /metrics
    metrics:
    - name: vllm:kv_cache_usage_perc # 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
```
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.

Load-Balancing-Richtlinie konfigurieren

Um die Verteilung Ihrer KI-/ML-Inferenzanfragen auf Ihre GKE-Cluster zu optimieren, konfigurieren Sie eine Load-Balancing-Richtlinie. Wenn Sie den richtigen Balancing-Modus auswählen, können Sie eine effiziente Ressourcennutzung sicherstellen, eine Überlastung einzelner Cluster verhindern und die Gesamtleistung und Reaktionsfähigkeit Ihrer Inferenzdienste verbessern.

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-llama3-8b-instruct
  default:
    timeoutSec: 100
    balancingMode: CUSTOM_METRICS
    trafficDuration: LONG
    customMetrics:
    - name: gke.named_metrics.kv-cache
      dryRun: false

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 maxUtilization: 60 in der customMetrics-Konfiguration Ihres GCPBackendPolicy fest.

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-llama3-8b-instruct
  default:
    balancingMode: CUSTOM_METRICS
    trafficDuration: LONG
    customMetrics:
      - name: gke.named_metrics.kv-cache
        dryRun: false
        maxUtilization: 60

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.

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-llama3-8b-instruct
  default:
    balancingMode: IN_FLIGHT
    trafficDuration: LONG
    maxInFlightRequestsPerEndpoint: 1000
    dryRun: false

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.

Deployment prüfen

Um den internen Load Balancer zu prüfen, 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 aus Ihrem VPC-Netzwerk zu senden und den internen Load Balancer zu prüfen:

Starten Sie eine interaktive Shell-Sitzung in einem temporären Pod:
```
kubectl run -it --rm --image=curlimages/curl curly --context=CLUSTER1_CONTEXT -- /bin/sh
```
Ersetzen Sie CLUSTER1_CONTEXT durch den Kontext für den ersten Cluster, z. B. gke_my-project_europe-west3-c_gke-west.

Rufen Sie in der neuen Shell die Gateway-IP-Adresse ab und senden Sie eine Testanfrage:

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

curl -i -X POST ${GW_IP}: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
}'

Hier ist ein Beispiel für eine erfolgreiche Antwort:

{
  "id": "cmpl-...",
  "object": "text_completion",
  "created": 1704067200,
  "model": "food-review-1",
  "choices": [
    {
      "text": "The best pizza in the world is subjective, but many argue for Neapolitan pizza...",
      "index": 0,
      "logprobs": null,
      "finish_reason": "length"
    }
  ],
  "usage": {
    "prompt_tokens": 10,
    "completion_tokens": 100,
    "total_tokens": 110
  }
}

GKE Multi-Cluster Inference Gateway einrichten Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Hinweise

Voraussetzungen

Multi-Cluster-Inference-Gateway einrichten

Cluster und Knotenpools erstellen

Cluster bei einer Flotte registrieren

Nur-Proxy-Subnetze erstellen

Erforderliche CRDs installieren

Ressourcen in den Zielclustern bereitstellen

Ressourcen im Konfigurationscluster bereitstellen

Berichterstellung für benutzerdefinierte Messwerte aktivieren

Load-Balancing-Richtlinie konfigurieren

Zeitlimits konfigurieren

Benutzerdefinierte Messwerte

Aktive Anfragen

Deployment prüfen

Nächste Schritte

GKE Multi-Cluster Inference Gateway einrichten