Configurer la haute disponibilité élastique interrégionale

Ce document explique comment configurer une haute disponibilité élastique interrégionale pour les charges de travail d'inférence d'IA à l'aide de Google Kubernetes Engine (GKE) Multi-Cluster Inference Gateway et de la fonctionnalité d'autoscaling de GKE. Cette configuration vous permet d'équilibrer intelligemment la charge des charges de travail sur plusieurs clusters GKE dans différentes régions.

Pour en savoir plus sur GKE Multi-Cluster Inference Gateway, consultez À propos de GKE Multi-Cluster Inference Gateway.

Avant de commencer

  1. Activez l'API Google Kubernetes Engine.

    Activer l'API Google Kubernetes Engine

  2. Installez et initialisez Google Cloud CLI si vous prévoyez de l'utiliser pour cette tâche.

  3. Assurez-vous que votre projet dispose d'un quota suffisant pour les GPU H100. Pour en savoir plus, consultez Quota de GPU et allocation de ressources.

  4. Utilisez GKE version 1.34.1-gke.1127000 ou ultérieure.

  5. Utilisez gcloud CLI version 480.0.0 ou ultérieure.

  6. Assurez-vous que le compte de service utilisé par vos nœuds dispose des autorisations roles/monitoring.metricWriter et roles/stackdriver.resourceMetadata.writer.

  7. Assurez-vous de disposer des rôles IAM (Identity and Access Management) roles/container.admin et roles/iam.serviceAccountAdmin sur le projet.

  8. Suivez les conditions préalables Hugging Face ci-dessous :

    1. Créez un compte Hugging Face.
    2. Demandez et obtenez l'approbation de l'accès au modèle Llama 3.1 sur Hugging Face.
    3. Signez le contrat de consentement de la licence sur la page du modèle sur Hugging Face.
    4. Générez un jeton d'accès Hugging Face avec au moins des autorisations de lecture.

Créer des clusters et des pools de nœuds

Pour créer deux clusters GKE dans différentes régions et configurer leurs pools de nœuds, procédez comme suit :

  1. Créez le premier 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

    Remplacez les éléments suivants :

    • PROJECT_ID : ID de votre projet
    • CLUSTER_1_ZONE: zone du premier cluster, par exemple europe-west3-c
    • GKE_VERSION: version de GKE à utiliser, par exemple 1.34.1-gke.1127000
    • MACHINE_TYPE: type de machine pour les nœuds de cluster, par exemple c2-standard-16
    • DISK_TYPE: type de disque pour les nœuds de cluster, par exemple pd-standard

  2. Créez un pool de nœuds H100 dans le premier 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

    Remplacez les éléments suivants :

    • PROJECT_ID : ID de votre projet
    • CLUSTER_1_ZONE: zone du premier cluster, par exemple europe-west3-c
    • CLUSTER_1_NAME: nom du premier cluster, par exemple gke-west
    • NODE_POOL_MACHINE_TYPE: type de machine pour le pool de nœuds, par exemple a3-highgpu-2g
    • NUM_NODES: nombre de nœuds dans le pool de nœuds, par exemple 3
    • MIN_NUM_NODES: nombre minimal de nœuds pour l'autoscaling dans le pool de nœuds, par exemple 1
    • MAX_NUM_NODES: nombre maximal de nœuds pour l'autoscaling dans le pool de nœuds, par exemple 10

  3. Obtenez les identifiants et créez un secret de jeton Hugging Face dans le premier 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

    Remplacez les éléments suivants :

    • PROJECT_ID : ID de votre projet
    • CLUSTER_1_NAME: nom du premier cluster, par exemple gke-west
    • CLUSTER_1_ZONE: zone du premier cluster, par exemple europe-west3-c
    • HF_TOKEN : jeton d'accès Hugging Face

  4. Créez le deuxième cluster dans une région différente de celle du premier cluster :

    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

    Remplacez CLUSTER_2_ZONE par la zone du deuxième cluster, par exemple us-east4-a.

  5. Créez un pool de nœuds H100 pour le deuxième 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

    Remplacez les éléments suivants :

    • PROJECT_ID : ID de votre projet
    • CLUSTER_2_ZONE: zone du deuxième cluster, par exemple us-east4-a
    • CLUSTER_2_NAME: nom du deuxième cluster, par exemple gke-east
    • NODE_POOL_MACHINE_TYPE: type de machine pour le pool de nœuds, par exemple a3-highgpu-2g
    • NUM_NODES: nombre de nœuds dans le pool de nœuds, par exemple 3
    • MIN_NUM_NODES: nombre minimal de nœuds pour l'autoscaling dans le pool de nœuds, par exemple 1
    • MAX_NUM_NODES: nombre maximal de nœuds pour l'autoscaling dans le pool de nœuds, par exemple 10

  6. Obtenez les identifiants et créez un secret pour le jeton Hugging Face sur le deuxième 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

    Remplacez les éléments suivants. Pour obtenir les définitions d'autres variables, reportez-vous aux étapes précédentes :

    • HF_TOKEN : jeton d'accès Hugging Face

Enregistrer des clusters dans un parc

  1. Enregistrez vos clusters dans le parc de votre projet :

    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

    Remplacez les éléments suivants et reportez-vous aux étapes précédentes pour obtenir les définitions d'autres variables :

    • CLUSTER_1_NAME: nom du premier cluster, par exemple gke-west
    • CLUSTER_2_NAME: nom du deuxième cluster, par exemple gke-east

  2. Activez la fonctionnalité Multi-Cluster Ingress et désignez un cluster de configuration :

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

    Remplacez les éléments suivants. Pour obtenir les définitions d'autres variables, reportez-vous aux étapes précédentes :

    • PROJECT_ID : ID de votre projet
    • CLUSTER_1_NAME: nom du premier cluster, par exemple gke-west

Créer des sous-réseaux proxy réservés

Avertissement Cloud de Confiance by S3NS : permet à chaque réseau VPC de n'avoir qu'un seul sous-réseau proxy réservé par région. Si la région cible contient déjà un sous-réseau proxy réservé avec le paramètre purpose=REGIONAL_MANAGED_PROXY, la création du sous-réseau GLOBAL_MANAGED_PROXY échoue. Vous devez d'abord supprimer le sous-réseau proxy réservé régional existant. La suppression d'un sous-réseau proxy réservé régional affecte tous les équilibreurs de charge régionaux basés sur Envoy de cette région qui l'utilisent. Planifiez donc la modification en conséquence.

  1. Créez un sous-réseau dans la région du premier 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

    Remplacez les éléments suivants :

    • PROJECT_ID : ID de votre projet
    • CLUSTER_1_REGION: région du premier cluster, par exemple europe-west3
    • SUBNET_RANGE_1: plage d'adresses IP du sous-réseau pour le sous-réseau proxy réservé dans la région du premier cluster, par exemple 10.0.0.0/23

  2. Créez un sous-réseau dans la région du deuxième 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

    Remplacez les éléments suivants :

    • PROJECT_ID : ID de votre projet
    • CLUSTER_2_REGION: région du deuxième cluster, par exemple us-east4
    • SUBNET_RANGE_2: plage d'adresses IP du sous-réseau pour le sous-réseau proxy réservé dans la région du deuxième cluster, par exemple 10.5.0.0/23

Installer les ressources personnalisées requises

  1. Définissez des variables de contexte pour vos clusters :

    CLUSTER1_CONTEXT="gke_PROJECT_ID_CLUSTER_1_ZONE_CLUSTER_1_NAME"
CLUSTER2_CONTEXT="gke_PROJECT_ID_CLUSTER_2_ZONE_CLUSTER_2_NAME"

    Remplacez les éléments suivants :

    • PROJECT_ID : ID de votre projet
    • CLUSTER_1_ZONE: zone du premier cluster, par exemple europe-west3-c
    • CLUSTER_1_NAME: nom du premier cluster, par exemple gke-west
    • CLUSTER_2_ZONE: zone du deuxième cluster, par exemple us-east4-a
    • CLUSTER_2_NAME: nom du deuxième cluster, par exemple gke-east

  2. Installez la ressource personnalisée InferencePool et InferenceObjective sur les deux clusters :

    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

Déployer des ressources sur les clusters cibles

  1. Déployez les serveurs de modèles sur les deux clusters :

    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. Enregistrez le fichier manifeste suivant dans un fichier nommé 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. Appliquez le fichier manifeste aux deux clusters :

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

  4. Déployez les ressources InferencePool sur les deux clusters à l'aide de 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. Dans les deux clusters, marquez les ressources InferencePool comme exportées :

    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

Déployer la passerelle d'inférence interrégionale

  1. Enregistrez le manifeste suivant sous le nom 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. Appliquez le fichier manifeste au cluster de configuration :

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

    Remplacez les éléments suivants :

    • CLUSTER1_CONTEXT: contexte du premier cluster, par exemple gke_my-project_europe-west3-c_gke-west

Activer la génération de rapports sur les métriques personnalisées

  1. Créez un fichier nommé metrics.yaml avec le contenu suivant :

    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. Pour chaque cluster, appliquez la configuration des métriques :

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

    Pour obtenir les définitions de CLUSTER1_CONTEXT et CLUSTER2_CONTEXT, consultez Installer les ressources personnalisées requises.

Configurer la règle d'équilibrage de charge

Cette section explique comment configurer la règle d'équilibrage de charge. Cette règle définit la manière dont le trafic est réparti entre vos pools d'inférence en fonction de métriques personnalisées et de préférences régionales. La configuration suivante définit us-east4 comme région préférée. Le trafic n'est transféré vers d'autres régions que lorsque la métrique personnalisée gke.named_metrics.kv-cache dans la région us-east4 atteint 80% d'utilisation.

  • Pour les versions vLLM v0.10.2 et ultérieures, utilisez la métrique gke.named_metrics.kv-cache.
  • Pour les versions antérieures, utilisez la métrique gke.named_metrics.kv-cache-old.

  1. Créez un fichier nommé backend-policy.yaml avec le contenu suivant :

    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. Appliquez la nouvelle règle :

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

    Remplacez CLUSTER1_CONTEXT par le contexte du premier cluster, par exemple gke_my-project_europe-west3-c_gke-west

Configurer l'autoscaling

Pour vous assurer que chaque cluster peut gérer une charge croissante avant que le trafic ne soit transféré vers d'autres régions, vous devez configurer l'autoscaler horizontal des pods (AHP) pour vos déploiements de serveurs de modèles.

Principes de configuration clés

  • Utilisez les mêmes métriques personnalisées : le AHP doit être configuré pour effectuer un scaling en fonction des mêmes métriques personnalisées que celles que vous utilisez dans la GCPBackendPolicy pour la passerelle d'inférence multicluster (par exemple, vllm:kv_cache_usage_perc). Cette approche permet de s'assurer que les décisions d'équilibrage de charge et de scaling sont basées sur le même signal provenant de vos serveurs d'inférence. Les métriques que vous choisissez doivent avoir une valeur comprise entre 0 et 1 pour représenter l'utilisation. Si la valeur de la métrique est supérieure à 1, elle est interprétée comme une utilisation de 100% par l'équilibreur de charge, ce qui peut entraîner des comportements de routage inattendus.

  • Définissez une cible AHP inférieure : la valeur cible de la métrique dans la configuration AHP doit être inférieure au paramètre maxUtilizationPercent défini dans GCPBackendPolicy. En définissant une utilisation cible inférieure pour le AHP (par exemple, le AHP effectue un scaling à 50% d'utilisation moyenne), vous autorisez le cluster à ajouter d'autres répliques avant que le seuil de l'équilibreur de charge (par exemple, 80% d'utilisation) ne soit atteint. Cette approche permet de maximiser la capacité dans la région préférée. Une cible d'utilisation inférieure permet également d'éviter un transfert de trafic prématuré en réservant une haute disponibilité élastique interrégionale pour le moment où la région actuelle approche réellement de ses limites.

  1. Accordez à votre utilisateur la possibilité de créer les rôles d'autorisation requis :

    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

    Les variables CLUSTER1_CONTEXT et CLUSTER2_CONTEXT sont définies dans la section Installer les ressources personnalisées requises.

  2. Pour chaque cluster, appliquez le fichier manifeste :

    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. Autorisez le compte de service custom-metrics-stackdriver-adapter à lire les métriques 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

    Remplacez PROJECT_ID par l'ID de votre projet.

  4. Enregistrez le fichier manifeste suivant dans un fichier nommé 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. Appliquez le fichier manifeste aux deux clusters :

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

  6. Enregistrez le fichier manifeste suivant dans un fichier nommé 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. Appliquez le fichier manifeste aux deux clusters :

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

Vérifier le déploiement

  1. Obtenez l'adresse IP de la passerelle :

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

echo ${GW_IP}

    La variable CLUSTER1_CONTEXT est définie dans la section Installer les ressources personnalisées requises.

  2. Démarrez une session sh interactive dans un pod temporaire :

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

    La variable CLUSTER1_CONTEXT est définie dans la section Installer les ressources personnalisées requises.

  3. À l'intérieur du pod curly, envoyez une requête de 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
}'

    Remplacez GW_IP par l'adresse IP de la passerelle de l'étape précédente.

Tester la charge de la passerelle

  1. Appliquez une charge soutenue à l'adresse IP de la passerelle à l'aide d'un générateur de charge au sein du même réseau VPC.

  2. Commencez par une charge modérée que vous prévoyez de gérer dans la région préférée (us-east4).

  3. Augmentez progressivement le taux de requêtes ou la simultanéité de votre test de charge.

  4. Pendant l'exécution du test de charge, surveillez le système dans la Cloud de Confiance console ou à l'aide de kubectl :

    • Scaling des pods (AHP) : vérifiez le nombre de pods dans le vllm-llama3-8b-instruct déploiement dans les deux clusters.
    • Scaling des nœuds (autoscaler de cluster) : surveillez le nombre de nœuds dans les pools de nœuds h100 des deux clusters.
    • Métriques personnalisées : surveillez la métrique vllm:kv_cache_usage_perc (pour la version vllm v0.10.2 et ultérieure) ou la métrique vllm:gpu_cache_usage_perc (pour la version vllm antérieure à la version v.0.10.2) dans Monitoring pour les déploiements de serveurs de modèles dans les deux clusters.
    • Métriques de l'équilibreur de charge : examinez les métriques de l'équilibreur de charge associé à cross-region-gateway dans Monitoring.

À mesure que vous augmentez la charge, l'utilisation dans us-east4 augmente. Lorsque le AHP du cluster gke-east effectue un scaling et que l'utilisation moyenne approche la valeur maxUtilization (80%) définie dans GCPBackendPolicy, l'équilibreur de charge commence à acheminer les requêtes vers le cluster gke-west dans europe-west3.

Étape suivante