Configurer la passerelle d'inférence multicluster GKE

Ce document explique comment configurer la passerelle d'inférence multicluster Google Kubernetes Engine (GKE) pour équilibrer intelligemment la charge de vos charges de travail d'inférence d'IA/de ML sur plusieurs clusters GKE, qui peuvent s'étendre sur différentes régions. Cette configuration utilise l'API Gateway, Multi Cluster Ingress et des ressources personnalisées telles que InferencePool et InferenceObjective pour améliorer la scalabilité, assurer une haute disponibilité et optimiser l'utilisation des ressources pour vos déploiements de diffusion de modèles.

Pour comprendre ce document, vous devez connaître les éléments suivants :

Ce document s'adresse aux personas suivants :

  • Ingénieurs en machine learning (ML), administrateurs et opérateurs de plate-forme, ou spécialistes des données et de l'IA qui souhaitent utiliser les fonctionnalités d'orchestration de conteneurs de GKE pour diffuser des charges de travail d'IA/ML.
  • Architectes cloud ou spécialistes de la mise en réseau qui interagissent avec la mise en réseau GKE.

Pour en savoir plus sur les rôles courants et les exemples de tâches cités dans le contenuGoogle Cloud , consultez Rôles utilisateur et tâches courantes de l'utilisateur dans GKE Enterprise.

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

  • Activez l'API Google Kubernetes Engine.
    • Activer l'API Google Kubernetes Engine
  • Si vous souhaitez utiliser la Google Cloud CLI pour cette tâche, installez et initialisez la gcloud CLI. Si vous avez déjà installé la gcloud CLI, obtenez la dernière version en exécutant la commande gcloud components update. Il est possible que les versions antérieures de la gcloud CLI ne permettent pas d'exécuter les commandes de ce document.

  • Activez les API Compute Engine, Google Kubernetes Engine, Model Armor et Network Services.

    Accédez à Activer l'accès aux API et suivez les instructions.

  • Activez l'API Autoscaling.

    Accédez à l'API Autoscaling et suivez les instructions.

  • Prérequis Hugging Face :

    • Créez un compte Hugging Face si vous n'en possédez pas.
    • Demandez et obtenez l'autorisation d'accéder au modèle Llama 3.1 sur Hugging Face.
    • Signez le contrat de consentement de la licence sur la page du modèle sur Hugging Face.
    • Générez un jeton d'accès Hugging Face avec au moins les autorisations Read.

Conditions requises

  • Assurez-vous que votre projet dispose d'un quota suffisant pour les GPU H100. Pour en savoir plus, consultez Planifier le quota de GPU et Quotas d'allocation.
  • Utilisez GKE version 1.34.1-gke.1127000 ou ultérieure.
  • Utilisez gcloud CLI version 480.0.0 ou ultérieure.
  • Vos comptes de service de nœud doivent être autorisés à écrire des métriques dans l'API Autoscaling.
  • Vous devez disposer des rôles IAM suivants sur le projet : roles/container.admin et roles/iam.serviceAccountAdmin.

Configurer une passerelle d'inférence multicluster

Pour configurer la passerelle d'inférence multicluster GKE, procédez comme suit :

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

Pour héberger vos charges de travail d'inférence d'IA/ML et activer l'équilibrage de charge multirégional, créez deux clusters GKE dans des régions différentes, chacun avec un pool de nœuds GPU H100.

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

    Remplacez les éléments suivants :

    • CLUSTER_1_NAME : nom du premier cluster, par exemple gke-west.
    • LOCATION : région du premier cluster (par exemple, europe-west3).
    • PROJECT_ID : ID de votre projet.
    • GKE_VERSION : version de GKE à utiliser, par exemple 1.34.1-gke.1127000.
    • MACHINE_TYPE : type de machine pour les nœuds du cluster, par exemple c2-standard-16.
    • DISK_TYPE : type de disque pour les nœuds du cluster, par exemple pd-standard.

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

    Remplacez les éléments suivants :

    • NODE_POOL_NAME : nom du pool de nœuds, par exemple h100.
    • 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 du pool de nœuds, par exemple a3-highgpu-2g.
    • NUM_NODES : nombre de nœuds dans le pool de nœuds, par exemple 3.

  3. Obtenez les identifiants :

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

    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.

  4. Sur le premier cluster, créez un secret pour le jeton Hugging Face :

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

    Remplacez HF_TOKEN par votre jeton d'accès Hugging Face.

  5. Créez le deuxième cluster dans une région différente de celle du premier 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.

    Remplacez les éléments suivants :

    • LOCATION : région du deuxième cluster. Cette région doit être différente de celle du premier cluster. Exemple :us-east4
    • PROJECT_ID : ID de votre projet.
    • GKE_VERSION : version de GKE à utiliser, par exemple 1.34.1-gke.1127000.
    • MACHINE_TYPE : type de machine pour les nœuds du cluster, par exemple c2-standard-16.
    • DISK_TYPE : type de disque pour les nœuds du cluster, par exemple pd-standard.

  6. 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 \
    --async # Allows the command to return immediately

    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 du pool de nœuds, par exemple a3-highgpu-2g.
    • NUM_NODES : nombre de nœuds dans le pool de nœuds, par exemple 3.

  7. Pour le deuxième cluster, obtenez les identifiants et créez un secret pour le jeton 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

    Remplacez les éléments suivants :

    • CLUSTER_2_NAME : nom du deuxième cluster, par exemple gke-east.
    • CLUSTER_2_ZONE : zone du deuxième cluster, par exemple us-east4-a.
    • PROJECT_ID : ID de votre projet.
    • HF_TOKEN : votre jeton d'accès Hugging Face.

Enregistrer des clusters dans un parc

Pour activer les fonctionnalités multicluster, telles que la passerelle d'inférence multicluster GKE, enregistrez vos clusters dans un parc.

  1. Enregistrez les deux 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 :

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

  2. Pour permettre à une seule passerelle de gérer le trafic sur plusieurs clusters, activez la fonctionnalité d'Ingress multicluster 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 :

    • 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

Pour une passerelle interne, créez un sous-réseau proxy réservé dans chaque région. Les proxys Envoy de la passerelle interne utilisent ces sous-réseaux dédiés pour gérer le trafic au sein de votre réseau VPC.

  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=10.0.0.0/23 \
    --project=PROJECT_ID

  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=10.5.0.0/23 \
    --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.
    • CLUSTER_2_REGION : région du deuxième cluster, par exemple us-east4.

Installer les CRD requises

La passerelle d'inférence multicluster GKE utilise des ressources personnalisées telles que InferencePool et InferenceObjective. Le contrôleur de l'API GKE Gateway gère la définition de ressource personnalisée (CRD) InferencePool. Toutefois, vous devez installer manuellement le CRD InferenceObjective, qui est en version alpha, sur vos clusters.

  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 le CRD InferenceObjective sur les deux clusters :

    # 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

    Remplacez les éléments suivants :

    • CLUSTER1_CONTEXT : contexte du premier cluster, par exemple gke_my-project_europe-west3-c_gke-west.
    • CLUSTER2_CONTEXT : contexte du deuxième cluster, par exemple gke_my-project_us-east4-a_gke-east.

Déployer des ressources sur les clusters cibles

Pour rendre vos charges de travail d'inférence d'IA/de ML disponibles sur chaque cluster, déployez les ressources requises, telles que les serveurs de modèle et les ressources personnalisées InferenceObjective.

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

    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

    Remplacez les éléments suivants :

    • CLUSTER1_CONTEXT : contexte du premier cluster, par exemple gke_my-project_europe-west3-c_gke-west.
    • CLUSTER2_CONTEXT : contexte du deuxième cluster (par exemple, gke_my-project_us-east4-a_gke-east).

  2. Déployez les ressources InferenceObjective sur les deux clusters. Enregistrez l'exemple de 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

    Remplacez les éléments suivants :

    • CLUSTER1_CONTEXT : contexte du premier cluster, par exemple gke_my-project_europe-west3-c_gke-west.
    • CLUSTER2_CONTEXT : contexte du deuxième cluster (par exemple, gke_my-project_us-east4-a_gke-east).

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

    Remplacez les éléments suivants :

    • CLUSTER1_CONTEXT : contexte du premier cluster, par exemple gke_my-project_europe-west3-c_gke-west.
    • CLUSTER2_CONTEXT : contexte du deuxième cluster, par exemple gke_my-project_us-east4-a_gke-east.

  5. Marquez les ressources InferencePool comme exportées sur les deux clusters. Cette annotation permet au InferencePool d'être importé par le cluster de configuration, ce qui est une étape obligatoire pour le routage 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

    Remplacez les éléments suivants :

    • CLUSTER1_CONTEXT : contexte du premier cluster, par exemple gke_my-project_europe-west3-c_gke-west.
    • CLUSTER2_CONTEXT : contexte du deuxième cluster, par exemple gke_my-project_us-east4-a_gke-east.

Déployer des ressources sur le cluster de configuration

Pour définir la façon dont le trafic est acheminé et équilibré entre les ressources InferencePool de tous les clusters enregistrés, déployez les ressources Gateway, HTTPRoute et HealthCheckPolicy. Vous ne déployez ces ressources que sur le cluster de configuration désigné, qui est gke-west dans ce document.

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

    ---
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. Appliquez le fichier manifeste :

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

    Remplacez CLUSTER1_CONTEXT par le contexte du premier cluster (le cluster de configuration), par exemple gke_my-project_europe-west3-c_gke-west.

Activer les rapports sur les métriques personnalisées

Pour activer le reporting des métriques personnalisées et améliorer l'équilibrage de charge multirégional, vous devez exporter les métriques d'utilisation du cache KV à partir de tous les clusters. L'équilibreur de charge utilise ces données d'utilisation du cache KV exportées comme signal de charge personnalisé. L'utilisation de ce signal de charge personnalisé permet de prendre des décisions d'équilibrage de charge plus intelligentes en fonction de la charge de travail réelle de chaque cluster.

  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 # 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. Appliquez la configuration des métriques aux deux clusters :

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

    Remplacez les éléments suivants :

    • CLUSTER1_CONTEXT : contexte du premier cluster, par exemple gke_my-project_europe-west3-c_gke-west.
    • CLUSTER2_CONTEXT : contexte du deuxième cluster, par exemple gke_my-project_us-east4-a_gke-east.

Configurer la règle d'équilibrage de charge

Pour optimiser la façon dont vos requêtes d'inférence d'IA/de ML sont distribuées sur vos clusters GKE, configurez une règle d'équilibrage de charge. Choisir le bon mode d'équilibrage permet d'assurer une utilisation efficace des ressources, d'éviter de surcharger les clusters individuels et d'améliorer les performances et la réactivité globales de vos services d'inférence.

Configurer les délais avant expiration

Si vos requêtes sont censées avoir une longue durée, configurez un délai avant expiration plus long pour l'équilibreur de charge. Dans GCPBackendPolicy, définissez le champ timeoutSec sur au moins le double de la latence de requête P99 estimée.

Par exemple, le fichier manifeste suivant définit le délai avant expiration de l'équilibreur de charge sur 100 secondes.

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

Pour en savoir plus, consultez la section Limites des passerelles multiclusters.

Étant donné que les modes d'équilibrage de charge Métriques personnalisées et Requêtes en cours s'excluent mutuellement, ne configurez qu'un seul de ces modes dans votre GCPBackendPolicy.

Choisissez un mode d'équilibrage de charge pour votre déploiement.

Métriques personnalisées

Pour un équilibrage de charge optimal, commencez par une utilisation cible de 60 %. Pour atteindre cette cible, définissez maxUtilization: 60 dans la configuration customMetrics de votre GCPBackendPolicy.

  1. Créez un fichier nommé backend-policy.yaml avec le contenu suivant pour activer l'équilibrage de charge basé sur la métrique personnalisée 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. 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.

Demandes en cours

Pour utiliser le mode d'équilibrage en cours de traitement, estimez le nombre de requêtes en cours de traitement que chaque backend peut gérer et configurez explicitement une valeur de capacité.

  1. Créez un fichier nommé backend-policy.yaml avec le contenu suivant pour activer l'équilibrage de charge en fonction du nombre de requêtes en cours :

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

Vérifier le déploiement

Pour vérifier l'équilibreur de charge interne, vous devez envoyer des requêtes depuis votre réseau VPC, car les équilibreurs de charge internes utilisent des adresses IP privées. Exécutez un pod temporaire dans l'un des clusters pour envoyer des requêtes depuis votre réseau VPC et vérifier l'équilibreur de charge interne :

  1. Démarrez une session shell interactive dans un pod temporaire :

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

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

  2. À partir du nouveau shell, récupérez l'adresse IP de la passerelle et envoyez une requête de 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
}'

    Voici un exemple de réponse positive :

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

Étapes suivantes