Configurar o balanceamento de carga baseado em utilização para serviços do GKE

Autopilot Standard

---

Prévia

Este recurso está sujeito aos Termos das Soluções Pré-GA na seção Termos Gerais de Serviço dos Termos Específicos de Serviço. Os recursos pré-GA estão disponíveis no estado em que se encontram e podem ter suporte limitado. Você encontra mais detalhes nas descrições das fases de lançamento.

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 administradores do GKE responsáveis por configurar e gerenciar a distribuição de tráfego para os 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 GKE Gateway disponível sem custo adicional. Os preços do Cloud Load Balancing e do GKE ainda são válidos.

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

Antes de começar

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

• Ativar a API Google Kubernetes Engine.
Ativar a API Google Kubernetes Engine
• Se você quiser usar a CLI do Google Cloud para essa tarefa, instale e, em seguida, inicialize a CLI gcloud. Se você instalou a gcloud CLI anteriormente, instale a versão mais recente executando gcloud components update.
  Observação:para instalações atuais da CLI gcloud, defina a propriedade compute/region. Se você usa principalmente clusters zonais, defina compute/zone. Ao definir um local padrão, você evita erros na CLI gcloud como este: 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.
• Confira as limitações.

Requisitos do GKE Gateway Controller

O balanceamento de carga baseado em utilização para serviços do GKE requer 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 RÁPIDO.
• 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 Google Cloud projeto.
• 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 Google Cloud balanceadores de carga de aplicativo, exceto os balanceadores de carga de aplicativo clássicos.

Limitações

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

• A única métrica de utilização de recursos compatível é a CPU.
• 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.
• O balanceamento de carga baseado em utilização não funciona bem se o tráfego for muito instável. O rebalanceamento de tráfego leva até 30 segundos quando os pods atingem a utilização máxima. Espera-se que o indicador de utilização aumente com o tráfego de entrada, mas esse atraso significa que o balanceamento de carga baseado na utilização precisa de tempo para se ajustar. Para uma performance ideal, o balanceamento de carga com base na utilização funciona melhor em ambientes com fluxos de tráfego suaves e previsíveis.
• Clusters de pilha dupla (com um endereço IPv4 e um IPv6) não são compatíveis.
• O balanceamento de carga baseado em utilização pode levar até 30 segundos para atualizar e ajustar a distribuição de tráfego após mudanças na 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 fica desativado para os serviços do GKE. É preciso 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 desempenho do HPA

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 cluster padrão com o perfil de 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 com a região ou zona do Compute Engine do cluster.
• PROJECT_ID pelo código do projeto;
• CLUSTER_VERSION com a 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, 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 novo cluster.
• LOCATION com a região ou zona do Compute Engine do cluster.
• PROJECT_ID pelo código 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 o tráfego com base na utilização do back-end. Você precisa usar a API Kubernetes Gateway pelo 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:

1. Implante 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 na utilização funcione corretamente, é necessário definir o recurso requests, principalmente para CPU, nas especificações do 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
   

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

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

Crie um GCPBackendPolicy para balanceamento de carga baseado 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 baseado em utilização para 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.

1. 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.
   • balancingMode: CUSTOM_METRICS: ativa o balanceamento de carga personalizado com base em métricas.
   • name: gke.cpu: especifica o uso 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á 80%. O tráfego é rebalanceado quando um back-end excede 80% de uso da CPU.

2. 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 de CPU em tempo real, você otimiza automaticamente a performance. 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 o 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 aos 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 nas 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 afetar 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 que não são de métrica 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 seu balancingMode para CUSTOM_METRICS.

• Como 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 poderá ficar visível apenas 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 de CPU maior ou menor antes de exigir uma redistribuição de tráfego. É possível personalizar esse limite usando o campo maxUtilizationPercent no recurso GCPBackendPolicy.

1. Para configurar um serviço do GKE para que ele permita que os back-ends utilizem até 70% da CPU antes que o rebalanceamento seja acionado, salve o seguinte manifesto de exemplo 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 maior.
   • Para serviços de vários clusters, o spec.targetRef.kind precisa ser ServiceImport e o group precisa ser net.gke.io.

2. Aplique o manifesto de exemplo ao cluster:

   kubectl apply -f my-backend-policy.yaml
   

Ao ativar um limite personalizado de uso da CPU, é 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 simulação monitora a utilização de recursos dos pods sem mudar 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.

1. Para ativar o modo de teste para seu serviço do GKE, salve o manifesto de amostra a seguir 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
   

2. Aplique o manifesto de exemplo 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_metrics.

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

Verificar a política

Para confirmar se 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á assim:

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 Gateway do Kubernetes 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, será necessário ativar o balanceamento de carga baseado em utilização no nível do BackendService.

1. Para um BackendService atual, ative o balanceamento de carga baseado em 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 com o nome do seu BackendService.
   • CUSTOM_METRICS com CUSTOM_METRICS.

2. Para atualizar as configurações de balanceamento de carga com base na utilização de uma entrada de back-end em um 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 com o nome do seu BackendService.
   • CUSTOM_METRICS com CUSTOM_METRICS.

Observação: se você usa métricas personalizadas, mantenha o número de dimensões configuradas abaixo do limite do serviço. Se você exceder o limite, não será possível adicionar mais dimensões.

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

Para desativar o balanceamento de carga com base na utilização nos seus serviços do GKE, siga estas etapas:

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

A seguir

• Visão geral dos grupos de endpoints de rede zonais