O Google usa tecnologia de IA na tradução de conteúdos para seu idioma de preferência. As traduções com IA podem ter erros.

Configurar o GKE Inference Gateway de vários clusters

Autopilot Standard

Este documento descreve como configurar o Inference Gateway de vários clusters do Google Kubernetes Engine (GKE) para balancear a carga de maneira inteligente das cargas de trabalho de inferência de IA/ML em vários clusters do GKE, que podem abranger diferentes regiões. Essa configuração usa a API Gateway, Entrada em vários clusters e recursos personalizados, como InferencePool e InferenceObjective, para melhorar a escalonabilidade, garantir alta disponibilidade e otimizar a utilização de recursos para implantações de serviço de modelos.

Para entender este documento, familiarize-se com o seguinte:

Orquestração de IA/ML no GKE.
Terminologia da IA generativa.
Conceitos de rede do GKE, incluindo:
Balanceamento de carga no Google Cloud, principalmente como os balanceadores de carga interagem com o GKE.

Este documento é destinado aos seguintes perfis:

Engenheiros de machine learning (ML), administradores e operadores de plataforma ou especialistas em dados e IA que querem usar os recursos de orquestração de contêineres do GKE para veicular cargas de trabalho de IA/ML.
Arquitetos de nuvem ou especialistas em redes que interagem com a rede do GKE.

Para saber mais sobre papéis comuns e tarefas de exemplo referenciados no conteúdo doGoogle Cloud , consulte Tarefas e funções de usuário comuns do GKE Enterprise.

Antes de começar

Antes de começar, verifique se você realizou as tarefas a seguir:

Ative a API Google Kubernetes Engine.

Ativar a API Google Kubernetes Engine

Se você quiser usar a Google Cloud CLI para essa tarefa, instale e, em seguida, inicialize a CLI gcloud. Se você instalou a CLI gcloud anteriormente, instale a versão mais recente executando o comando gcloud components update. Talvez as versões anteriores da CLI gcloud não sejam compatíveis com a execução dos comandos neste documento.
Observação:em instalações prévias da CLI gcloud, defina a propriedade compute/region. Se você usa principalmente clusters zonais, defina compute/zone. Ao definir um local padrão, é possível evitar erros na CLI gcloud como: One of [--zone, --region] must be supplied: Please specify location. Talvez seja necessário especificar o local em determinados comandos se o local do cluster for diferente do padrão definido.

Ative a API Compute Engine, a API Kubernetes Engine, o Model Armor e a API Network Services.

Acesse Ativar acesso a APIs e siga as instruções.
Ative a API Autoscaling.

Acesse a API de escalonamento automático e siga as instruções.
Ative a API GKE Hub.

Acesse a API do GKE Hub e siga as instruções.

Como alternativa, use a Google Cloud CLI:
```
gcloud services enable gkehub.googleapis.com --project=PROJECT_ID
```
Pré-requisitos do Hugging Face:
- Crie uma conta do Hugging Face caso ainda não tenha uma.
- Solicite e receba aprovação para acessar o modelo Qwen3-32B no Hugging Face.
- Assine o contrato de consentimento de licença na página do modelo no Hugging Face.
- Gere um token de acesso do Hugging Face com pelo menos permissões de Read.

Requisitos

Verifique se o projeto tem cota suficiente para GPUs H100. Para mais informações, consulte Planejar cota de GPU e Cotas de alocação.
Use o GKE versão 1.34.1-gke.1127000 ou mais recente.
Use a CLI gcloud versão 480.0.0 ou mais recente.
As contas de serviço do nó precisam ter permissões para gravar métricas na API Autoscaling.
Você precisa ter os seguintes papéis do IAM no projeto: roles/container.admin e roles/iam.serviceAccountAdmin.
Todos os clusters registrados na frota, incluindo o cluster de configuração, precisam estar na mesma rede VPC. Os gateways de vários clusters não são compatíveis com o balanceamento de carga entre clusters em diferentes redes VPC.

Limites de multiportas e NEGs

Ao implantar recursos do InferencePool de várias portas em uma configuração de vários clusters, considere o limite de NEG do serviço de back-end Google Cloud . Cada porta em cada zona cria um NEG dedicado. Por exemplo, um cluster regional com três zonas e um InferencePool configurado com oito portas vai usar 24 NEGs. Como um serviço de back-end é limitado a 50 NEGs, só é possível agregar esse InferencePool específico de um máximo de dois clusters antes de atingir o limite.

Configurar um gateway de inferência de vários clusters

Para configurar o GKE Inference Gateway multicluster, siga estas etapas:

Criar clusters e pools de nós

Para hospedar suas cargas de trabalho de inferência de IA/ML e ativar o balanceamento de carga entre regiões, crie dois clusters do GKE em regiões diferentes, cada um com um pool de nós de GPU H100.

Crie o primeiro 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
```
Substitua:
- CLUSTER_1_NAME: o nome do primeiro cluster, por exemplo, gke-west.
- LOCATION: a região do primeiro cluster, por exemplo, europe-west3.
- PROJECT_ID: o ID do projeto.
- GKE_VERSION: a versão do GKE a ser usada, por exemplo, 1.34.1-gke.1127000.
- MACHINE_TYPE: o tipo de máquina dos nós do cluster, por exemplo, c2-standard-16.
- DISK_TYPE: o tipo de disco para os nós do cluster, por exemplo, pd-standard.
Observação: a flag --async permite que o comando retorne imediatamente enquanto o GKE cria o cluster em segundo plano. O comando get-credentials subsequente aguarda o provisionamento completo do cluster.
Crie um pool de nós H100 para o primeiro 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
```
Substitua:
- NODE_POOL_NAME: o nome do pool de nós, por exemplo, h100.
- PROJECT_ID: o ID do projeto.
- CLUSTER_1_ZONE: a zona do primeiro cluster, por exemplo, europe-west3-c.
- CLUSTER_1_NAME: o nome do primeiro cluster, por exemplo, gke-west.
- NODE_POOL_MACHINE_TYPE: o tipo de máquina para o pool de nós, por exemplo, a3-highgpu-2g.
- NUM_NODES: o número de nós no pool de nós, por exemplo, 3.
Observação: usar a flag --spot cria um pool de nós de VM spot, que pode ser preemptivo. As VMs spot geralmente são adequadas para cargas de trabalho de inferência de IA/ML porque oferecem economia de custos significativa, e as tarefas de inferência podem ser projetadas para serem resilientes a interrupções.
Receba as credenciais:
```
gcloud container clusters get-credentials CLUSTER_1_NAME \
    --location CLUSTER_1_ZONE \
    --project=PROJECT_ID
```
Substitua:
- PROJECT_ID: o ID do projeto.
- CLUSTER_1_NAME: o nome do primeiro cluster, por exemplo, gke-west.
- CLUSTER_1_ZONE: a zona do primeiro cluster, por exemplo, europe-west3-c.
No primeiro cluster, crie um secret para o token do Hugging Face:
```
kubectl create secret generic hf-token \
    --from-literal=token=HF_TOKEN
```
Substitua HF_TOKEN pelo seu token de acesso do Hugging Face.
Crie o segundo cluster em uma região diferente do primeiro:
```
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.
```
Substitua:
- LOCATION: a região do segundo cluster. Essa região precisa ser diferente da do primeiro cluster. Por exemplo, us-east4.
- PROJECT_ID: o ID do projeto.
- GKE_VERSION: a versão do GKE a ser usada, por exemplo, 1.34.1-gke.1127000.
- MACHINE_TYPE: o tipo de máquina dos nós do cluster, por exemplo, c2-standard-16.
- DISK_TYPE: o tipo de disco para os nós do cluster, por exemplo, pd-standard.
Observação: para ativar o balanceamento de carga entre regiões, verifique se o segundo cluster está em uma região diferente do primeiro.

Crie um pool de nós H100 para o segundo 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

Substitua:

PROJECT_ID: o ID do projeto.
CLUSTER_2_ZONE: a zona do segundo cluster, por exemplo, us-east4-a.
CLUSTER_2_NAME: o nome do segundo cluster. Por exemplo, gke-east.
NODE_POOL_MACHINE_TYPE: o tipo de máquina para o pool de nós, por exemplo, a3-highgpu-2g.
NUM_NODES: o número de nós no pool de nós, por exemplo, 3.

Para o segundo cluster, receba as credenciais e crie um secret para o token do 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
```
Substitua:
- CLUSTER_2_NAME: o nome do segundo cluster. Por exemplo, gke-east.
- CLUSTER_2_ZONE: a zona do segundo cluster, por exemplo, us-east4-a.
- PROJECT_ID: o ID do projeto.
- HF_TOKEN: seu token de acesso do Hugging Face.

Registrar clusters em uma frota

Para ativar recursos de vários clusters, como o gateway de inferência do GKE de vários clusters, registre seus clusters em uma frota.

Defina a substituição do endpoint de API para evitar problemas de mTLS durante o registro.
```
gcloud config set api_endpoint_overrides/container https://container.googleapis.com/
```

Registre os dois clusters na frota do projeto:

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

Substitua:

CLUSTER_1_NAME: o nome do primeiro cluster, por exemplo, gke-west.
CLUSTER_1_ZONE: a zona do primeiro cluster, por exemplo, europe-west3-c.
PROJECT_ID: o ID do projeto.
CLUSTER_2_NAME: o nome do segundo cluster. Por exemplo, gke-east.
CLUSTER_2_ZONE: a zona do segundo cluster, por exemplo, us-east4-a.

Para permitir que um único gateway gerencie o tráfego em vários clusters, ative o recurso de Entrada de vários clusters e designe um cluster de configuração:
```
gcloud container fleet ingress enable \
    --config-membership=projects/PROJECT_ID/locations/global/memberships/CLUSTER_1_NAME
```
Substitua:
- PROJECT_ID: o ID do projeto.
- CLUSTER_1_NAME: o nome do primeiro cluster, por exemplo, gke-west.

Criar sub-redes somente proxy

Para um gateway interno, crie uma sub-rede somente proxy em cada região. Os proxies Envoy do gateway interno usam essas sub-redes dedicadas para processar o tráfego na rede VPC.

Aviso:o Google Cloud permite apenas uma sub-rede somente proxy por região em cada rede VPC. Se a região de destino já tiver uma sub-rede somente proxy com a configuração purpose=REGIONAL_MANAGED_PROXY, a criação da sub-rede GLOBAL_MANAGED_PROXY vai falhar. Primeiro, exclua a sub-rede somente proxy regional atual. A exclusão de uma sub-rede somente proxy regional afeta todos os balanceadores de carga regionais baseados no Envoy que a usam. Portanto, planeje a mudança de acordo.

Crie uma sub-rede na região do primeiro 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

Crie uma sub-rede na região do segundo 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

Substitua:

PROJECT_ID: o ID do projeto.
CLUSTER_1_REGION: a região do primeiro cluster, por exemplo, europe-west3.
CLUSTER_2_REGION: a região do segundo cluster, por exemplo, us-east4.

Instalar as CustomResourceDefinitions necessárias

O GKE Inference Gateway de vários clusters usa recursos personalizados, como InferencePool e InferenceObjective. O controlador da API GKE Gateway gerencia a CustomResourceDefinition InferencePool. No entanto, é necessário instalar manualmente a CustomResourceDefinition InferenceObjective, que está em versão Alfa, nos clusters.

Defina variáveis de contexto para seus clusters:
```
CLUSTER1_CONTEXT="gke_PROJECT_ID_CLUSTER_1_ZONE_CLUSTER_1_NAME"
CLUSTER2_CONTEXT="gke_PROJECT_ID_CLUSTER_2_ZONE_CLUSTER_2_NAME"
```
Substitua:
- PROJECT_ID: o ID do projeto.
- CLUSTER_1_ZONE: a zona do primeiro cluster, por exemplo, europe-west3-c.
- CLUSTER_1_NAME: o nome do primeiro cluster, por exemplo, gke-west.
- CLUSTER_2_ZONE: a zona do segundo cluster, por exemplo, us-east4-a.
- CLUSTER_2_NAME: o nome do segundo cluster, por exemplo, gke-east.

Instale a CustomResourceDefinition InferenceObjective nos dois clusters:

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

Implantar recursos nos clusters de destino

Para disponibilizar suas cargas de trabalho de inferência de IA/ML em cada cluster, implante os recursos necessários, como os servidores de modelo e os recursos personalizados InferenceObjective.

Observação:os exemplos neste documento usam o vLLM, mas o gateway de inferência de vários clusters é independente da plataforma do servidor de modelos e também funciona com outros servidores de modelos, como o SGLang. Se você usa um servidor de modelo diferente, ajuste as seguintes configurações:

Porta de disponibilização. Defina a porta de destino InferencePool, a porta HealthCheckPolicy e a porta do endpoint AutoscalingMetric como a porta de veiculação do servidor de modelo. Por exemplo, o SGLang atende na porta 30000 por padrão em vez da porta 8000.
Nomes de métricas. Os nomes das métricas são específicos para cada servidor de modelo. Por exemplo, o SGLang informa a utilização do cache KV como a métrica sglang:token_usage em vez de vllm:kv_cache_usage_perc. Mapeie a métrica do servidor de modelos para o nome de exportação kv-cache no recurso AutoscalingMetric. A extração de métricas personalizadas para servidores de modelo que não sejam vLLM exige uma imagem compatível do Endpoint Picker (EPP). Use a versão mais recente do gráfico compatível.
Disponibilização do modelo em vários nós. Se uma réplica de modelo abranger vários nós (por exemplo, ao usar a API LeaderWorkerSet para disponibilizar um modelo grande), somente o pod líder (classificação 0) vai disponibilizar a API. Configure o seletor InferencePool modelServers.matchLabels para corresponder apenas aos pods líderes, por exemplo, adicionando o rótulo apps.kubernetes.io/pod-index: "0". Se o seletor também corresponder a pods de worker, o gateway vai encaminhar solicitações para pods que não podem atendê-las, e essas solicitações vão falhar com um código de status HTTP 404 Not Found.

Implante os servidores de modelo nos dois clusters:

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

Implante os recursos InferenceObjective nos dois clusters. Salve o seguinte manifesto de exemplo em um arquivo chamado 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"

Aplique o manifesto aos dois clusters:
```
kubectl apply -f inference-objective.yaml --context=$CLUSTER1_CONTEXT
kubectl apply -f inference-objective.yaml --context=$CLUSTER2_CONTEXT
```
Substitua:
- $CLUSTER1_CONTEXT: o contexto do primeiro cluster, por exemplo, gke_my-project_europe-west3-c_gke-west.
- $CLUSTER2_CONTEXT: o contexto do segundo cluster, por exemplo, gke_my-project_us-east4-a_gke-east.

Implante os recursos do InferencePool nos dois clusters usando o 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

Os comandos anteriores usam a versão v1.5.0 do gráfico do Helm porque é uma versão recomendada para essa configuração. O gráfico do Helm também instala um recurso personalizado GCPBackendPolicy e um recurso personalizado HealthCheckPolicy destinados ao uso em um único cluster.

Na versão v1.1.0 do gráfico Helm InferencePool, a flag --set inferencePool.targetPortNumber pode ser ignorada, e a porta de destino assume o valor padrão 8000. Se o servidor de modelo detectar em uma porta diferente (por exemplo, o SGLang usa a porta 30000 por padrão), verifique a porta após a instalação:

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

Se a porta estiver incorreta, adicione um patch ao recurso personalizado InferencePool antes de exportá-lo:

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

Marque os recursos InferencePool como exportados nos dois clusters. Essa anotação disponibiliza o InferencePool para importação pelo cluster de configuração, que é uma etapa obrigatória para o roteamento de vários clusters.

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

Implantar recursos no cluster de configuração

Para definir como o tráfego é roteado e balanceado por carga nos recursos do InferencePool em todos os clusters registrados, implante os recursos Gateway, HTTPRoute e HealthCheckPolicy. Você implanta esses recursos apenas no cluster de configuração designado, que é gke-west neste documento.

Crie um arquivo chamado mcig.yaml com o conteúdo a seguir:

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

Aplique o manifesto:

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

Ativar relatórios de métricas personalizadas

Para ativar os relatórios de métricas personalizadas e ajudar a melhorar o balanceamento de carga entre regiões, exporte as métricas de uso do cache KV de todos os clusters. O balanceador de carga usa esses dados de uso do cache KV exportados como um indicador de carga personalizado. Usar esse indicador de carga personalizado permite decisões de balanceamento de carga mais inteligentes com base na carga de trabalho real de cada cluster.

Crie um arquivo chamado metrics.yaml com o conteúdo a seguir:

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

Aplique a configuração de métricas aos dois clusters:

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

Configurar a política de balanceamento de carga

Para otimizar a distribuição de solicitações de inferência de IA/ML nos clusters do GKE, configure uma política de balanceamento de carga. Um modo de balanceamento adequado ajuda a garantir o uso eficiente dos recursos, evita a sobrecarga de clusters individuais e melhora o desempenho e a capacidade de resposta dos serviços de inferência.

Configurar tempos limite

Se as solicitações tiverem durações longas, configure um tempo limite maior para o balanceador de carga. No GCPBackendPolicy, defina o campo timeoutSec como pelo menos o dobro da latência de solicitação P99 estimada. Para cargas de trabalho de inferência de contexto longo com alta simultaneidade, talvez seja necessário um tempo limite de até 3600 segundos. Por exemplo, o manifesto a seguir define o tempo limite do balanceador de carga como 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 mais informações, consulte Limitações do gateway de vários clusters.

Como os modos de balanceamento de carga Métricas personalizadas e Solicitações em andamento são mutuamente exclusivos, configure apenas um desses modos no seu GCPBackendPolicy.

Escolha um modo de balanceamento de carga para sua implantação.

Métricas personalizadas

Para um balanceamento de carga ideal, comece com uma utilização de destino de 60%. Para atingir essa meta, defina maxUtilizationPercent: 60 na configuração customMetrics do GCPBackendPolicy.

Crie um arquivo chamado backend-policy.yaml com o seguinte conteúdo para ativar o balanceamento de carga com base na métrica personalizada kv-cache:

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:
    balancingMode: CUSTOM_METRICS
    trafficDuration: LONG
    customMetrics:
      - name: gke.named_metrics.kv-cache
        dryRun: false
        maxUtilizationPercent: 60

Aplique a nova política:

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

Solicitações em trânsito

Para usar o modo de balanceamento em andamento, estime o número de solicitações em andamento que cada back-end pode processar e configure explicitamente um valor de capacidade.

Crie um arquivo chamado backend-policy.yaml com o seguinte conteúdo para ativar o balanceamento de carga com base no número de solicitações em andamento:

kind: GCPBackendPolicy
apiVersion: networking.gke.io/v1
metadata:
  name: my-backend-policy
spec:
  targetRef:
    group: "networking.gke.io"
    kind: GCPInferencePoolImport
    name: vllm-qwen3-32b
  default:
    balancingMode: IN_FLIGHT
    trafficDuration: LONG
    maxInFlightRequestsPerEndpoint: 1000
    dryRun: false

Aplique a nova política:

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

Verificar a implantação

Para verificar o balanceador de carga interno, envie solicitações da sua rede VPC, já que os balanceadores de carga internos usam endereços IP privados. Execute um pod temporário em um dos clusters para enviar solicitações da rede VPC e verificar o balanceador de carga interno:

No novo shell, receba o endereço IP do gateway:

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

Envie uma solicitação de teste de um pod temporário dentro do 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": "Qwen/Qwen3-32B",
  "prompt": "What is the best pizza in the world?",
  "max_tokens": 100,
  "temperature": 0
  }'

A seguir

Saiba mais sobre a API GKE Gateway.
Saiba mais sobre o GKE Inference Gateway de vários clusters.
Saiba mais sobre o Ingress de vários clusters.

Configurar o GKE Inference Gateway de vários clusters Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Antes de começar

Requisitos

Limites de multiportas e NEGs

Configurar um gateway de inferência de vários clusters

Criar clusters e pools de nós

Registrar clusters em uma frota

Criar sub-redes somente proxy

Instalar as CustomResourceDefinitions necessárias

Implantar recursos nos clusters de destino

Implantar recursos no cluster de configuração

Ativar relatórios de métricas personalizadas

Configurar a política de balanceamento de carga

Configurar tempos limite

Métricas personalizadas

Solicitações em trânsito

Verificar a implantação

A seguir

Configurar o GKE Inference Gateway de vários clusters