Configura l'alta affidabilità cross-region elastica

Questo documento mostra come configurare l'alta affidabilità cross-region elastica per i carichi di lavoro di inferenza AI utilizzando il gateway di inferenza multicluster Google Kubernetes Engine (GKE) e la funzionalità di scalabilità automatica di GKE. Questa configurazione ti consente di bilanciare il carico in modo intelligente tra più cluster GKE in regioni diverse.

Per saperne di più su GKE Multi-Cluster Inference Gateway, consulta Informazioni su GKE Multi-Cluster Inference Gateway.

Prima di iniziare

  1. Abilita l'API Google Kubernetes Engine.

    Abilita l'API Google Kubernetes Engine

  2. Installa e inizializza Google Cloud CLI se prevedi di utilizzarla per questa attività.

  3. Assicurati che il tuo progetto disponga di una quota sufficiente per le GPU H100. Per saperne di più, consulta Quota delle GPU e Allocazione delle risorse.

  4. Utilizza GKE 1.34.1-gke.1127000 o versioni successive.

  5. Utilizza gcloud CLI versione 480.0.0 o successive.

  6. Assicurati che il account di servizio utilizzato dai nodi disponga delle autorizzazioni roles/monitoring.metricWriter e roles/stackdriver.resourceMetadata.writer.

  7. Assicurati di disporre dei ruoli IAM (Identity and Access Management) roles/container.admin e roles/iam.serviceAccountAdmin nel progetto.

  8. Completa i seguenti prerequisiti di Hugging Face:

    1. Crea un account Hugging Face.
    2. Richiedi e ottieni l'approvazione per l'accesso al modello Llama 3.1 su Hugging Face.
    3. Firma il contratto di consenso alla licenza nella pagina del modello su Hugging Face.
    4. Genera un token di accesso a Hugging Face con almeno le autorizzazioni in lettura.

Crea cluster e node pool

Per creare due cluster GKE in regioni diverse e configurare i relativi pool di nodi, segui questi passaggi:

  1. Crea il primo cluster:

    gcloud container clusters create gke-west --zone \
    CLUSTER_1_ZONE \
    --project=PROJECT_ID \
    --gateway-api=standard \
    --cluster-version=GKE_VERSION \
    --machine-type="MACHINE_TYPE" \
    --disk-type="DISK_TYPE" \
    --enable-managed-prometheus --monitoring=SYSTEM,DCGM \
    --hpa-profile=performance \
    --workload-pool=PROJECT_ID.s3ns.svc.id.goog \
    --async

    Sostituisci quanto segue:

    • PROJECT_ID: il tuo ID progetto
    • CLUSTER_1_ZONE: la zona del primo cluster, ad esempio europe-west3-c
    • 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 nel primo cluster:

    gcloud container node-pools create h100 \
    --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 \
    --min-nodes=MIN_NUM_NODES \
    --max-nodes=MAX_NUM_NODES \
    --enable-autoscaling \
    --async

    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
    • 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 node pool, ad esempio 3
    • MIN_NUM_NODES: il numero minimo di nodi per la scalabilità automatica nel pool di nodi, ad esempio 1
    • MAX_NUM_NODES: il numero massimo di nodi per la scalabilità automatica nelpool di nodil, ad esempio 10

  3. Ottieni le credenziali e crea un secret del token Hugging Face nel primo cluster:

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

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

    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
    • HF_TOKEN: il tuo token di accesso a Hugging Face

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

    gcloud container clusters create gke-east --zone CLUSTER_2_ZONE \
    --project=PROJECT_ID \
    --gateway-api=standard \
    --cluster-version=GKE_VERSION \
    --machine-type="MACHINE_TYPE" \
    --disk-type="DISK_TYPE" \
    --enable-managed-prometheus \
    --monitoring=SYSTEM,DCGM \
    --hpa-profile=performance \
    --workload-pool=PROJECT_ID.s3ns.svc.id.goog \
    --async

    Sostituisci CLUSTER_2_ZONE con la zona del secondo cluster, ad esempio us-east4-a.

  5. 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 \
    --min-nodes=MIN_NUM_NODES \
    --max-nodes=MAX_NUM_NODES \
    --enable-autoscaling \
    --async

    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 node pool, ad esempio 3
    • MIN_NUM_NODES: il numero minimo di nodi per la scalabilità automatica nel pool di nodi, ad esempio 1
    • MAX_NUM_NODES: il numero massimo di nodi per la scalabilità automatica nelpool di nodil, ad esempio 10

  6. Recupera le credenziali e crea un secret per il token Hugging Face sul secondo cluster:

    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. Per le definizioni di altre variabili, consulta i passaggi precedenti:

    • HF_TOKEN: il token di accesso a Hugging Face

Registra i cluster in un parco risorse

  1. Registra i cluster nel parco risorse del 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 e fai riferimento ai passaggi precedenti per le definizioni di altre variabili:

    • CLUSTER_1_NAME: il nome del primo cluster, ad esempio gke-west
    • CLUSTER_2_NAME: il nome del secondo cluster, ad esempio gke-east

  2. Attiva 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. Per le definizioni di altre variabili, consulta i passaggi precedenti:

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

Crea subnet solo proxy

Avviso: Cloud de Confiance by S3NS consente a ogni rete VPC di avere una sola subnet solo proxy per regione. Se la regione di destinazione contiene già una subnet solo proxy con l'impostazione purpose=REGIONAL_MANAGED_PROXY, la creazione della subnet GLOBAL_MANAGED_PROXY non va a buon fine. Devi prima eliminare la subnet solo proxy regionale esistente. L'eliminazione di una subnet solo proxy a livello di regione influisce su tutti i bilanciatori del carico basati su Envoy a livello di regione che la utilizzano, quindi pianifica la modifica di conseguenza.

  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=SUBNET_RANGE_1 \
    --project=PROJECT_ID

    Sostituisci quanto segue:

    • PROJECT_ID: il tuo ID progetto
    • CLUSTER_1_REGION: la regione del primo cluster, ad esempio europe-west3
    • SUBNET_RANGE_1: l'intervallo IP della subnet solo proxy nella regione del primo cluster, ad esempio 10.0.0.0/23

  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=SUBNET_RANGE_2 \
    --project=PROJECT_ID

    Sostituisci quanto segue:

    • PROJECT_ID: il tuo ID progetto
    • CLUSTER_2_REGION: la regione per il secondo cluster, ad esempio us-east4
    • SUBNET_RANGE_2: l'intervallo IP della subnet solo proxy nella regione del secondo cluster, ad esempio 10.5.0.0/23

Installa le risorse personalizzate richieste

  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 risorsa personalizzata InferencePool e InferenceObjective su entrambi i cluster:

    kubectl apply -f https://github.com/kubernetes-sigs/gateway-api-inference-extension/releases/download/v1.0.1/manifests.yaml --context=$CLUSTER1_CONTEXT

kubectl apply -f https://github.com/kubernetes-sigs/gateway-api-inference-extension/releases/download/v1.0.1/manifests.yaml --context=$CLUSTER2_CONTEXT

Esegui il deployment delle risorse nei cluster di destinazione

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

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

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

  2. Salva il seguente manifest 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

  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 \
  --set inferenceExtension.monitoring.gke.enabled=true \
  --version v1.0.1 \
  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.0.1 \
  oci://registry.k8s.io/gateway-api-inference-extension/charts/inferencepool

  5. In entrambi i cluster, contrassegna le risorse InferencePool come esportate in entrambi i cluster:

    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

Esegui il deployment del gateway di inferenza tra regioni

  1. Salva il seguente manifest come mygateway.yaml:

    ---
kind: Gateway
apiVersion: gateway.networking.k8s.io/v1beta1
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
    allowedRoutes:
      kinds:
      -   kind: HTTPRoute
      namespaces:
        from: All
---
apiVersion: gateway.networking.k8s.io/v1beta1
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
---
kind: HealthCheckPolicy
apiVersion: networking.gke.io/v1
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 al cluster di configurazione:

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

    Sostituisci quanto segue:

    • CLUSTER1_CONTEXT: il contesto del primo cluster, ad esempio gke_my-project_europe-west3-c_gke-west

Attiva i report sulle metriche personalizzate

  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
      exportName: kv-cache
    -   name: vllm:gpu_cache_usage_perc
      exportName: kv-cache-old

  2. Per ogni cluster, applica la configurazione delle metriche:

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

    Per le definizioni di CLUSTER1_CONTEXT e CLUSTER2_CONTEXT, consulta Installa le risorse personalizzate richieste.

Configura la policy di bilanciamento del carico

Questa sezione descrive come configurare la policy di bilanciamento del carico. Questa policy definisce il modo in cui il traffico viene distribuito tra i pool di inferenza in base a metriche personalizzate e preferenze regionali. La seguente configurazione imposta us-east4 come regione preferita. Il traffico si riversa in altre regioni solo quando la metrica personalizzata gke.named_metrics.kv-cache nella regione us-east4 raggiunge l'80% di utilizzo.

  • Per le versioni di vLLM v0.10.2 e successive, utilizza la metrica gke.named_metrics.kv-cache.
  • Per le versioni precedenti, utilizza la metrica gke.named_metrics.kv-cache-old.

  1. Crea un file denominato backend-policy.yaml con i seguenti contenuti:

    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:
    timeoutSec: 600
    balancingMode: CUSTOM_METRICS
    trafficDuration: LONG
    customMetrics:
    -   name: gke.named_metrics.kv-cache
      maxUtilizationPercent: 80
      dryRun: false
    scopes:
    -   selector:
        gke.io/region: "us-east4"
      backendPreference: PREFERRED

  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.

Configura scalabilità automatica

Per garantire che ogni cluster possa gestire un carico crescente prima che il traffico si riversi in altre regioni, devi configurare Horizontal-Pod-Autoscaler (HPA) per i deployment del server di modelli.

Principi di configurazione chiave

  • Utilizza le stesse metriche personalizzate: l'HPA deve essere configurato per scalare in base alle stesse metriche personalizzate utilizzate in GCPBackendPolicy per il gateway di inferenza multicluster (ad esempio, vllm:kv_cache_usage_perc). Questo approccio contribuisce a garantire che le decisioni relative al bilanciamento del carico e allo scaling siano basate sullo stesso segnale dei server di inferenza. Le metriche scelte devono avere un valore compreso tra 0 e 1 per rappresentare l'utilizzo. Se il valore della metrica è maggiore di 1, viene interpretato come un utilizzo del 100% da parte del bilanciatore del carico, il che può causare comportamenti di routing imprevisti.

  • Imposta un target HPA inferiore: il valore target per la metrica nella configurazione HPA deve essere impostato su un valore inferiore all'impostazione maxUtilizationPercent definita in GCPBackendPolicy. Impostando un utilizzo target inferiore per l'HPA (ad esempio, l'HPA scala con un utilizzo medio del 50%), consenti al cluster di aggiungere più repliche prima che venga raggiunta la soglia del bilanciatore del carico (ad esempio, un utilizzo dell'80%). Questo approccio consente di massimizzare la capacità all'interno della regione preferita. Un target di utilizzo inferiore contribuisce anche a prevenire lo spillover prematuro del traffico riservando l'alta affidabilità cross-region elastica per quando la regione attuale si avvicina realmente ai suoi limiti.

  1. Concedi all'utente la possibilità di creare i ruoli di autorizzazione richiesti:

    kubectl create clusterrolebinding cluster-admin-binding \
    --clusterrole cluster-admin --user "$(gcloud config get-value account)" --context=CLUSTER1_CONTEXT

kubectl create clusterrolebinding cluster-admin-binding \
    --clusterrole cluster-admin --user "$(gcloud config get-value account)" --context=CLUSTER2_CONTEXT

    Le variabili CLUSTER1_CONTEXT e CLUSTER2_CONTEXT sono definite nella sezione Installa le risorse personalizzate richieste.

  2. Per ogni cluster, applica il manifest:

    kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/k8s-stackdriver/master/custom-metrics-stackdriver-adapter/deploy/production/adapter_new_resource_model.yaml --context=CLUSTER1_CONTEXT

kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/k8s-stackdriver/master/custom-metrics-stackdriver-adapter/deploy/production/adapter_new_resource_model.yaml --context=CLUSTER2_CONTEXT

  3. Consenti al account di servizio custom-metrics-stackdriver-adapter di leggere le metriche di Cloud Monitoring:

    PROJECT_NUMBER=$(gcloud projects describe PROJECT_ID --format="value(projectNumber)")

gcloud projects add-iam-policy-binding projects/PROJECT_ID \
  --role roles/monitoring.viewer \
  --member=principal://iam.googleapis.com/projects/$PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.s3ns.svc.id.goog/subject/ns/custom-metrics/sa/custom-metrics-stackdriver-adapter

    Sostituisci PROJECT_ID con l'ID progetto.

  4. Salva il seguente manifest in un file denominato pod-monitoring.yaml:

    apiVersion: monitoring.googleapis.com/v1
kind: PodMonitoring
metadata:
  name: inference-server-podmon
spec:
  selector:
    matchLabels:
      app: vllm-llama3-8b-instruct
  endpoints:
  -   port: 8000
    path: /metrics
    interval: 5s

  5. Applica il manifest a entrambi i cluster:

    kubectl apply -f pod-monitoring.yaml --context=CLUSTER1_CONTEXT
kubectl apply -f pod-monitoring.yaml --context=CLUSTER2_CONTEXT

  6. Salva il seguente manifest in un file denominato hpa.yaml:

    apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: inference-server-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: vllm-llama3-8b-instruct
  minReplicas: 1
  maxReplicas: 10
  metrics:
  -   type: Pods
    pods:
      metric:
        name: prometheus.googleapis.com|vllm:gpu_cache_usage_perc|gauge
      target:
        type: AverageValue
        averageValue: "0.5"

  7. Applica il manifest a entrambi i cluster:

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

Verifica il deployment

  1. Ottieni l'indirizzo IP del gateway:

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

echo ${GW_IP}

    La variabile CLUSTER1_CONTEXT è definita nella sezione Installa le risorse personalizzate richieste.

  2. Avvia una sessione sh interattiva in un pod temporaneo:

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

    La variabile CLUSTER1_CONTEXT è definita nella sezione Installa le risorse personalizzate richieste.

  3. Dall'interno del pod curly, invia una richiesta di test:

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

    Sostituisci GW_IP con l'indirizzo IP del gateway del passaggio precedente.

Esegui il test di carico del gateway

  1. Applica un carico sostenuto all'indirizzo IP del gateway utilizzando un generatore di carico all'interno della stessa rete VPC.

  2. Inizia con un carico moderato che prevedi che la regione preferita (us-east4) gestisca.

  3. Aumenta gradualmente il tasso di richieste o la concorrenza del test di carico.

  4. Durante l'esecuzione del test di carico, monitora il sistema nella console Cloud de Confiance o utilizzando kubectl:

    • Scalabilità dei pod (HPA): controlla il numero di pod nel deployment vllm-llama3-8b-instruct in entrambi i cluster.
    • Scalabilità dei nodi (gestore della scalabilità automatica del cluster): monitora il numero di nodi nei pool di nodi h100 in entrambi i cluster.
    • Metriche personalizzate: monitora la metrica vllm:kv_cache_usage_perc (per vllm versione v0.10.2 e successive) o la metrica vllm:gpu_cache_usage_perc (per vllm versione precedente alla v.0.10.2) in Monitoring per i deployment del server di modelli in entrambi i cluster.
    • Metriche del bilanciatore del carico: esamina le metriche del bilanciatore del carico associato a cross-region-gateway in Monitoring.

Man mano che aumenti il carico, l'utilizzo in us-east4 aumenta. Quando l'HPA nel cluster gke-east fa lo scale out e l'utilizzo medio si avvicina al valore maxUtilization (80%) definito in GCPBackendPolicy, il bilanciatore del carico inizia a instradare le richieste al cluster gke-west in europe-west3.

Passaggi successivi