Configura la alta disponibilidad elástica entre regiones

En este documento, se muestra cómo configurar la alta disponibilidad elástica en varias regiones para las cargas de trabajo de inferencia de IA con la puerta de enlace de inferencia de varios clústeres de Google Kubernetes Engine (GKE) y la función de ajuste de escala automático de GKE. Esta configuración te permite balancear las cargas de trabajo de forma inteligente en varios clústeres de GKE en diferentes regiones.

Para obtener más información sobre GKE Multi-Cluster Inference Gateway, consulta Acerca de GKE Multi-Cluster Inference Gateway.

Antes de comenzar

  1. Habilita la API de Google Kubernetes Engine.

    Habilitar la API de Google Kubernetes Engine

  2. Instala e inicializa Google Cloud CLI si planeas usarla para esta tarea.

  3. Asegúrate de que tu proyecto tenga la cuota suficiente para las GPU H100. Para obtener más información, consulta Cuota de GPU y asignación de recursos.

  4. Usa la versión 1.34.1-gke.1127000 de GKE o una posterior.

  5. Usa la versión 480.0.0 o posterior de gcloud CLI.

  6. Asegúrate de que la cuenta de servicio que usan tus nodos tenga los permisos roles/monitoring.metricWriter y roles/stackdriver.resourceMetadata.writer.

  7. Asegúrate de tener los roles de Identity and Access Management (IAM) roles/container.admin y roles/iam.serviceAccountAdmin en el proyecto.

  8. Completa los siguientes requisitos previos de Hugging Face:

    1. Crea una cuenta de Hugging Face.
    2. Solicita y obtén la aprobación para acceder al modelo Llama 3.1 en Hugging Face.
    3. Firma el acuerdo de consentimiento de licencia en la página del modelo en Hugging Face.
    4. Genera un token de acceso de Hugging Face con, al menos, permisos de lectura.

Crea clústeres y grupos de nodos

Para crear dos clústeres de GKE en diferentes regiones y configurar sus grupos de nodos, sigue estos pasos:

  1. Crea el primer clúster:

    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

    Reemplaza lo siguiente:

    • PROJECT_ID: Es el ID del proyecto.
    • CLUSTER_1_ZONE: la zona del primer clúster, por ejemplo, europe-west3-c
    • GKE_VERSION: 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 en el primer clúster:

    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

    Reemplaza lo siguiente:

    • PROJECT_ID: Es el ID del proyecto.
    • CLUSTER_1_ZONE: la zona del primer clúster, por ejemplo, europe-west3-c
    • CLUSTER_1_NAME: El nombre del primer clúster, por ejemplo, gke-west
    • NODE_POOL_MACHINE_TYPE: el tipo de máquina del grupo de nodos, por ejemplo, a3-highgpu-2g
    • NUM_NODES: La cantidad de nodos en el grupo de nodos, por ejemplo, 3
    • MIN_NUM_NODES: Es la cantidad mínima de nodos para el ajuste de escala automático en el grupo de nodos, por ejemplo, 1.
    • MAX_NUM_NODES: Es la cantidad máxima de nodos para el ajuste de escala automático en el grupo de nodos, por ejemplo, 10.

  3. Obtén credenciales y crea un secreto de token de Hugging Face en el primer clúster:

    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

    Reemplaza lo siguiente:

    • PROJECT_ID: Es el ID del proyecto.
    • CLUSTER_1_NAME: El nombre del primer clúster, por ejemplo, gke-west
    • CLUSTER_1_ZONE: la zona del primer clúster, por ejemplo, europe-west3-c
    • HF_TOKEN: Tu token de acceso de Hugging Face

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

    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

    Reemplaza CLUSTER_2_ZONE por la zona del segundo clúster, por ejemplo, us-east4-a.

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

    Reemplaza lo siguiente:

    • PROJECT_ID: Es el ID del proyecto.
    • CLUSTER_2_ZONE: la zona del segundo clúster, por ejemplo, us-east4-a
    • CLUSTER_2_NAME: El nombre del segundo clúster, por ejemplo, gke-east
    • NODE_POOL_MACHINE_TYPE: el tipo de máquina del grupo de nodos, por ejemplo, a3-highgpu-2g
    • NUM_NODES: La cantidad de nodos en el grupo de nodos, por ejemplo, 3
    • MIN_NUM_NODES: Es la cantidad mínima de nodos para el ajuste de escala automático en el grupo de nodos, por ejemplo, 1.
    • MAX_NUM_NODES: Es la cantidad máxima de nodos para el ajuste de escala automático en el grupo de nodos, por ejemplo, 10.

  6. Obtén credenciales y crea un secreto para el token de Hugging Face en el segundo clúster:

    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. Para ver las definiciones de otras variables, consulta los pasos anteriores:

    • HF_TOKEN: Tu token de acceso de Hugging Face

Registra clústeres en una flota

  1. Registra tus 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 y consulta los pasos anteriores para conocer las definiciones de otras variables:

    • CLUSTER_1_NAME: El nombre del primer clúster, por ejemplo, gke-west
    • CLUSTER_2_NAME: El nombre del segundo clúster, por ejemplo, gke-east

  2. Habilita la función de entrada 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. Para ver las definiciones de otras variables, consulta los pasos anteriores:

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

Crea subredes de solo proxy

Advertencia: Cloud de Confiance by S3NS permite que cada red de VPC tenga solo una subred de solo proxy por región. 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=SUBNET_RANGE_1 \
    --project=PROJECT_ID

    Reemplaza lo siguiente:

    • PROJECT_ID: Es el ID del proyecto.
    • CLUSTER_1_REGION: la región del primer clúster, por ejemplo, europe-west3
    • SUBNET_RANGE_1: Es el rango de IP de la subred solo para proxy en la región del primer clúster, por ejemplo, 10.0.0.0/23.

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

    Reemplaza lo siguiente:

    • PROJECT_ID: Es el ID del proyecto.
    • CLUSTER_2_REGION: la región del segundo clúster, por ejemplo, us-east4
    • SUBNET_RANGE_2: Es el rango de IP de la subred solo de proxy en la región del segundo clúster, por ejemplo, 10.5.0.0/23.

Instala los recursos personalizados requeridos

  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: Es el ID del proyecto.
    • CLUSTER_1_ZONE: la zona del primer clúster, por ejemplo, europe-west3-c
    • CLUSTER_1_NAME: El nombre del primer clúster, por ejemplo, gke-west
    • CLUSTER_2_ZONE: la zona del segundo clúster, por ejemplo, us-east4-a
    • CLUSTER_2_NAME: El nombre del segundo clúster, por ejemplo, gke-east

  2. Instala el recurso personalizado InferencePool y InferenceObjective en ambos clústeres:

    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

Implementa recursos en los clústeres de destino

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

    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. Guarda el siguiente manifiesto como un archivo llamado 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. 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

  4. Implementa los recursos de InferencePool en ambos clústeres con 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. En ambos clústeres, marca los recursos InferencePool como exportados:

    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

Implementa la puerta de enlace de inferencia interregional

  1. Guarda el siguiente manifiesto como 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. Aplica el manifiesto al clúster de configuración:

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

    Reemplaza lo siguiente:

    • CLUSTER1_CONTEXT: Es el contexto del primer clúster, por ejemplo, gke_my-project_europe-west3-c_gke-west.

Habilita los informes de métricas personalizadas

  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-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. Para cada clúster, aplica la configuración de métricas:

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

    Para obtener las definiciones de CLUSTER1_CONTEXT y CLUSTER2_CONTEXT, consulta Instala los recursos personalizados requeridos.

Configura la política de balanceo de cargas

En esta sección, se describe cómo configurar la política de balanceo de cargas. Esta política define cómo se distribuye el tráfico en tus grupos de inferencia según las métricas personalizadas y las preferencias regionales. La siguiente configuración establece us-east4 como la región preferida. El tráfico se desborda a otras regiones solo cuando la métrica personalizada gke.named_metrics.kv-cache en la región us-east4 alcanza el 80% de utilización.

  • Para las versiones v0.10.2 y posteriores de vLLM, usa la métrica gke.named_metrics.kv-cache.
  • Para versiones anteriores, usa la métrica gke.named_metrics.kv-cache-old.

  1. Crea un archivo llamado backend-policy.yaml con el siguiente contenido:

    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. Aplica la política nueva:

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

    Reemplaza CLUSTER1_CONTEXT por el contexto del primer clúster, por ejemplo, gke_my-project_europe-west3-c_gke-west.

Configurar ajuste de escala automático

Para garantizar que cada clúster pueda controlar una carga cada vez mayor antes de que el tráfico se desborde hacia otras regiones, debes configurar el escalador automático horizontal de Pods (HPA) para las implementaciones de tu servidor de modelos.

Principios clave de configuración

  • Usa las mismas métricas personalizadas: El HPA debe configurarse para realizar el escalamiento en función de las mismas métricas personalizadas que usas en GCPBackendPolicy para la puerta de enlace de inferencia de varios clústeres (por ejemplo, vllm:kv_cache_usage_perc). Este enfoque ayuda a garantizar que tanto el balanceo de cargas como las decisiones de escalamiento se basen en el mismo indicador de tus servidores de inferencia. Las métricas que elijas deben tener un valor entre 0 y 1 para representar la utilización. Si el valor de la métrica es mayor que 1, se interpreta como un uso del 100% por parte del balanceador de cargas, lo que puede provocar comportamientos de enrutamiento inesperados.

  • Establece un objetivo de HPA más bajo: El valor objetivo de la métrica en la configuración de HPA debe establecerse en un valor inferior al parámetro de configuración maxUtilizationPercent que se define en GCPBackendPolicy. Si estableces un uso objetivo más bajo para el HPA (por ejemplo, el HPA se ajusta al 50% de uso promedio), permites que el clúster agregue más réplicas antes de que se alcance el umbral del balanceador de cargas (por ejemplo, el 80% de uso). Este enfoque ayuda a maximizar la capacidad dentro de la región preferida. Un objetivo de utilización más bajo también ayuda a evitar el desbordamiento prematuro del tráfico, ya que reserva la alta disponibilidad elástica entre regiones para cuando la región actual se acerca realmente a sus límites.

  1. Otórgale al usuario la capacidad de crear los roles de autorización requeridos:

    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

    Las variables CLUSTER1_CONTEXT y CLUSTER2_CONTEXT se definen en la sección Instala los recursos personalizados requeridos.

  2. Aplica el manifiesto a cada clúster:

    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. Permite que la cuenta de servicio custom-metrics-stackdriver-adapter lea las métricas de 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

    Reemplaza PROJECT_ID por el ID del proyecto

  4. Guarda el siguiente manifiesto como un archivo llamado 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. Aplica el manifiesto a ambos clústeres:

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

  6. Guarda el siguiente manifiesto como un archivo llamado 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. Aplica el manifiesto a ambos clústeres:

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

Verifica la implementación

  1. Obtén la dirección IP de la puerta de enlace:

    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 se define en la sección Instala los recursos personalizados requeridos.

  2. Inicia una sesión interactiva de sh en un Pod temporal:

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

    La variable CLUSTER1_CONTEXT se define en la sección Instala los recursos personalizados requeridos.

  3. Desde el Pod curly, envía una solicitud de prueba:

    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
}'

    Reemplaza GW_IP por la dirección IP de la puerta de enlace del paso anterior.

Realiza una prueba de carga en la puerta de enlace

  1. Aplica una carga sostenida a la dirección IP de la puerta de enlace con un generador de carga dentro de la misma red de VPC.

  2. Comienza con una carga moderada que esperas que la región preferida (us-east4) pueda controlar.

  3. Aumenta gradualmente la tasa de solicitudes o la simultaneidad de tu prueba de carga.

  4. Mientras se ejecuta la prueba de carga, supervisa el sistema en la consola de Cloud de Confiance o con kubectl:

    • Escalado de Pods (HPA): Verifica la cantidad de Pods en la Deployment de vllm-llama3-8b-instruct en ambos clústeres.
    • Ajuste de escala de nodos (escalador automático de clústeres): Supervisa la cantidad de nodos en los grupos de nodos h100 de ambos clústeres.
    • Métricas personalizadas: Observa la métrica vllm:kv_cache_usage_perc (para la versión v0.10.2 y versiones posteriores de vllm) o la métrica vllm:gpu_cache_usage_perc (para la versión de vllm anterior a la v0.10.2) en Monitoring para las implementaciones del servidor de modelos en ambos clústeres.
    • Métricas del balanceador de cargas: Examina las métricas del balanceador de cargas asociado con el cross-region-gateway en Monitoring.

A medida que aumentas la carga, el uso en us-east4 aumenta. Cuando el HPA en el clúster gke-east se expande y el uso promedio se acerca al valor maxUtilization (80%) que se define en GCPBackendPolicy, el balanceador de cargas comienza a enrutar solicitudes al clúster gke-west en europe-west3.

¿Qué sigue?