Configura la GKE Inference Gateway de varios clústeres

En este documento, se describe cómo configurar la puerta de enlace de inferencia de Google Kubernetes Engine (GKE) de varios clústeres para balancear la carga de forma inteligente de tus cargas de trabajo de inferencia de IA/ML en varios clústeres de GKE, que pueden abarcar diferentes regiones. Esta configuración usa la API de Gateway, Ingress de varios clústeres y recursos personalizados, como InferencePool y InferenceObjective, para ayudar a mejorar la escalabilidad, garantizar la alta disponibilidad y optimizar el uso de recursos para tus implementaciones de entrega de modelos.

Para comprender este documento, debes conocer lo siguiente:

• Organización de IA/AA en GKE.
• Terminología de la IA generativa.
• Conceptos de redes de GKE, incluidos los siguientes:
  • Servicios
  • Ingress de varios clústeres de GKE
  • API de Gateway
• Balanceo de cargas enCloud de Confiance, en especial, cómo interactúan los balanceadores de cargas con GKE

Este documento está dirigido a las siguientes personas:

• Ingenieros de aprendizaje automático (AA), administradores y operadores de plataformas, o especialistas en IA y datos que deseen usar las capacidades de organización de contenedores de GKE para entregar cargas de trabajo de IA/AA
• Arquitectos de nube o especialistas en redes que interactúan con las redes de GKE

Para obtener más información sobre los roles comunes y las tareas de ejemplo a las que se hace referencia en el contenido deCloud de Confiance by S3NS , consulta Roles de usuario y tareas comunes de GKE Enterprise.

Antes de comenzar

Antes de comenzar, asegúrate de haber realizado las siguientes tareas:

• Habilita la API de Google Kubernetes Engine.
Habilitar la API de Google Kubernetes Engine
• Si deseas usar Google Cloud CLI para esta tarea, instala y, luego, inicializa gcloud CLI. Si ya instalaste la gcloud CLI, ejecuta el comando gcloud components update para obtener la versión más reciente. Es posible que las versiones anteriores de gcloud CLI no admitan la ejecución de los comandos que se indican en este documento.

• Habilita la API de Compute Engine, la API de Kubernetes Engine, Model Armor y la API de Network Services.

  Ve a Habilita el acceso a las APIs y sigue las instrucciones.

• Habilita la API de Autoscaling.

  Ve a la API de ajuste de escala automático y sigue las instrucciones.

• Habilita la API de GKE Hub.

  Ve a la API de GKE Hub y sigue las instrucciones.

  Como alternativa, usa Google Cloud CLI:

  gcloud services enable gkehub.googleapis.com --project=PROJECT_ID
  

• Requisitos previos de Hugging Face:

  • Crea una cuenta de Hugging Face si aún no tienes una.
  • Solicita y obtén la aprobación para acceder al modelo Qwen3-32B en Hugging Face.
  • Firma el acuerdo de consentimiento de licencia en la página del modelo en Hugging Face.
  • Genera un token de acceso de Hugging Face con, al menos, permisos de Read.

Requisitos

• Asegúrate de que tu proyecto tenga la cuota suficiente para las GPU H100. Para obtener más información, consulta Planifica la cuota de GPU y Cuotas de asignación.
• Usa la versión 1.34.1-gke.1127000 de GKE o una posterior.
• Usa la versión 480.0.0 o posterior de gcloud CLI.
• Las cuentas de servicio de tus nodos deben tener permisos para escribir métricas en la API de Autoscaling.
• Debes tener los siguientes roles de IAM en el proyecto: roles/container.admin y roles/iam.serviceAccountAdmin.
• Todos los clústeres que registres en la flota, incluido el clúster de configuración, deben estar en la misma red de VPC. Las Gateways de varios clústeres no admiten el balanceo de cargas en clústeres de diferentes redes de VPC.

Límites de puertos múltiples y NEG

Cuando implementes recursos de InferencePool de varios puertos en una configuración de varios clústeres, ten en cuenta el límite de NEG del servicio de backend de Cloud de Confiance by S3NS . Cada puerto de cada zona crea un NEG dedicado. Por ejemplo, un clúster regional con tres zonas y un InferencePool configurado con ocho puertos utilizará 24 NEG. Dado que un servicio de backend se limita a 50 NEG, solo puedes agregar este InferencePool específico desde un máximo de dos clústeres antes de alcanzar el límite.

Configura una puerta de enlace de inferencia de varios clústeres

Para configurar la puerta de enlace de inferencia de GKE de varios clústeres, sigue estos pasos:

Crea clústeres y grupos de nodos

Para alojar tus cargas de trabajo de inferencia de IA/AA y habilitar el balanceo de cargas entre regiones, crea dos clústeres de GKE en diferentes regiones, cada uno con un grupo de nodos de GPU H100.

1. Crea el primer clúster:

   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
   

   Reemplaza lo siguiente:

   • CLUSTER_1_NAME: Es el nombre del primer clúster, por ejemplo, gke-west.
   • LOCATION: la región del primer clúster, por ejemplo, europe-west3.
   • PROJECT_ID: el ID de tu proyecto
   • GKE_VERSION: Es la versión de GKE que se usará, por ejemplo, 1.34.1-gke.1127000.
   • MACHINE_TYPE: Es el tipo de máquina para los nodos del clúster, por ejemplo, c2-standard-16.
   • DISK_TYPE: Es el tipo de disco para los nodos del clúster, por ejemplo, pd-standard.

2. Crea un grupo de nodos H100 para el primer clúster:

   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
   

   Reemplaza lo siguiente:

   • NODE_POOL_NAME: el nombre del grupo de nodos, por ejemplo, h100
   • PROJECT_ID: el ID de tu proyecto
   • CLUSTER_1_ZONE: Es la zona del primer clúster, por ejemplo, europe-west3-c.
   • CLUSTER_1_NAME: Es el nombre del primer clúster, por ejemplo, gke-west.
   • NODE_POOL_MACHINE_TYPE: Es el tipo de máquina del grupo de nodos, por ejemplo, a3-highgpu-2g.
   • NUM_NODES: Es la cantidad de nodos en el grupo de nodos, por ejemplo, 3.

3. Obtén las credenciales:

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

   Reemplaza lo siguiente:

   • PROJECT_ID: el ID de tu proyecto
   • CLUSTER_1_NAME: Es el nombre del primer clúster, por ejemplo, gke-west.
   • CLUSTER_1_ZONE: Es la zona del primer clúster, por ejemplo, europe-west3-c.

4. En el primer clúster, crea un secreto para el token de Hugging Face:

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

   Reemplaza HF_TOKEN por tu token de acceso de Hugging Face.

5. Crea el segundo clúster en una región diferente a la del primer clúster:

   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.
   

   Reemplaza lo siguiente:

   • LOCATION: Es la región del segundo clúster. Debe ser una región diferente a la del primer clúster. Por ejemplo, us-east4
   • PROJECT_ID: el ID de tu proyecto
   • GKE_VERSION: Es la versión de GKE que se usará, por ejemplo, 1.34.1-gke.1127000.
   • MACHINE_TYPE: Es el tipo de máquina para los nodos del clúster, por ejemplo, c2-standard-16.
   • DISK_TYPE: Es el tipo de disco para los nodos del clúster, por ejemplo, pd-standard.

6. Crea un grupo de nodos H100 para el segundo clúster:

   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
   

   Reemplaza lo siguiente:

   • PROJECT_ID: el ID de tu proyecto
   • CLUSTER_2_ZONE: Es la zona del segundo clúster, por ejemplo, us-east4-a.
   • CLUSTER_2_NAME: Es el nombre del segundo clúster, por ejemplo, gke-east.
   • NODE_POOL_MACHINE_TYPE: Es el tipo de máquina del grupo de nodos, por ejemplo, a3-highgpu-2g.
   • NUM_NODES: Es la cantidad de nodos en el grupo de nodos, por ejemplo, 3.

7. Para el segundo clúster, obtén credenciales y crea un secreto para el token de 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
   

   Reemplaza lo siguiente:

   • CLUSTER_2_NAME: Es el nombre del segundo clúster, por ejemplo, gke-east.
   • CLUSTER_2_ZONE: Es la zona del segundo clúster, por ejemplo, us-east4-a.
   • PROJECT_ID: el ID de tu proyecto
   • HF_TOKEN: Tu token de acceso de Hugging Face.

Registra clústeres en una flota

Para habilitar las capacidades de varios clústeres, como la puerta de enlace de inferencia de GKE de varios clústeres, registra tus clústeres en una flota.

1. Establece la anulación del extremo de API para evitar problemas de mTLS durante el registro.

   gcloud config set api_endpoint_overrides/container https://container.googleapis.com/
   

2. Registra ambos clústeres en la flota de tu proyecto:

   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
   

   Reemplaza lo siguiente:

   • CLUSTER_1_NAME: Es el nombre del primer clúster, por ejemplo, gke-west.
   • CLUSTER_1_ZONE: Es la zona del primer clúster, por ejemplo, europe-west3-c.
   • PROJECT_ID: el ID de tu proyecto
   • CLUSTER_2_NAME: Es el nombre del segundo clúster, por ejemplo, gke-east.
   • CLUSTER_2_ZONE: Es la zona del segundo clúster, por ejemplo, us-east4-a.

3. Para permitir que una sola puerta de enlace administre el tráfico en varios clústeres, habilita la función de Ingress de varios clústeres y designa un clúster de configuración:

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

   Reemplaza lo siguiente:

   • PROJECT_ID: el ID de tu proyecto
   • CLUSTER_1_NAME: Es el nombre del primer clúster, por ejemplo, gke-west.

Crea subredes de solo proxy

En el caso de una puerta de enlace interna, crea una subred de solo proxy en cada región. Los proxies de Envoy de la puerta de enlace interna usan estas subredes dedicadas para controlar el tráfico dentro de tu red de VPC.

Advertencia: Cloud de Confiance by S3NS Solo se permite una subred de solo proxy por región en cada red de VPC. Si la región de destino ya contiene una subred de solo proxy con el parámetro de configuración purpose=REGIONAL_MANAGED_PROXY, falla la creación de la subred GLOBAL_MANAGED_PROXY. Primero debes borrar la subred de solo proxy regional existente. Borrar una subred regional de solo proxy afecta a todos los balanceadores de cargas regionales basados en Envoy de esa región que la usan, por lo que debes planificar el cambio en consecuencia.

1. Crea una subred en la región del primer clúster:

   gcloud compute networks subnets create CLUSTER_1_REGION-subnet \
       --purpose=GLOBAL_MANAGED_PROXY \
       --role=ACTIVE \
       --region=CLUSTER_1_REGION \
       --network=default \
       --range=10.0.0.0/23 \
       --project=PROJECT_ID
   

2. Crea una subred en la región del segundo clúster:

   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
   

   Reemplaza lo siguiente:

   • PROJECT_ID: el ID de tu proyecto
   • CLUSTER_1_REGION: Es la región del primer clúster, por ejemplo, europe-west3.
   • CLUSTER_2_REGION: Es la región del segundo clúster, por ejemplo, us-east4.

Instala los CustomResourceDefinitions requeridos

La puerta de enlace de inferencia de GKE de varios clústeres usa recursos personalizados, como InferencePool y InferenceObjective. El controlador de la API de GKE Gateway administra el CustomResourceDefinition de InferencePool. Sin embargo, debes instalar manualmente el CustomResourceDefinition de InferenceObjective, que se encuentra en versión alfa, en tus clústeres.

1. Define variables de contexto para tus clústeres:

   CLUSTER1_CONTEXT="gke_PROJECT_ID_CLUSTER_1_ZONE_CLUSTER_1_NAME"
   CLUSTER2_CONTEXT="gke_PROJECT_ID_CLUSTER_2_ZONE_CLUSTER_2_NAME"
   

   Reemplaza lo siguiente:

   • PROJECT_ID: el ID de tu proyecto
   • CLUSTER_1_ZONE: Es la zona del primer clúster, por ejemplo, europe-west3-c.
   • CLUSTER_1_NAME: Es el nombre del primer clúster, por ejemplo, gke-west.
   • CLUSTER_2_ZONE: Es la zona del segundo clúster, por ejemplo, us-east4-a.
   • CLUSTER_2_NAME: Es el nombre del segundo clúster, por ejemplo, gke-east.

2. Instala el CustomResourceDefinition de InferenceObjective en ambos clústeres:

   kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/gateway-api-inference-extension/v1.5.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.5.0/config/crd/bases/inference.networking.x-k8s.io_inferenceobjectives.yaml --context=$CLUSTER2_CONTEXT
   

Implementa recursos en los clústeres de destino

Para que tus cargas de trabajo de inferencia de IA/AA estén disponibles en cada clúster, implementa los recursos necesarios, como los servidores de modelos y los recursos personalizados de InferenceObjective.

Nota: Los ejemplos de este documento usan vLLM, pero Inference Gateway de varios clústeres es independiente de la plataforma del servidor de modelos y también funciona con otros servidores de modelos, como SGLang. Si usas otro servidor de modelos, ajusta la siguiente configuración:

• Puerto de servicio. Configura el puerto de destino InferencePool, el puerto HealthCheckPolicy y el puerto de extremo AutoscalingMetric en el puerto de entrega de tu servidor de modelos. Por ejemplo, SGLang se ejecuta en el puerto 30000 de forma predeterminada en lugar del puerto 8000.
• Nombres de las métricas. Los nombres de las métricas son específicos de cada servidor de modelos. Por ejemplo, SGLang informa la utilización de la caché de KV como la métrica sglang:token_usage en lugar de la métrica vllm:kv_cache_usage_perc. Asigna la métrica de tu servidor de modelos al nombre de exportación kv-cache en el recurso AutoscalingMetric. La extracción de métricas personalizadas para servidores de modelos que no sean vLLM requiere una imagen de Endpoint Picker (EPP) compatible. Usa la versión de gráfico compatible más reciente.
• Entrega de modelos de varios nodos. Si una réplica del modelo abarca varios nodos (por ejemplo, cuando usas la API de LeaderWorkerSet para entregar un modelo grande), solo el Pod líder (rango 0) entrega la API. Configura el selector InferencePool modelServers.matchLabels para que solo coincida con los Pods líderes, por ejemplo, agregando la etiqueta apps.kubernetes.io/pod-index: "0". Si el selector también coincide con los Pods de trabajadores, la puerta de enlace enruta las solicitudes a los Pods que no pueden atenderlas, y esas solicitudes fallan con un código de estado HTTP 404 Not Found.

1. Implementa los servidores de modelos en ambos clústeres:

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

2. Implementa los recursos de InferenceObjective en ambos clústeres. Guarda el siguiente manifiesto de muestra en un archivo llamado inference-objective.yaml:

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

3. Aplica el manifiesto a ambos clústeres:

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

   Reemplaza lo siguiente:

   • $CLUSTER1_CONTEXT: Es el contexto del primer clúster, por ejemplo, gke_my-project_europe-west3-c_gke-west.
   • $CLUSTER2_CONTEXT: Es el contexto del segundo clúster, por ejemplo, gke_my-project_us-east4-a_gke-east.

4. Implementa los recursos de InferencePool en ambos clústeres con Helm:

     helm install vllm-qwen3-32b \
     --kube-context $CLUSTER1_CONTEXT \
     --set inferencePool.modelServers.matchLabels.app=vllm-qwen3-32b \
     --set provider.name=gke \
     --set inferenceExtension.monitoring.gke.enabled=true \
     --version v1.5.0 \
     oci://registry.k8s.io/gateway-api-inference-extension/charts/inferencepool
   

   helm install vllm-qwen3-32b \
     --kube-context $CLUSTER2_CONTEXT \
     --set inferencePool.modelServers.matchLabels.app=vllm-qwen3-32b \
     --set provider.name=gke \
     --set inferenceExtension.monitoring.gke.enabled=true \
     --version v1.5.0 \
     oci://registry.k8s.io/gateway-api-inference-extension/charts/inferencepool
   

   Los comandos anteriores usan la versión v1.5.0 del gráfico de Helm porque es una versión recomendada para esta configuración. El gráfico de Helm también instala un recurso personalizado GCPBackendPolicy y un recurso personalizado HealthCheckPolicy diseñados para usarse en un solo clúster.

   En la versión v1.1.0 del gráfico de Helm InferencePool, es posible que se ignore la marca --set inferencePool.targetPortNumber y que el puerto de destino se establezca de forma predeterminada en 8000. Si tu servidor de modelos escucha en un puerto diferente (por ejemplo, SGLang se ejecuta en el puerto 30000 de forma predeterminada), verifica el puerto después de la instalación:

   kubectl get inferencepool POOL_NAME -o jsonpath='{.spec.targetPorts}' \
       --context=CLUSTER_CONTEXT
   

   Si el puerto es incorrecto, aplica un parche al recurso personalizado InferencePool antes de exportarlo:

   kubectl patch inferencepool POOL_NAME --type=merge \
       -p '{"spec":{"targetPorts":[{"number":TARGET_PORT}]}}' \
       --context=CLUSTER_CONTEXT
   

5. Marca los recursos de InferencePool como exportados en ambos clústeres. Esta anotación hace que InferencePool esté disponible para la importación por parte del clúster de configuración, lo que es un paso obligatorio para el enrutamiento de varios clústeres.

   kubectl annotate inferencepool vllm-qwen3-32b networking.gke.io/export="True" \
       --context=$CLUSTER1_CONTEXT
   

   kubectl annotate inferencepool vllm-qwen3-32b networking.gke.io/export="True" \
       --context=$CLUSTER2_CONTEXT
   

Implementa recursos en el clúster de configuración

Para definir cómo se enruta y balancea la carga del tráfico en los recursos de InferencePool de todos los clústeres registrados, implementa los recursos Gateway, HTTPRoute y HealthCheckPolicy. Implementas estos recursos solo en el clúster de configuración designado, que es gke-west en este documento.

1. Crea un archivo llamado mcig.yaml con el siguiente contenido:

   ---
   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-qwen3-32b-default
   spec:
     parentRefs:
     - name: cross-region-gateway
       kind: Gateway
     rules:
     - backendRefs:
       - group: networking.gke.io
         kind: GCPInferencePoolImport
         name: vllm-qwen3-32b
   ---
   apiVersion: networking.gke.io/v1
   kind: HealthCheckPolicy
   metadata:
     name: health-check-policy
     namespace: default
   spec:
     targetRef:
       group: "networking.gke.io"
       kind: GCPInferencePoolImport
       name: vllm-qwen3-32b
     default:
       config:
         type: HTTP
         httpHealthCheck:
           requestPath: /health
           port: 8000
   

2. Aplica el manifiesto

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

Habilita los informes de métricas personalizadas

Para habilitar la generación de informes de métricas personalizadas y ayudar a mejorar el balanceo de cargas entre regiones, debes exportar las métricas de uso de la caché de KV de todos los clústeres. El balanceador de cargas usa estos datos de uso de la caché de KV exportados como un indicador de carga personalizado. El uso de este indicador de carga personalizado permite tomar decisiones de balanceo de cargas más inteligentes basadas en la carga de trabajo real de cada clúster.

1. Crea un archivo llamado metrics.yaml con el siguiente contenido:

   apiVersion: autoscaling.gke.io/v1beta1
   kind: AutoscalingMetric
   metadata:
     name: gpu-cache
     namespace: default
   spec:
     selector:
       matchLabels:
         app: vllm-qwen3-32b
     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. Aplica la configuración de métricas a ambos clústeres:

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

Configura la política de balanceo de cargas

Para optimizar la forma en que las solicitudes de inferencia de IA/AA se distribuyen en tus clústeres de GKE, configura una política de balanceo de cargas. Un modo de balanceo adecuado ayuda a garantizar el uso eficiente de los recursos, evita la sobrecarga de clústeres individuales y ayuda a mejorar el rendimiento y la capacidad de respuesta de tus servicios de inferencia.

Configura los tiempos de espera

Si se espera que tus solicitudes tengan duraciones prolongadas, configura un tiempo de espera más largo para el balanceador de cargas. En GCPBackendPolicy, establece el campo timeoutSec en al menos el doble de la latencia de solicitud del percentil 99 estimada. Para las cargas de trabajo de inferencia de contexto extenso con alta simultaneidad, es posible que necesites un tiempo de espera de hasta 3600 segundos. Por ejemplo, el siguiente manifiesto establece el tiempo de espera del balanceador de cargas en 600 segundos.

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
spec:
  targetRef:
    group: "networking.gke.io"
    kind: GCPInferencePoolImport
    name: vllm-qwen3-32b
  default:
    timeoutSec: 600
    balancingMode: CUSTOM_METRICS
    trafficDuration: LONG
    customMetrics:
      - name: gke.named_metrics.kv-cache
        dryRun: false
        maxUtilizationPercent: 60

Para obtener más información, consulta las limitaciones de la puerta de enlace de varios clústeres.

Dado que los modos de balanceo de cargas Métricas personalizadas y Solicitudes en tránsito son mutuamente excluyentes, configura solo uno de estos modos en tu GCPBackendPolicy.

Elige un modo de balanceo de cargas para tu implementación.

Verifica la implementación

Para verificar el balanceador de cargas interno, debes enviar solicitudes desde tu red de VPC, ya que los balanceadores de cargas internos usan direcciones IP privadas. Ejecuta un Pod temporal dentro de uno de los clústeres para enviar solicitudes desde tu red de VPC y verificar el balanceador de cargas interno:

1. En el nuevo shell, obtén la dirección IP de la puerta de enlace:

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

2. Envía una solicitud de prueba desde un Pod temporal dentro del clúster:

   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": "Qwen/Qwen3-32B",
     "prompt": "What is the best pizza in the world?",
     "max_tokens": 100,
     "temperature": 0
     }'
   

¿Qué sigue?

• Obtén más información sobre la API de GKE Gateway.
• Obtén más información sobre la puerta de enlace de GKE Inference de varios clústeres.
• Obtén más información sobre Ingress de varios clústeres.