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 balanceamento de carga baseado em utilização para serviços do GKE

Autopilot Standard

Nesta página, descrevemos como configurar o balanceamento de carga baseado em utilização para serviços do GKE. Esta página é destinada a equipes de infraestrutura e aplicativos e a administradores do GKE responsáveis por configurar e gerenciar a distribuição de tráfego dos Serviços do GKE.

É possível usar balanceadores de carga baseados em utilização para otimizar o desempenho e a disponibilidade do aplicativo distribuindo o tráfego de maneira inteligente com base no uso de recursos em tempo real dos seus pods do GKE.

Antes de ler esta página, familiarize-se com o balanceamento de carga baseado em utilização para serviços do GKE e como ele funciona.

Preços

O balanceamento de carga baseado em utilização é um recurso do gateway do GKE que está disponível sem custo financeiro adicional. Os preços do Cloud Load Balancing e do GKE ainda se aplicam.

Cotas

O balanceamento de carga baseado em utilização não introduz novas cotas, embora todas as cotas do Cloud Load Balancing e de outros serviços dependentes ainda sejam válidas.

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

Confira os requisitos do controlador do gateway.
Revise as limitações.

Requisitos do GKE Gateway Controller

O balanceamento de carga baseado em utilização para serviços do GKE exige o seguinte:

Google Cloud CLI versão 516.0.0 ou mais recente.
GKE versão 1.33.1-gke.1918000 ou posterior no canal RAPID.
A API Gateway precisa estar ativada no cluster.
O perfil de HPA de desempenho precisa estar ativado no cluster.
A API Autoscaling precisa estar ativada no seu projeto do Google Cloud .
As contas de serviço do nó precisam ter permissão para gravar na API Autoscaling.

O balanceamento de carga baseado na utilização para serviços do GKE oferece suporte ao seguinte:

Serviços do GKE de cluster único e multicluster que servem como back-ends para um balanceador de carga gerenciado pelo Google Cloud.
Todas as edições do GKE (Standard, Autopilot e Enterprise).
Todos os balanceadores de carga de aplicativo Google Cloud , exceto os clássicos.

Limitações

O balanceamento de carga baseado em utilização para serviços do GKE tem as seguintes limitações.

As métricas de utilização de recursos compatíveis são as seguintes:
- Métricas de utilização de recursos da CPU.
- Métricas personalizadas emitidas pelo aplicativo do GKE. Para mais detalhes, consulte Expor métricas personalizadas para balanceadores de carga.
Os balanceadores de carga de rede de passagem ou de proxy não são compatíveis.
Somente a API Gateway é compatível. As APIs Service e Ingress não são compatíveis.
O balanceamento de carga baseado em utilização não funciona bem se o tráfego tiver muitos picos. O rebalanceamento de tráfego leva até 30 segundos quando os pods atingem a utilização máxima. O sinal de utilização deve aumentar com o tráfego de entrada, mas esse atraso significa que o balanceamento de carga baseado em utilização precisa de tempo para se ajustar. Para um desempenho ideal, o balanceamento de carga baseado em utilização funciona melhor em ambientes com fluxos de tráfego suaves e previsíveis.
O balanceamento de carga com base na utilização pode levar até 30 segundos para atualizar e ajustar a distribuição de tráfego após mudanças de configuração, como modificar ou remover o campo dryRun em um GCPBackendPolicy. Esse atraso é um comportamento conhecido em todo o sistema. Por isso, esse recurso é mais adequado para aplicativos com padrões de tráfego relativamente estáveis que podem tolerar essa latência de atualização.

Por padrão, o balanceamento de carga baseado em utilização está desativado para seus serviços do GKE. É necessário ativá-lo explicitamente. Se você não definir um limite máximo de utilização, o sistema vai usar 80% por endpoint.

O objetivo ao configurar o balanceamento de carga baseado na utilização é otimizar a distribuição de tráfego para que os pods de back-end possam gerenciar a carga de trabalho de maneira eficiente, o que melhora o desempenho do aplicativo e a utilização de recursos.

Ativar o balanceamento de carga com base na utilização e o perfil de HPA de desempenho

Antes de configurar o balanceamento de carga com base na utilização, verifique se o cluster do GKE oferece suporte aos recursos necessários. O balanceamento de carga baseado em utilização usa métricas personalizadas, como CPU, para tomar decisões de roteamento mais inteligentes. Essas decisões dependem do seguinte:

API Gateway, que permite políticas no nível do serviço por GCPBackendPolicy.
O perfil de HPA de desempenho, que permite que as cargas de trabalho sejam escalonadas com mais rapidez e agressividade usando sinais de CPU.

Ativar a API Gateway e o perfil de HPA de desempenho

Piloto automático

A API Gateway e o perfil de HPA de desempenho estão disponíveis por padrão em um cluster do Autopilot.

Padrão

Para criar um novo cluster padrão com o perfil HPA de desempenho e a API Gateway ativada, execute o seguinte comando:

gcloud container clusters create CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID \
    --cluster-version=CLUSTER_VERSION \
    --gateway-api=standard \
    --hpa-profile=performance \
    --release-channel=rapid

Substitua:

CLUSTER_NAME pelo nome do novo cluster.
LOCATION pela região ou zona do Compute Engine do cluster.
PROJECT_ID com o ID do projeto.
CLUSTER_VERSION pela versão do GKE, que precisa ser 1.33.1-gke.1918000 ou mais recente.

Para ativar o perfil de HPA de desempenho e a API Gateway em um cluster GKE Standard existente, use o seguinte:

gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID \
    --gateway-api=standard \
    --hpa-profile=performance \
    --release-channel=rapid

Substitua:

CLUSTER_NAME pelo nome do cluster.
LOCATION com a região ou zona do Compute Engine do cluster.
PROJECT_ID com o ID do projeto.

Para mais informações sobre o perfil de HPA de desempenho, consulte Configurar o perfil de HPA de desempenho.

Configurar o balanceamento de carga com base na utilização

Depois que o cluster estiver pronto, defina uma política que direcione como o tráfego é roteado com base na utilização do back-end. Use a API Gateway do Kubernetes por meio de GCPBackendPolicy para a configuração.

Pré-requisitos

Antes de configurar o balanceamento de carga com base na utilização usando a API Gateway, verifique se o cluster do GKE atende aos seguintes requisitos:

Implantar um aplicativo: use um recurso de implantação para implantar um aplicativo do Kubernetes. Para mais informações, consulte Implantar um aplicativo em um cluster do GKE.

Observação: para que o balanceamento de carga baseado em utilização funcione corretamente, é preciso definir o recurso requests, principalmente para CPU, nas especificações de contêiner da implantação. Isso permite que o sistema determine com precisão a utilização de recursos de linha de base e reequilibre o tráfego de maneira eficaz. Sem requests definido, o mecanismo de balanceamento de carga pode não se comportar como esperado.

Por exemplo, um manifesto de implantação típico pode incluir uma seção de recursos como esta:
```
apiVersion: apps/v1
kind: Deployment
metadata:
  name: store-v1
spec:
  # ... other deployment configurations ...
  template:
    # ... other template configurations ...
    spec:
      containers:
        - name: your-container-name
          image: your-image
          ports:
            - containerPort: 8080
          resources:
            limits:
              cpu: 100m
              memory: 45Mi
            requests:
              cpu: 100m
              memory: 45Mi
```
Exponha o aplicativo usando um serviço: é necessário expor o aplicativo usando um serviço do Kubernetes. Para mais informações sobre como os serviços funcionam e como configurá-los, consulte Entender os serviços do Kubernetes.
Use um balanceador de carga de aplicativo baseado na API Gateway: exponha o serviço usando um balanceador de carga de aplicativo gerenciado pelo GKE configurado pela API Gateway. Para mais informações, consulte Como implantar gateways.

Criar um `GCPBackendPolicy` para balanceamento de carga com base em CPU

Essa configuração permite que o GKE distribua o tráfego de forma dinâmica com base na utilização da CPU em tempo real de cada pod de back-end.

Para ativar o balanceamento de carga com base na utilização para os Serviços do GKE, use o recurso personalizado GCPBackendPolicy da API Kubernetes Gateway.

O recurso personalizado GCPBackendPolicy permite definir de forma declarativa o comportamento de balanceamento de carga no cluster do Kubernetes. Ao especificar métricas de utilização da CPU, você controla como o tráfego é distribuído entre os back-ends com base no uso atual de recursos. Essa abordagem ajuda a manter o desempenho do aplicativo, evita a sobrecarga de pods individuais e melhora a confiabilidade e a experiência do usuário.

Salve o seguinte manifesto de amostra como my-backend-policy.yaml:
```
kind: GCPBackendPolicy
apiVersion: networking.gke.io/v1
metadata:
  name: my-backend-policy
  namespace: team-awesome
spec:
  targetRef:
    group: ""
    kind: Service
    name: super-service
  default:
    balancingMode: CUSTOM_METRICS
    customMetrics:
    - name: gke.cpu
      dryRun: false
```
Observe o seguinte:
- spec.targetRef.kind: Service: tem como destino um serviço padrão do Kubernetes no mesmo cluster.
- spec.targetRef.kind: ServiceImport: tem como destino um serviço de outro cluster em uma configuração de vários clusters. Para serviços de vários clusters, o valor do campo group precisa ser definido como net.gke.io.
- balancingMode: CUSTOM_METRICS: ativa o balanceamento de carga com base em métrica personalizada.
- name: gke.cpu: especifica a utilização da CPU como a métrica para distribuição de tráfego.
Se o campo maxUtilizationPercent não for especificado, o limite de utilização padrão será de 80%. O tráfego é rebalanceado quando um back-end excede 80% de uso da CPU.

Aplique o manifesto de exemplo ao cluster:

kubectl apply -f my-backend-policy.yaml

Ao basear a distribuição de tráfego na utilização da CPU em tempo real, você otimiza automaticamente o desempenho. Essa ação ajuda a evitar a sobrecarga em pods individuais.

Considerações importantes sobre `dryRun` e `balancingMode`

Ao configurar o GCPBackendPolicy com métricas personalizadas, considere a interação entre balancingMode e o campo dryRun na definição de customMetrics. Essa interação determina como o balanceador de carga usa suas métricas personalizadas. Para mais informações sobre métricas personalizadas e restrições, incluindo aquelas relacionadas a modos de balanceamento, consulte Métricas personalizadas do Cloud Load Balancing.

balancingMode: CUSTOM_METRICS
- Para distribuir o tráfego com base em uma métrica personalizada, pelo menos uma métrica personalizada na lista customMetrics precisa ter dryRun definido como false. Essa configuração informa ao balanceador de carga para usar ativamente essa métrica para decisões de rebalanceamento.
- É possível incluir outras métricas personalizadas com dryRun: true junto com métricas que não são de simulação. Isso permite testar ou monitorar novas métricas, como a utilização da GPU, sem que elas afetem o tráfego, enquanto outra métrica, como a utilização da CPU com dryRun: false, controla o balanceamento.
- Se balancingMode for CUSTOM_METRICS e todas as métricas personalizadas tiverem dryRun definido como true, você vai receber um erro. Por exemplo: gceSync: generic::invalid_argument: Update: Invalid value for field 'resource.backends[0]': '...'. CUSTOM_METRICS BalancingMode requires at least one non-dry-run custom metric. O balanceador de carga precisa de uma métrica ativa para tomar decisões.
balancingMode é RATE ou outros modos de métrica não personalizada
- Se o balanceamento de carga for baseado em critérios diferentes das métricas personalizadas, como RATE para solicitações por segundo, defina dryRun: true para todas as métricas personalizadas. Isso permite monitorar métricas personalizadas sem afetar o mecanismo de balanceamento principal. Isso é útil para testar novas métricas personalizadas antes de mudar de balancingMode para CUSTOM_METRICS.
Monitorar métricas personalizadas
- Depois de configurar o GCPBackendPolicy e começar a enviar tráfego para o aplicativo, leva algum tempo para que as métricas personalizadas, como gke.cpu, apareçam no Metrics Explorer.
- Para que as métricas personalizadas fiquem visíveis e ativas no Metrics Explorer, é necessário que haja tráfego real fluindo pelo back-end monitorado pela política. Se não houver tráfego, a métrica só vai aparecer em "Recursos inativos" no Metrics Explorer.

Definir um limite personalizado de uso da CPU

Por padrão, o GKE distribui o tráfego para longe de back-ends que excedem 80% de utilização da CPU. No entanto, algumas cargas de trabalho podem tolerar um uso maior ou menor da CPU antes de exigir uma redistribuição de tráfego. É possível personalizar esse limite usando o campo maxUtilizationPercent no recurso GCPBackendPolicy.

Para configurar um serviço do GKE de modo que ele permita que os back-ends usem até 70% da CPU antes que o rebalanceamento seja acionado, salve o seguinte manifesto de amostra como my-backend-policy.yaml:
```
kind: GCPBackendPolicy
apiVersion: networking.gke.io/v1
metadata:
  name: my-backend-policy
  namespace: team-awesome
spec:
  targetRef:
    group: ""
    kind: Service
    name: super-service
  default:
    balancingMode: CUSTOM_METRICS
    customMetrics:
    - name: gke.cpu
      maxUtilizationPercent: 70
```
Observe o seguinte:
- O campo maxUtilizationPercent aceita valores de 0 a 100. Um valor de 100 significa que um back-end pode usar toda a capacidade da CPU antes que o tráfego seja rebalanceado.
- Para cargas de trabalho sensíveis à latência que exigem descarregamento antecipado, use um limite menor.
- Para cargas de trabalho projetadas para serem executadas quase na capacidade total, use um limite mais alto.
- Para serviços de vários clusters, o spec.targetRef.kind precisa ser ServiceImport, e o valor do campo group precisa ser definido como net.gke.io.

Aplique o manifesto de amostra ao cluster:

kubectl apply -f my-backend-policy.yaml

Ao ativar um limite de uso da CPU personalizado, é possível controlar a distribuição do tráfego com base no uso da CPU do back-end.

(Opcional) Ativar o modo de teste

O modo de teste monitora a utilização de recursos dos pods sem alterar a distribuição de tráfego. Quando o modo de teste está ativado, as métricas são exportadas para o Cloud Monitoring, mas o Cloud Load Balancing as ignora e usa o comportamento padrão de balanceamento de carga.

Para ativar o modo de teste no serviço do GKE, salve o seguinte manifesto de amostra como my-backend-policy.yaml:

kind: GCPBackendPolicy
apiVersion: networking.gke.io/v1
metadata:
  name: my-backend-policy
spec:
  targetRef:
    group: ""
    kind: Service
    name: store-v1
  default:
    balancingMode: RATE
    maxRatePerEndpoint: 10
    customMetrics:
    - name: gke.cpu
      dryRun: true

Aplique o manifesto de amostra ao cluster:

kubectl apply -f my-backend-policy.yaml

Quando você ativa o modo de teste, acontece o seguinte:

O Cloud Load Balancing ignora as métricas de utilização da CPU e usa o comportamento padrão de balanceamento de carga.
As métricas continuam sendo exportadas para o Cloud Monitoring em network.googleapis.com/loadbalancer/backend/lb_custom_metric.

Depois de analisar as métricas, remova o campo dryRun do GCPBackendPolicy e reaplique a configuração. Se ocorrerem problemas depois de desativar a simulação, reative-a adicionando dryRun: true de volta à política.

Verificar a política

Para confirmar que o GCPBackendPolicy foi aplicado ao serviço do GKE e verificar se os controladores do GKE reconhecem a política, execute o seguinte comando:

kubectl describe gcpbackendpolicy POLICY_NAME -n NAMESPACE

O resultado será o seguinte:

Name:         <your policy name>
Namespace:    <your namespace>
Labels:       <none>
Annotations:  <none>
API Version:  networking.gke.io/v1
Kind:         GCPBackendPolicy
Metadata:
  Creation Timestamp:  ...
  Generation:          1
  Resource Version:    …
  UID:                 …
Spec:
  Default:
    Balancing Mode:  CUSTOM_METRICS
    Custom Metrics:
      Dry Run:  false
      Name:     gke.cpu
  Target Ref:
    Group:
    Kind:   Service
    Name:   super-service
Status:
  Conditions:
    Last Transition Time:  …
    Message:
    Reason:                Attached
    Status:                True
    Type:                  Attached
Events:
…

Configurar o balanceamento de carga com base na utilização usando as APIs do Compute Engine

Recomendamos usar a API Kubernetes Gateway para configurar o balanceamento de carga com base na utilização dos serviços do GKE.

No entanto, talvez você prefira usar as APIs do Compute Engine ou o Terraform para gerenciar seus balanceadores de carga diretamente. Se você escolher essa abordagem, ative o balanceamento de carga com base na utilização no nível do BackendService.

Para um BackendService atual, ative o balanceamento de carga com base na utilização e anexe um grupo de endpoints de rede (NEG), my-lb-neg, executando o comando a seguir:

gcloud compute backend-services add-backend MY_BACKEND_SERVICE \
  --network-endpoint-group my-lb-neg \
  --network-endpoint-group-zone=asia-southeast1-a \
  --global \
  --balancing-mode=CUSTOM_METRICS \
  --custom-metrics 'name="gke.cpu",maxUtilization=0.8'

Substitua o seguinte:

MY_BACKEND_SERVICE pelo nome do BackendService.
CUSTOM_METRICS com CUSTOM_METRICS.

Para atualizar as configurações de balanceamento de carga com base na utilização de uma entrada de back-end existente no BackendService em que um NEG já está anexado, execute o seguinte comando:
```
gcloud compute backend-services update-backend MY_BACKEND_SERVICE \
  --network-endpoint-group my-lb-neg \
  --network-endpoint-group-zone=asia-southeast1-a \
  --global \
  --balancing-mode=CUSTOM_METRICS \
  --custom-metrics 'name="gke.cpu",maxUtilization=0.8'
```
substitua o seguinte:
- MY_BACKEND_SERVICE pelo nome do BackendService.
- CUSTOM_METRICS com CUSTOM_METRICS.

Desativar o balanceamento de carga baseado na utilização para um serviço do GKE

Para desativar o balanceamento de carga baseado em utilização nos serviços do GKE, siga estas etapas:

Se você quiser manter a política para outras configurações, remova os campos balancingMode e customMetrics do GCPBackendPolicy.
Se você não precisar mais de GCPBackendPolicy, poderá excluir.
Se você usa APIs do Compute Engine, mude de volta as flags --balancing-mode e --custom-metrics do serviço de back-end.

A seguir

Para usar métricas personalizadas no balanceamento de carga, consulte Expor métricas personalizadas para balanceadores de carga.
Visão geral dos grupos de endpoints de rede zonais.