Balanceamento de carga nativo de contêiner

Nesta página, explicamos o que é balanceamento de carga nativo de contêiner no Google Kubernetes Engine (GKE). O balanceamento de carga nativo de contêiner permite que vários tipos de balanceadores de carga segmentem pods diretamente e distribuam uniformemente o tráfego para os pods.

Arquitetura de balanceamento de carga nativo de contêiner

O balanceamento de carga nativo de contêiner usa grupos de endpoints de rede (NEGs, na sigla em inglês) GCE_VM_IP_PORT. Os endpoints do NEG são endereços IP do pod.

O balanceamento de carga nativo de contêiner é sempre usado para Entrada interna do GKE e é opcional para Entrada externa. O controlador de entrada cria o balanceador de carga, incluindo o endereço IP virtual, as regras de encaminhamento, as verificações de integridade e as regras de firewall.

Para saber como usar o balanceamento de carga nativo do contêiner com o Ingress, consulte Balanceamento de carga nativo do contêiner por meio do Ingress.

Para mais flexibilidade, também é possível criar NEGs autônomos. Nesse caso, você é responsável por criar e gerenciar todos os aspectos do balanceador de carga.

Benefícios do balanceamento de carga nativo de contêiner

O balanceamento de carga nativo de contêiner oferece os seguintes benefícios:

Os pods são objetos principais para balanceamento de carga
O
kube-proxy (em inglês) configura as regras dos nós iptables para distribuir tráfego para os pods. Sem balanceamento de carga nativo de contêiner, o tráfego do balanceador de carga viaja para os grupos de instâncias do nó e é roteado por meio de regras iptables para pods que podem ou não estar no mesmo nó. Com o balanceamento de carga nativo de contêiner, o tráfego do balanceador de carga é distribuído diretamente para os pods destinados a recebê-lo, eliminando o salto extra de rede. O balanceamento de carga nativo de contêiner também ajuda a melhorar a verificação de integridade, visto que é direcionado para os pods.

Comparação do comportamento padrão (à esquerda) com o comportamento do balanceador de carga nativo de contêiner.
Melhor desempenho de rede
Como o balanceador de carga nativo de contêiner se comunica diretamente com os pods e as conexões têm menos saltos de rede, a latência e a capacidade são aprimoradas.
Maior visibilidade
Com o balanceamento de carga nativo de contêiner, você tem visibilidade da latência do balanceador de carga de aplicativo para os pods. Agregada ao balanceamento de carga nativo de contêiner no IP do nó, a latência é visível desde o balanceador de carga de aplicativo até cada pod. Isso facilita a solução de problemas dos serviços no nível de NEG.
Suporte para recursos avançados de balanceamento de carga
O balanceamento de carga nativo de contêiner no GKE oferece suporte a vários recursos de balanceadores de carga de aplicativo externos, como a integração com serviços do Google Cloud, como Google Cloud Armor, CDN do Cloud e Identity-Aware Proxy. Outro atributo são os algoritmos de balanceamento de carga para distribuição de tráfego precisa.
Compatibilidade com o Cloud Service Mesh
O modelo de dados NEG é necessário para usar o Cloud Service Mesh, o plano de controle de tráfego totalmente gerenciado do Google Cloud para malha de serviço.

Prontidão do pod

Para os pods relevantes, o controlador de entrada correspondente gerencia um portão de prontidão do tipo cloud.google.com/load-balancer-neg-ready. O controlador de entrada pesquisa o status de verificação de integridade do balanceador de carga, que inclui a integridade de todos os endpoints no NEG. Ao indicar que o endpoint correspondente a um pod específico está íntegro, o controlador de entrada define o valor do portão de prontidão do pod como True. O kubelet em execução em cada nó calcula então a prontidão efetiva do pod, considerando o valor deste portão de prontidão e, se definida, a sondagem de prontidão do pod.

Os portões de prontidão do pod são ativados automaticamente ao usar o balanceamento de carga nativo de contêiner por meio do Ingress.

Os gates de prontidão controlam a taxa de uma atualização gradual. Ao iniciar uma atualização gradual, conforme o GKE cria novos pods, um endpoint para cada novo pod é adicionado a um NEG. Quando o endpoint é íntegro na perspectiva do balanceador de carga, o controlador de tráfego de entrada define o portão de prontidão como True. Um pod recém-criado precisa pelo menos passar pelo portão de prontidão antes que o GKE remova um pod antigo. Isso garante que o endpoint correspondente do pod já tenha passado pela verificação de integridade do balanceador de carga e que a capacidade do back-end seja mantida.

Se o portão de prontidão de um pod não indicar que o pod está pronto, devido a uma imagem ruim do contêiner ou uma verificação de integridade do balanceador de carga configurada incorretamente, o balanceador de carga não direcionará tráfego para o novo pod. Se isso ocorrer durante o lançamento de uma implantação atualizada, o lançamento será interrompido após tentar criar um novo pod porque o portão de prontidão desse pod nunca será "True". Veja a seção de solução de problemas (em inglês) para mais informações sobre como detectar e corrigir esta situação.

Sem portões de prontidão e balanceamento de carga nativos de contêiner, o GKE não consegue detectar se os endpoints de um balanceador de carga estão íntegros antes de marcar os pods como prontos. Nas versões anteriores do Kubernetes, você controla a taxa de remoção e de substituição dos pods, especificando um período de atraso (minReadySeconds na especificação de implantação).

O GKE define o valor de cloud.google.com/load-balancer-neg-ready de um pod como True se alguma das seguintes condições for atendida:

  • Nenhum dos endereços IP do pod são endpoints em um GCE_VM_IP_PORT NEG gerenciado pelo plano de controle do GKE.
  • Um ou mais endereços IP do pod são endpoints em um NEG GCE_VM_IP_PORT gerenciado pelo plano de controle do GKE. O NEG está anexado a um serviço de back-end. O serviço de back-end tem uma verificação de integridade do balanceador de carga bem-sucedida.
  • Um ou mais endereços IP do pod são endpoints em um NEG GCE_VM_IP_PORT gerenciado pelo plano de controle do GKE. O NEG é anexado a um serviço de back-end. A verificação de integridade do balanceador de carga para o serviço de back-end expira.
  • Um ou mais endereços IP do pod são endpoints em um ou mais NEGs GCE_VM_IP_PORT. Nenhum dos NEGs está anexado a um serviço de back-end. Não há dados de verificação de integridade do balanceador de carga disponíveis.

Afinidade da sessão

O balanceamento de carga nativo de contêiner é compatível com a afinidade da sessão baseada em pods.

Requisitos para usar o balanceamento de carga nativo de contêiner

Os balanceadores de carga nativos de contêiner pela Entrada no GKE têm os seguintes requisitos:

  • O cluster precisa ser nativo de VPC.
  • O cluster precisa ter o complemento HttpLoadBalancing ativado. Os clusters do GKE têm o complemento HttpLoadBalancing ativado por padrão. Não o desative.

Limitações para balanceadores de carga nativos de contêiner

Os balanceadores de carga nativos de contêiner por meio do tráfego de entrada no GKE têm os seguintes requisitos:

  • Não oferece suporte a balanceadores de carga de rede de passagem externa.
  • Não altere ou atualize manualmente a configuração do balanceador de carga de aplicativo criado pelo GKE. Todas as alterações feitas são substituídas pelo GKE.

Preços de balanceadores de carga nativos de contêiner

Você vai receber cobranças pelo balanceador de carga de aplicativo provisionado pelo Ingress criado neste guia. Para informações sobre preços do balanceador de carga, consulte as Regras de encaminhamento e balanceamento de carga na página de preços da VPC.

A seguir