Configura il gateway di inferenza multi-cluster GKE

Questo documento descrive come configurare il gateway di inferenza multi-cluster Google Kubernetes Engine (GKE) per bilanciare il carico in modo intelligente dei tuoi workload di inferenza AI/ML su più cluster GKE, che possono estendersi su diverse regioni. Questa configurazione utilizza l'API Gateway, Ingress multi-cluster e risorse personalizzate come InferencePool e InferenceObjective per migliorare la scalabilità, contribuire a garantire l'alta disponibilità e ottimizzare l'utilizzo delle risorse per i deployment di servizio del modello.

Per comprendere questo documento, devi avere familiarità con quanto segue:

Questo documento è destinato alle seguenti figure:

  • ML engineer, amministratori e operatori della piattaforma o specialisti di dati e AI che vogliono utilizzare le funzionalità di orchestrazione dei container di GKE per la pubblicazione di workload di AI/ML.
  • Cloud Architect o specialisti di networking che interagiscono con il networking GKE.

Per scoprire di più sui ruoli comuni e sulle attività di esempio a cui viene fatto riferimento nei contenuti diGoogle Cloud , consulta la pagina Ruoli utente e attività comuni di GKE Enterprise.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti operazioni:

  • Attiva l'API Google Kubernetes Engine.
    • Attiva l'API Google Kubernetes Engine
  • Se vuoi utilizzare Google Cloud CLI per questa attività, installala e poi inizializza gcloud CLI. Se hai già installato gcloud CLI, scarica l'ultima versione eseguendo il comando gcloud components update. Le versioni precedenti di gcloud CLI potrebbero non supportare l'esecuzione dei comandi in questo documento.

  • Abilita l'API Compute Engine, l'API Google Kubernetes Engine, Model Armor e l'API Network Services.

    Vai ad Abilita l'accesso alle API e segui le istruzioni.

  • Abilita l'API Autoscaling.

    Vai all'API Autoscaling e segui le istruzioni.

  • Prerequisiti di Hugging Face:

    • Crea un account Hugging Face se non ne hai già uno.
    • Richiedi e ottieni l'approvazione per l'accesso al modello Llama 3.1 su Hugging Face.
    • Firma il contratto di consenso alla licenza nella pagina del modello su Hugging Face.
    • Genera un token di accesso a Hugging Face con almeno le autorizzazioni Read.

Requisiti

  • Assicurati che il tuo progetto disponga di una quota sufficiente per le GPU H100. Per saperne di più, consulta Pianificare la quota di GPU e Quote di allocazione.
  • Utilizza GKE 1.34.1-gke.1127000 o versioni successive.
  • Utilizza gcloud CLI versione 480.0.0 o successive.
  • I service account dei nodi devono disporre delle autorizzazioni per scrivere metriche nell'API Autoscaling.
  • Devi disporre dei seguenti ruoli IAM nel progetto: roles/container.admin e roles/iam.serviceAccountAdmin.

Configura il gateway di inferenza multi-cluster

Per configurare il gateway di inferenza multicluster GKE:

Crea cluster e node pool

Per ospitare i workload di inferenza AI/ML e abilitare il bilanciamento del carico cross-region, crea due cluster GKE in regioni diverse, ognuno con un pool di nodi GPU H100.

  1. Crea il primo 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

    Sostituisci quanto segue:

    • CLUSTER_1_NAME: il nome del primo cluster, ad esempio gke-west.
    • LOCATION: la regione del primo cluster, ad esempio europe-west3.
    • PROJECT_ID: il tuo ID progetto.
    • GKE_VERSION: la versione di GKE da utilizzare, ad esempio 1.34.1-gke.1127000.
    • MACHINE_TYPE: il tipo di macchina per i nodi del cluster, ad esempio c2-standard-16.
    • DISK_TYPE: il tipo di disco per i nodi del cluster, ad esempio pd-standard.

  2. Crea un pool di nodi H100 per il primo 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

    Sostituisci quanto segue:

    • NODE_POOL_NAME: il nome del pool di nodi, ad esempio h100.
    • PROJECT_ID: il tuo ID progetto.
    • CLUSTER_1_ZONE: la zona del primo cluster, ad esempio europe-west3-c.
    • CLUSTER_1_NAME: il nome del primo cluster, ad esempio gke-west.
    • NODE_POOL_MACHINE_TYPE: il tipo di macchina per il pool di nodi, ad esempio a3-highgpu-2g.
    • NUM_NODES: il numero di nodi nel pool di nodi, ad esempio 3.

  3. Recupera le credenziali:

    gcloud container clusters get-credentials CLUSTER_1_NAME \
    --location CLUSTER_1_ZONE \
    --project=PROJECT_ID

    Sostituisci quanto segue:

    • PROJECT_ID: il tuo ID progetto.
    • CLUSTER_1_NAME: il nome del primo cluster, ad esempio gke-west.
    • CLUSTER_1_ZONE: la zona del primo cluster, ad esempio europe-west3-c.

  4. Nel primo cluster, crea un secret per il token Hugging Face:

    kubectl create secret generic hf-token \
    --from-literal=token=HF_TOKEN

    Sostituisci HF_TOKEN con il tuo token di accesso a Hugging Face.

  5. Crea il secondo cluster in una regione diversa dal primo:

    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.

    Sostituisci quanto segue:

    • LOCATION: la regione del secondo cluster. Deve essere una regione diversa da quella del primo cluster. Ad esempio, us-east4.
    • PROJECT_ID: il tuo ID progetto.
    • GKE_VERSION: la versione di GKE da utilizzare, ad esempio 1.34.1-gke.1127000.
    • MACHINE_TYPE: il tipo di macchina per i nodi del cluster, ad esempio c2-standard-16.
    • DISK_TYPE: il tipo di disco per i nodi del cluster, ad esempio pd-standard.

  6. Crea un pool di nodi H100 per il secondo 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

    Sostituisci quanto segue:

    • PROJECT_ID: il tuo ID progetto.
    • CLUSTER_2_ZONE: la zona del secondo cluster, ad esempio us-east4-a.
    • CLUSTER_2_NAME: il nome del secondo cluster, ad esempio gke-east.
    • NODE_POOL_MACHINE_TYPE: il tipo di macchina per il pool di nodi, ad esempio a3-highgpu-2g.
    • NUM_NODES: il numero di nodi nel pool di nodi, ad esempio 3.

  7. Per il secondo cluster, recupera le credenziali e crea un secret per il token Hugging Face:

    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

    Sostituisci quanto segue:

    • CLUSTER_2_NAME: il nome del secondo cluster, ad esempio gke-east.
    • CLUSTER_2_ZONE: la zona del secondo cluster, ad esempio us-east4-a.
    • PROJECT_ID: il tuo ID progetto.
    • HF_TOKEN: il token di accesso a Hugging Face.

Registra i cluster in un parco risorse

Per abilitare le funzionalità multi-cluster, come GKE Multi-cluster Inference Gateway, registra i cluster in un parco risorse.

  1. Registra entrambi i cluster nel parco risorse del tuo progetto:

    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

    Sostituisci quanto segue:

    • CLUSTER_1_NAME: il nome del primo cluster, ad esempio gke-west.
    • CLUSTER_1_ZONE: la zona del primo cluster, ad esempio europe-west3-c.
    • PROJECT_ID: il tuo ID progetto.
    • CLUSTER_2_NAME: il nome del secondo cluster, ad esempio gke-east.
    • CLUSTER_2_ZONE: la zona del secondo cluster, ad esempio us-east4-a.

  2. Per consentire a un singolo gateway di gestire il traffico su più cluster, abilita la funzionalità Ingress multi-cluster e designa un cluster di configurazione:

    gcloud container fleet ingress enable \
    --config-membership=projects/PROJECT_ID/locations/global/memberships/CLUSTER_1_NAME

    Sostituisci quanto segue:

    • PROJECT_ID: il tuo ID progetto.
    • CLUSTER_1_NAME: il nome del primo cluster, ad esempio gke-west.

Crea subnet solo proxy

Per un gateway interno, crea una subnet solo proxy in ogni regione. I proxy Envoy del gateway interno utilizzano queste subnet dedicate per gestire il traffico all'interno della tua rete VPC.

  1. Crea una subnet nella regione del primo cluster:

    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. Crea una subnet nella regione del secondo cluster:

    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

    Sostituisci quanto segue:

    • PROJECT_ID: il tuo ID progetto.
    • CLUSTER_1_REGION: la regione del primo cluster, ad esempio europe-west3.
    • CLUSTER_2_REGION: la regione per il secondo cluster, ad esempio us-east4.

Installa le CRD richieste

GKE Multi-cluster Inference Gateway utilizza risorse personalizzate come InferencePool e InferenceObjective. Il controller API GKE Gateway gestisce la definizione di risorsa personalizzata (CRD) InferencePool. Tuttavia, devi installare manualmente la InferenceObjective CRD, che è in versione alpha, sui tuoi cluster.

  1. Definisci le variabili di contesto per i tuoi cluster:

    CLUSTER1_CONTEXT="gke_PROJECT_ID_CLUSTER_1_ZONE_CLUSTER_1_NAME"
CLUSTER2_CONTEXT="gke_PROJECT_ID_CLUSTER_2_ZONE_CLUSTER_2_NAME"

    Sostituisci quanto segue:

    • PROJECT_ID: il tuo ID progetto.
    • CLUSTER_1_ZONE: la zona del primo cluster, ad esempio europe-west3-c.
    • CLUSTER_1_NAME: il nome del primo cluster, ad esempio gke-west.
    • CLUSTER_2_ZONE: la zona del secondo cluster, ad esempio us-east4-a.
    • CLUSTER_2_NAME: il nome del secondo cluster, ad esempio gke-east.

  2. Installa la CRD InferenceObjective su entrambi i cluster:

    # 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

    Sostituisci quanto segue:

    • CLUSTER1_CONTEXT: il contesto per il primo cluster, ad esempio gke_my-project_europe-west3-c_gke-west.
    • CLUSTER2_CONTEXT: il contesto per il secondo cluster, ad esempio gke_my-project_us-east4-a_gke-east.

Esegui il deployment delle risorse nei cluster di destinazione

Per rendere disponibili i tuoi carichi di lavoro di inferenza AI/ML su ogni cluster, esegui il deployment delle risorse richieste, come i server dei modelli e le risorse personalizzate InferenceObjective.

  1. Esegui il deployment dei server dei modelli in entrambi i cluster:

    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

    Sostituisci quanto segue:

    • CLUSTER1_CONTEXT: il contesto del primo cluster, ad esempio gke_my-project_europe-west3-c_gke-west.
    • CLUSTER2_CONTEXT: il contesto del secondo cluster, ad esempio gke_my-project_us-east4-a_gke-east.

  2. Esegui il deployment delle risorse InferenceObjective in entrambi i cluster. Salva il seguente manifest di esempio in un file denominato inference-objective.yaml:

    apiVersion: inference.networking.x-k8s.io/v1alpha2
kind: InferenceObjective
metadata:
  name: food-review
spec:
  priority: 10
  poolRef:
    name: llama3-8b-instruct
    group: "inference.networking.k8s.io"

  3. Applica il manifest a entrambi i cluster:

    kubectl apply -f inference-objective.yaml --context=CLUSTER1_CONTEXT
kubectl apply -f inference-objective.yaml --context=CLUSTER2_CONTEXT

    Sostituisci quanto segue:

    • CLUSTER1_CONTEXT: il contesto del primo cluster, ad esempio gke_my-project_europe-west3-c_gke-west.
    • CLUSTER2_CONTEXT: il contesto del secondo cluster, ad esempio gke_my-project_us-east4-a_gke-east.

  4. Esegui il deployment delle risorse InferencePool in entrambi i cluster utilizzando Helm:

    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

    Sostituisci quanto segue:

    • CLUSTER1_CONTEXT: il contesto per il primo cluster, ad esempio gke_my-project_europe-west3-c_gke-west.
    • CLUSTER2_CONTEXT: il contesto per il secondo cluster, ad esempio gke_my-project_us-east4-a_gke-east.

  5. Contrassegna le risorse InferencePool come esportate su entrambi i cluster. Questa annotazione rende InferencePool disponibile per l'importazione da parte del cluster di configurazione, che è un passaggio obbligatorio per il routing multicluster.

    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

    Sostituisci quanto segue:

    • CLUSTER1_CONTEXT: il contesto per il primo cluster, ad esempio gke_my-project_europe-west3-c_gke-west.
    • CLUSTER2_CONTEXT: il contesto per il secondo cluster, ad esempio gke_my-project_us-east4-a_gke-east.

Esegui il deployment delle risorse nel cluster di configurazione

Per definire come il traffico viene instradato e bilanciato il carico tra le risorse InferencePool in tutti i cluster registrati, esegui il deployment delle risorse Gateway, HTTPRoute e HealthCheckPolicy. Esegui il deployment di queste risorse solo nel cluster di configurazione designato, ovvero gke-west in questo documento.

  1. Crea un file denominato mcig.yaml con i seguenti contenuti:

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

  2. Applica il manifest:

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

    Sostituisci CLUSTER1_CONTEXT con il contesto del primo cluster (il cluster di configurazione), ad esempio gke_my-project_europe-west3-c_gke-west.

Attivare i report sulle metriche personalizzate

Per attivare la generazione di report sulle metriche personalizzate e migliorare il bilanciamento del carico tra regioni, esporta le metriche di utilizzo della cache KV da tutti i cluster. Il bilanciatore del carico utilizza questi dati di utilizzo della cache KV esportati come indicatore di carico personalizzato. L'utilizzo di questo segnale di carico personalizzato consente di prendere decisioni di bilanciamento del carico più intelligenti in base al carico di lavoro effettivo di ciascun cluster.

  1. Crea un file denominato metrics.yaml con i seguenti contenuti:

    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

  2. Applica la configurazione delle metriche a entrambi i cluster:

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

    Sostituisci quanto segue:

    • CLUSTER1_CONTEXT: il contesto per il primo cluster, ad esempio gke_my-project_europe-west3-c_gke-west.
    • CLUSTER2_CONTEXT: il contesto per il secondo cluster, ad esempio gke_my-project_us-east4-a_gke-east.

Configura la policy di bilanciamento del carico

Per ottimizzare la distribuzione delle richieste di inferenza AI/ML nei cluster GKE, configura una policy di bilanciamento del carico. La scelta della modalità di bilanciamento corretta contribuisce a garantire un utilizzo efficiente delle risorse, impedisce il sovraccarico dei singoli cluster e migliora le prestazioni complessive e la reattività dei servizi di inferenza.

Configurare i timeout

Se le richieste dovrebbero avere una lunga durata, configura un timeout più lungo per il bilanciatore del carico. In GCPBackendPolicy, imposta il campo timeoutSec su almeno il doppio della latenza delle richieste P99 stimata.

Ad esempio, il seguente manifest imposta il timeout del bilanciatore del carico su 100 secondi.

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

Per ulteriori informazioni, vedi limitazioni del gateway multicluster.

Poiché le modalità di bilanciamento del carico Metriche personalizzate e Richieste in corso si escludono a vicenda, configura solo una di queste modalità nel file GCPBackendPolicy.

Scegli una modalità di bilanciamento del carico per il deployment.

Metriche personalizzate

Per un bilanciamento del carico ottimale, inizia con un utilizzo target del 60%. Per raggiungere questo target, imposta maxUtilization: 60 nella configurazione GCPBackendPolicy di customMetrics.

  1. Crea un file denominato backend-policy.yaml con i seguenti contenuti per attivare il bilanciamento del carico in base alla metrica personalizzata kv-cache:

    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

  2. Applica la nuova policy:

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

    Sostituisci CLUSTER1_CONTEXT con il contesto per il primo cluster, ad esempio gke_my-project-europe-west3-c-gke-west.

Richieste in corso

Per utilizzare la modalità di bilanciamento in volo, stima il numero di richieste in volo che ogni backend può gestire e configura esplicitamente un valore di capacità.

  1. Crea un file denominato backend-policy.yaml con il seguente contenuto per attivare il bilanciamento del carico in base al numero di richieste in corso:

    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

  2. Applica la nuova policy:

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

    Sostituisci CLUSTER1_CONTEXT con il contesto del primo cluster, ad esempio gke_my-project_europe-west3-c_gke-west.

Verifica il deployment

Per verificare il bilanciatore del carico interno, devi inviare richieste dall'interno della rete VPC perché i bilanciatori del carico interni utilizzano indirizzi IP privati. Esegui un pod temporaneo all'interno di uno dei cluster per inviare richieste dalla tua rete VPC e verifica il bilanciatore del carico interno:

  1. Avvia una sessione di shell interattiva in un pod temporaneo:

    kubectl run -it --rm --image=curlimages/curl curly --context=CLUSTER1_CONTEXT -- /bin/sh

    Sostituisci CLUSTER1_CONTEXT con il contesto per il primo cluster, ad esempio gke_my-project_europe-west3-c_gke-west.

  2. Dalla nuova shell, ottieni l'indirizzo IP del gateway e invia una richiesta di test:

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

    Di seguito è riportato un esempio di risposta corretta:

    {
  "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
  }
}

Passaggi successivi