Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Configurer la passerelle GKE Inference multicluster

Ce document explique comment configurer la passerelle d'inférence Google Kubernetes Engine (GKE) multicluster 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 qu'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 :

Orchestration d'IA/ML sur GKE
Terminologie de l'IA générative
Concepts de mise en réseau GKE, y compris :
Équilibrage de charge dansGoogle Cloud, en particulier l'interaction des équilibreurs de charge avec GKE.

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.
Remarque : Pour les installations de la gcloud CLI existantes, veillez à définir la propriété compute/region. Si vous utilisez principalement des clusters zonaux, définissez plutôt compute/zone. En définissant un emplacement par défaut, vous pouvez éviter les erreurs gcloud CLI de ce type : One of [--zone, --region] must be supplied: Please specify location. Vous devrez peut-être spécifier l'emplacement dans certaines commandes si celui de votre cluster diffère de l'emplacement par défaut que vous avez défini.

Activez l'API Compute Engine, l'API Kubernetes Engine, Model Armor et l'API 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.

Limites multiports et NEG

Lorsque vous déployez des ressources InferencePool multiports dans une configuration multicluster, tenez compte de la limite de NEG de service de backend Google Cloud . Chaque port de chaque zone crée un NEG dédié. Par exemple, un cluster régional avec trois zones et un InferencePool configuré avec huit ports utilisera 24 NEG. Étant donné qu'un service de backend est limité à 50 NEG, vous ne pouvez agréger ce pool d'inférence spécifique qu'à partir de deux clusters maximum avant d'atteindre la limite.

Configurer une passerelle d'inférence multicluster

Pour configurer la passerelle d'inférence GKE multicluster, 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.

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.
Remarque : L'option --async permet à la commande de renvoyer immédiatement un résultat pendant que GKE crée le cluster en arrière-plan. La commande get-credentials suivante attend que le cluster soit entièrement provisionné.
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.
Remarque : L'utilisation de l'option --spot crée un pool de nœuds VM Spot, qui peut être préempté. Les VM Spot sont souvent adaptées aux charges de travail d'inférence d'IA/de ML, car elles permettent de réaliser des économies considérables. De plus, les tâches d'inférence peuvent souvent être conçues pour résister aux interruptions.
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.
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.
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.
Remarque : Pour activer l'équilibrage de charge interrégional, assurez-vous que le deuxième cluster se trouve dans une région différente de celle du premier cluster.

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.

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 GKE Inference multicluster, enregistrez vos clusters dans un parc.

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

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

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

GKE Inference Gateway multicluster 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.

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.

Installez le CRD InferenceObjective sur les deux clusters :

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

Déployer des ressources sur les clusters cibles

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

Déployez les serveurs de modèles 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).

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"

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

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

Marquez les ressources InferencePool comme exportées sur les deux clusters. Cette annotation permet au cluster de configuration d'importer InferencePool, 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 dans 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.

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

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.

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

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
        maxUtilizationPercent: 60

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 maxUtilizationPercent: 60 dans la configuration customMetrics de votre GCPBackendPolicy.

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
        maxUtilizationPercent: 60

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

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

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 :

Dans le nouveau shell, récupérez l'adresse IP de la passerelle :

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

Envoyez une requête de test à partir d'un pod temporaire dans le cluster :

kubectl run -it --rm --image=curlimages/curl curly --context=$CLUSTER1_CONTEXT -- \
  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
  }'

Étapes suivantes

En savoir plus sur l'API GKE Gateway
En savoir plus sur la passerelle d'inférence GKE multiclusters
En savoir plus sur Multi Cluster Ingress

Configurer la passerelle GKE Inference multicluster Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Avant de commencer

Conditions requises

Limites multiports et NEG

Configurer une passerelle d'inférence multicluster

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

Enregistrer des clusters dans un parc

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

Installer les CRD requises

Déployer des ressources sur les clusters cibles

Déployer des ressources sur le cluster de configuration

Activer les rapports sur les métriques personnalisées

Configurer la règle d'équilibrage de charge

Configurer les délais avant expiration

Métriques personnalisées

Demandes en cours

Vérifier le déploiement

Étapes suivantes

Configurer la passerelle GKE Inference multicluster