Balanceamento de carga nativo de contêiner

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.

Esse balanceamento de carga nativo de contêiner aproveita um modelo de dados denominado grupos de endpoints da rede (NEGs, na sigla em inglês), que são coleções de endpoints de rede representados por pares de IP-porta.

Quando os NEGs são usados com a Entrada do GKE, o controlador da Entrada facilita a criação de todos os aspectos do balanceador de carga L7. Isso inclui a criação de endereço IP virtual, regras de encaminhamento, verificações de integridade, regras de firewall e muito mais.

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

Vantagens

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 HTTP(S) 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 HTTP(S) 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 oferece suporte nativo no Google Kubernetes Engine para diversos recursos de balanceamento de carga HTTP, como a integração com serviços do Google Cloud como Google Cloud Armor, Cloud CDN e Identity-Aware Proxy. Outro atributo são os algoritmos de balanceamento de carga para distribuição de tráfego precisa.
Suporte para o Traffic Director
O modelo de dados NEG é necessário para usar o Traffic Director, o plano de controle de tráfego totalmente gerenciado do Google Cloud para a malha serviço.

Prontidão do pod

Para os pods relevantes, o controlador de entrada correspondente gerencia um portão de prontidão (em inglês) 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 (em inglês) do pod.

Para balanceamento de carga nativo de contêiner por meio do tráfego de entrada, os gates de prontidão do conjunto são ativados automaticamente em:

  • Clusters GKE v1.13 com a v1.13.8 e posterior
  • Clusters GKE v1.14 com a v1.14.4 e posterior
  • v1.15 e posterior

Os gates de prontidão controlam a taxa de uma atualização gradual. As versões do GKE listadas acima adicionam portões de prontidão aos pods automaticamente. 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 gate de prontidão como True. Assim, um pod recém-criado precisa pelo menos passar pelo gate 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).

Requisitos

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

Versão do Google Kubernetes Engine

Os balanceadores de carga nativos de contêiner estão geralmente disponíveis em:

  • Clusters GKE v1.13 com a v1.13.8 e posterior
  • Clusters GKE v1.14 com a v1.14.4 e posterior
  • v1.15 e posterior
Cluster nativo de VPC

Para usar o balanceamento de carga nativo de contêiner, os clusters precisam ser nativos de VPC. Para saber mais, consulte Como criar clusters nativos de VPC usando IPs de alias.

Balanceamento de carga HTTP

Para usar o balanceamento de carga nativo do contêiner, o cluster precisa ter o balanceamento de carga HTTP ativado. Os clusters do GKE têm o balanceamento de carga HTTP ativado por padrão. Não o desative.

Restrições

Balanceadores de carga nativos de contêiner não funcionam com redes legadas.

Limitações

Os balanceadores de carga nativos de contêiner não são compatíveis com balanceadores de carga TCP/UDP internos ou de rede.

Preço

Você é cobrado pelo balanceador de carga HTTP(S) provisionado pela entrada criada 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