Configure o equilíbrio de carga baseado na utilização para serviços do GKE

Autopilot Padrão

Pré-visualização

Esta funcionalidade está sujeita aos "Termos das Ofertas de Pré-DG" na secção Termos Gerais de Serviço dos Termos Específicos do Serviço. As funcionalidades de pré-DG estão disponíveis "tal como estão" e podem ter apoio técnico limitado. Para mais informações, consulte as descrições das fases de lançamento.

Esta página descreve como configurar o equilíbrio de carga baseado na utilização para os serviços do GKE. Esta página destina-se às equipas de infraestrutura e aplicações, e aos administradores do GKE responsáveis por configurar e gerir a distribuição de tráfego para os respetivos serviços do GKE.

Pode usar equilibradores de carga baseados na utilização para otimizar o desempenho e a disponibilidade das aplicações distribuindo o tráfego de forma inteligente com base na utilização de recursos em tempo real dos seus pods do GKE.

Antes de ler esta página, certifique-se de que conhece o equilíbrio de carga baseado na utilização para os serviços do GKE e como funciona o equilíbrio de carga baseado na utilização.

Preços

O equilíbrio de carga baseado na utilização é uma capacidade do GKE Gateway que está disponível sem custos adicionais. Os preços do Cloud Load Balancing e do GKE continuam a aplicar-se.

Quotas

O balanceamento de carga baseado na utilização não introduz novas quotas, embora todas as quotas do Cloud Load Balancing e de outros serviços dependentes continuem a aplicar-se.

Antes de começar

Antes de começar, certifique-se de que realizou as seguintes tarefas:

• Ative a API Google Kubernetes Engine.
Ative a API Google Kubernetes Engine
• Se quiser usar a CLI gcloud para esta tarefa, instale-a e, em seguida, inicialize-a. Se instalou anteriormente a CLI gcloud, execute gcloud components update para obter a versão mais recente.
  Nota: para instalações existentes da CLI gcloud, certifique-se de que define a compute/region propriedade. Se usar principalmente clusters zonais, defina o compute/zone. Ao definir uma localização predefinida, pode evitar erros na CLI gcloud, como os seguintes: One of [--zone, --region] must be supplied: Please specify location. Pode ter de especificar a localização em determinados comandos se a localização do seu cluster for diferente da predefinição que definiu.

• Reveja os requisitos do controlador de gateway.
• Reveja as limitações.

Requisitos do GKE Gateway Controller

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

• Versão 516.0.0 ou posterior da CLI Google Cloud.
• Versão 1.33.1-gke.1918000 ou posterior do GKE no canal RAPID.
• A API Gateway tem de estar ativada no seu cluster.
• O perfil de HPA de desempenho tem de estar ativado no seu cluster.
• A API Autoscaling tem de estar ativada no seu Google Cloud projeto.
• As contas de serviço do nó têm de poder escrever na API Autoscaling.

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

• Serviços do GKE de cluster único e vários clusters que funcionam como back-ends para um balanceador de carga gerido pela Google Cloud.
• Todas as edições do GKE (Standard, Autopilot e Enterprise).
• Todos os Google Cloud balanceadores de carga de aplicações, exceto os balanceadores de carga de aplicações clássicos.

Limitações

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

• A única métrica de utilização de recursos suportada é a CPU.
• Os equilibradores de carga de rede de passagem ou proxy não são suportados.
• Apenas a API Gateway é suportada. As APIs Service e Ingress não são suportadas.
• O equilíbrio de carga baseado na utilização não funciona bem se o seu tráfego for muito instável. O reequilíbrio do tráfego demora até 30 segundos quando os pods atingem a respetiva utilização máxima. Espera-se que o sinal de utilização aumente com o tráfego recebido, mas este atraso significa que o equilíbrio de carga baseado na utilização precisa de tempo para se ajustar. Para um desempenho ideal, o equilíbrio de carga baseado na utilização funciona melhor em ambientes com fluxos de tráfego suaves e previsíveis.
• Os clusters de pilha dupla (clusters com um endereço IPv4 e um endereço IPv6) não são suportados.
• O equilíbrio de carga baseado na utilização pode demorar até 30 segundos a atualizar e ajustar a distribuição de tráfego após alterações de configuração, como modificar ou remover o campo dryRun num GCPBackendPolicy. Este atraso é um comportamento conhecido ao nível do sistema. Como tal, esta funcionalidade é mais adequada para aplicações com padrões de tráfego relativamente estáveis que podem tolerar esta latência de atualização.

Por predefinição, o equilíbrio de carga baseado na utilização está desativado para os seus serviços do GKE. Tem de a ativar explicitamente. Se não definir um limite de utilização máximo, o sistema usa por predefinição uma utilização de 80% por ponto final.

O objetivo da configuração do equilíbrio de carga baseado na utilização é otimizar a distribuição do tráfego para que os pods de back-end possam gerir eficientemente a respetiva carga de trabalho, o que melhora o desempenho da aplicação e a utilização de recursos.

Ative o balanceamento de carga baseado na utilização e o perfil de HPA de desempenho

Antes de configurar o equilíbrio de carga baseado na utilização, certifique-se de que o seu cluster do GKE suporta as funcionalidades necessárias. O equilíbrio de carga baseado na utilização usa métricas personalizadas, como a CPU, para tomar decisões de encaminhamento mais inteligentes. Estas decisões dependem do seguinte:

• API Gateway, que permite políticas ao nível do serviço através de GCPBackendPolicy.
• O perfil HPA de desempenho, que permite que as cargas de trabalho sejam dimensionadas de forma mais rápida e agressiva através de sinais da CPU.

Ative a API Gateway e o perfil de HPA de desempenho

Autopilot

A API Gateway e o perfil HPA de desempenho estão disponíveis por predefinição num 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 o seguinte:

• CLUSTER_NAME com o nome do novo cluster.
• LOCATION com a região ou zona do Compute Engine para o seu cluster.
• PROJECT_ID com o ID do seu projeto.
• CLUSTER_VERSION com a versão do GKE, que tem de ser 1.33.1-gke.1918000 ou posterior.

Para ativar o perfil de HPA de desempenho e a API Gateway num cluster padrão do GKE 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 o seguinte:

• CLUSTER_NAME com o nome do novo cluster.
• LOCATION com a região ou zona do Compute Engine para o seu cluster.
• PROJECT_ID com o ID do seu projeto.

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

Configure o balanceamento de carga baseado na utilização

Quando o cluster estiver pronto, defina uma política que direcione a forma como o tráfego é encaminhado com base na utilização do back-end. Tem de usar a API Kubernetes Gateway através de GCPBackendPolicy para a configuração.

Pré-requisitos

Antes de configurar o equilíbrio de carga baseado na utilização através da API Gateway, certifique-se de que o seu cluster do GKE cumpre os seguintes requisitos:

1. Implemente uma aplicação: certifique-se de que implementa uma aplicação Kubernetes usando um recurso de implementação. Para mais informações, consulte o artigo Implemente uma aplicação num cluster do GKE.

   Nota: para que o equilíbrio de carga baseado na utilização funcione corretamente, tem de definir o recurso requests, especialmente para a CPU, nas especificações do contentor da sua implementação. Isto permite ao sistema determinar com precisão a utilização de recursos de base e reequilibrar o tráfego de forma eficaz. Sem o elemento requests definido, o mecanismo de equilíbrio de carga pode não funcionar como esperado.

   Por exemplo, um manifesto de implementação típico pode incluir uma secçã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 a aplicação através de um serviço: tem de expor a aplicação através de um serviço do Kubernetes. Para mais informações sobre o funcionamento dos serviços e como os configurar, consulte o artigo Compreender os serviços do Kubernetes.

3. Use um Application Load Balancer baseado na API Gateway: exponha o serviço usando um Application Load Balancer gerido pelo GKE que esteja configurado através da API Gateway. Para mais informações, consulte o artigo Implementar gateways.

Crie um GCPBackendPolicy para o balanceamento de carga baseado na CPU

Esta 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 equilíbrio de carga baseado na utilização para os serviços do GKE, use o recurso personalizado GCPBackendPolicy da API Kubernetes Gateway.

O recurso personalizado GCPBackendPolicy permite-lhe definir declarativamente o comportamento de equilíbrio de carga no seu cluster do Kubernetes. Ao especificar as métricas de utilização da CPU, controla a forma como o tráfego é distribuído pelos back-ends com base na respetiva utilização atual de recursos. Esta abordagem ajuda a manter o desempenho da aplicação, a evitar a sobrecarga de Pods individuais e a melhorar a fiabilidade e a experiência do utilizador da aplicação.

1. Guarde 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
         dryRun: false
   

   Tenha em conta o seguinte:

   • spec.targetRef.kind: Service: segmenta um serviço Kubernetes padrão no mesmo cluster.
   • spec.targetRef.kind: ServiceImport: segmenta um serviço de outro cluster numa configuração de vários clusters.
   • balancingMode: CUSTOM_METRICS: ativa o balanceamento de carga baseado em métricas personalizadas.
   • name: gke.cpu: especifica a utilização da CPU como a métrica para a distribuição de tráfego.

   Se o campo maxUtilizationPercent não for especificado, o limite de utilização predefinido é de 80%. O tráfego é reequilibrado quando um back-end excede a utilização de 80% da CPU.

2. Aplique o manifesto de exemplo ao seu cluster:

   kubectl apply -f my-backend-policy.yaml
   

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

Considerações importantes para dryRun e balancingMode

Quando configura GCPBackendPolicy com métricas personalizadas, considere a interação entre balancingMode e o campo dryRun na definição de customMetrics. Esta interação determina como o equilibrador de carga usa as suas métricas personalizadas. Para mais informações sobre métricas personalizadas e as respetivas restrições, incluindo as relacionadas com modos de equilíbrio, consulte o artigo Métricas personalizadas do Cloud Load Balancing.

• balancingMode: CUSTOM_METRICS

  • Para distribuir o tráfego com base numa métrica personalizada, pelo menos uma métrica personalizada na lista customMetrics tem de ter definido como dryRun.false Esta definição indica ao equilibrador de carga que use ativamente essa métrica para tomar decisões de reequilíbrio.
  • Pode incluir outras métricas personalizadas com dryRun: true, juntamente com métricas que não sejam de teste. Isto permite-lhe testar ou monitorizar novas métricas, como a utilização da GPU, sem que estas afetem o tráfego, enquanto outra métrica, como a utilização da CPU com dryRun: false, controla o equilíbrio.
  • Se balancingMode for CUSTOM_METRICS e todas as métricas personalizadas tiverem dryRun definido como true, recebe 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 equilibrador de carga precisa de uma métrica ativa para tomar decisões.

• balancingMode é RATE ou outros modos de métricas não personalizadas

  • Se o equilíbrio de carga se basear em critérios que não sejam métricas personalizadas, como RATE para pedidos por segundo, pode definir dryRun: true para todas as métricas personalizadas. Isto permite-lhe monitorizar métricas personalizadas sem afetar o mecanismo de equilíbrio principal. Isto é útil para testar novas métricas personalizadas antes de mudar o seu balancingMode para CUSTOM_METRICS.

• Monitorizar métricas personalizadas

  • Depois de configurar o GCPBackendPolicy e começar a enviar tráfego para a sua aplicação, as métricas personalizadas, como gke.cpu, demoram algum tempo a aparecer no explorador de métricas.
  • Para que as métricas personalizadas sejam visíveis e estejam ativas no explorador de métricas, tem de haver tráfego real a fluir através do back-end que a política monitoriza. Se não houver tráfego, a métrica só pode ser visível em "Recursos inativos" no explorador de métricas.

Defina um limite de utilização da CPU personalizado

Por predefinição, o GKE distribui o tráfego para longe dos back-ends que excedem 80% de utilização da CPU. No entanto, determinadas cargas de trabalho podem tolerar uma utilização da CPU mais alta ou mais baixa antes de exigirem a redistribuição do tráfego. Pode personalizar este limite usando o campo maxUtilizationPercent no recurso GCPBackendPolicy.

1. Para configurar um serviço do GKE de modo que permita que os back-ends usem até 70% da CPU antes de o reequilíbrio ser acionado, guarde 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
   

   Tenha em conta o seguinte:

   • O campo maxUtilizationPercent aceita valores de 0 a 100. Um valor de 100 significa que um back-end pode usar a sua capacidade total da CPU antes de o tráfego ser reequilibrado.
   • Para cargas de trabalho sensíveis à latência que requerem descarregamento antecipado, use um limite inferior.
   • Para cargas de trabalho concebidas para serem executadas perto da capacidade total, use um limite mais elevado.
   • Para serviços em vários clusters, o spec.targetRef.kind tem de ser ServiceImport e o group tem de ser net.gke.io.

2. Aplique o manifesto de exemplo ao seu cluster:

   kubectl apply -f my-backend-policy.yaml
   

Ao ativar um limite de utilização da CPU personalizado, pode controlar a distribuição do tráfego com base na utilização da CPU do back-end.

(Opcional) Ative o modo de teste

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

1. Para ativar o modo de teste para o seu serviço GKE, guarde o seguinte manifesto de exemplo 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 seu cluster:

   kubectl apply -f my-backend-policy.yaml
   

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

• As métricas continuam a ser exportadas para o Cloud Monitoring em network.googleapis.com/loadbalancer/backend/lb_custom_metrics.

Depois de rever as métricas, remova o campo dryRun do seu GCPBackendPolicy e volte a aplicar a configuração. Se ocorrerem problemas depois de desativar o teste de execução, reative-o adicionando dryRun: true novamente à política.

Valide a política

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

kubectl describe gcpbackendpolicy POLICY_NAME -n NAMESPACE

O resultado é semelhante ao 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:
…

Configure o equilíbrio de carga baseado na utilização através das APIs Compute Engine

Recomendamos que use a API Kubernetes Gateway para configurar o equilíbrio de carga baseado na utilização para os seus serviços do GKE.

No entanto, pode preferir usar as APIs Compute Engine ou o Terraform para gerir os seus equilibradores de carga diretamente. Se escolher esta abordagem, tem de ativar o equilíbrio de carga baseado na utilização ao nível do BackendService.

1. Para um BackendService existente, ative o balanceamento de carga baseado na utilização e anexe um grupo de pontos finais da 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 o seguinte:

   • MY_BACKEND_SERVICE com o nome do seu BackendService.
   • CUSTOM_METRICS com CUSTOM_METRICS.

2. Para atualizar as definições de equilíbrio de carga baseado na utilização para uma entrada de back-end existente no seu BackendService onde já está anexado um NEG, 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.

Nota: se usar métricas personalizadas, mantenha o número de dimensões configuradas abaixo do limite do serviço. Se exceder o limite, não vai poder adicionar mais dimensões.

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

Para desativar o equilíbrio de carga baseado na utilização nos seus serviços do GKE, siga estes passos:

1. Se quiser manter a política para outras definições, remova os campos balancingMode e customMetrics do seu GCPBackendPolicy.
2. Se já não precisar do GCPBackendPolicy, pode eliminá-lo.
3. Se usar as APIs Compute Engine, altere novamente as flags --balancing-mode e --custom-metrics do seu serviço de back-end.

O que se segue?

• Vista geral dos grupos de pontos finais de rede zonais