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

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 a performance e a disponibilidade do aplicativo, distribuindo o tráfego de maneira inteligente com base no uso de recursos em tempo real dos 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 o balanceamento de carga baseado em utilização 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 GKE ainda são aplicáveis.

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 aplicáveis.

Antes de começar

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

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

Requisitos do GKE Gateway Controller

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

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

  • Serviços do GKE de cluster único e múltiplo que servem como back-ends para um Google Cloud-balanceador de carga gerenciado.
  • Todas as edições do GKE (Standard, Autopilot e Enterprise).
  • Todos os Google Cloud balanceadores de carga de aplicativo, 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 com suporte são as seguintes:
  • Balanceadores de carga de rede de passagem ou 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 for muito instável. 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 uma performance 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 baseado em 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 uma GCPBackendPolicy. Esse atraso é um comportamento conhecido em todo o sistema. Como resultado, 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 os 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% de utilização por endpoint.

O objetivo ao configurar o balanceamento de carga baseado em utilização é otimizar a distribuição de tráfego para que os pods de back-end possam gerenciar a carga de trabalho com eficiência, o que melhora a performance do aplicativo e a utilização de recursos.

Ativar o balanceamento de carga baseado em utilização e o perfil de HPA de performance

Antes de configurar o balanceamento de carga baseado em 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 a 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 meio de GCPBackendPolicy.
  • O perfil de HPA de performance, 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 performance

Piloto automático

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

Padrão

Para criar um novo cluster padrão com o perfil de HPA de performance e a API Gateway ativados, 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 performance 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:

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

Configurar o balanceamento de carga baseado em 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. É necessário usar a API Kubernetes Gateway por meio de GCPBackendPolicy para a configuração.

Pré-requisitos

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

  1. Implantar um aplicativo: implante um aplicativo do Kubernetes usando um recurso de implantação. Para mais informações, consulte Implantar um aplicativo em um cluster do GKE.

    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. Expor 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. Usar 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 uma GCPBackendPolicy para balanceamento de carga baseado em CPU

Essa configuração permite que o GKE distribua o tráfego dinamicamente 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 a performance do aplicativo, evita que pods individuais fiquem sobrecarregados e melhora a confiabilidade e a experiência do usuário do aplicativo.

  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: direciona um serviço padrão do Kubernetes no mesmo cluster.
    • spec.targetRef.kind: ServiceImport: direciona um serviço de outro cluster em uma configuração de vários clusters.
    • balancingMode: CUSTOM_METRICS: ativa o balanceamento de carga baseado 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 será rebalanceado quando um back-end exceder 80% de uso da CPU.

  2. Aplique o manifesto de amostra 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 a performance. Essa ação ajuda a evitar a sobrecarga em pods individuais.

Considerações importantes para dryRun e balancingMode

Ao configurar 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 não de teste. 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ê 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 personalizados

    • Se o balanceamento de carga for baseado em critérios diferentes de métricas personalizadas, como RATE para solicitações por segundo, é possível definir 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 o balancingMode para CUSTOM_METRICS.
  • Monitorar métricas personalizadas

    • Depois de configurar a 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 de utilização da CPU personalizado

Por padrão, o GKE distribui o tráfego 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 a redistribuição do tráfego. É possível personalizar esse limite usando o campo maxUtilizationPercent no recurso GCPBackendPolicy.

  1. Para configurar um serviço do GKE de modo que ele permita que os back-ends utilizem 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 mais baixo.
    • Para cargas de trabalho projetadas para serem executadas perto da capacidade total, use um limite mais alto.
    • 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 amostra ao cluster:

    kubectl apply -f my-backend-policy.yaml
    

Ao ativar um limite de utilização da CPU personalizado, é possível controlar a distribuição de tráfego com base na utilização 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 ignora essas métricas e usa o comportamento de balanceamento de carga padrão.

  1. Para ativar o modo de teste para o 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
    
  2. Aplique o manifesto de amostra ao cluster:

    kubectl apply -f my-backend-policy.yaml
    

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

  • O Cloud Load Balancing ignora as métricas de utilização da CPU e usa o comportamento de balanceamento de carga padrão.

  • 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 da GCPBackendPolicy e reaplique a configuração. Se ocorrerem problemas depois de desativar o teste, reative-o adicionando dryRun: true de volta à política.

Verificar a política

Para confirmar se a GCPBackendPolicy foi aplicada 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 baseado em utilização usando as APIs do Compute Engine

Recomendamos o uso da API Kubernetes Gateway para configurar o balanceamento de carga baseado em utilização para os serviços do GKE.

No entanto, talvez você prefira usar as APIs do Compute Engine ou o Terraform para gerenciar os 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 seguinte comando:

    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:

    • MY_BACKEND_SERVICE pelo nome do seu BackendService.
    • CUSTOM_METRICS por CUSTOM_METRICS.
  2. Para atualizar as configurações de balanceamento de carga baseado em utilização de uma entrada de back-end atual 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:

    • MY_BACKEND_SERVICE pelo nome do seu BackendService.
    • CUSTOM_METRICS por CUSTOM_METRICS.

Desativar o balanceamento de carga baseado em 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:

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

A seguir