Balanceamento de carga nativa do contentor

Esta página explica o balanceamento de carga nativo do contentor no Google Kubernetes Engine (GKE).

Esta página pressupõe que conhece o Cloud Load Balancing e os grupos de pontos finais de rede (NEGs) zonais. Com o balanceamento de carga nativa do contentor, estes balanceadores de carga podem distribuir o tráfego diretamente e de forma uniforme para os pods.

Arquitetura de balanceamento de carga nativa do contentor

O balanceamento de carga nativa do contentor usa GCE_VM_IP_PORTgrupos de pontos finais da rede (NEGs). Os pontos finais do NEG são endereços IP de pods.

O balanceamento de carga nativa do contentor é sempre usado para o GKE Ingress interno e é opcional para o Ingress externo. O controlador de entrada cria o balanceador de carga, incluindo o endereço IP virtual, as regras de encaminhamento, as verificações de estado e as regras de firewall.

Para saber como usar o balanceamento de carga nativa do contentor com a entrada, consulte o artigo Balanceamento de carga nativa do contentor através da entrada.

Para maior flexibilidade, também pode criar NEGs autónomas. Neste caso, é responsável por criar e gerir todos os aspetos do equilibrador de carga.

Vantagens do balanceamento de carga nativa do contentor

O balanceamento de carga nativa do contentor oferece as seguintes vantagens:

Os pods são objetos essenciais para o balanceamento de carga
kube-proxy configura as regras iptables dos nós para distribuir o tráfego para os pods. Sem o balanceamento de carga nativo do contentor, o tráfego do balanceador de carga desloca-se para os grupos de instâncias de nós e é encaminhado através de regras para os pods, que podem ou não estar no mesmo nó.iptables Com o balanceamento de carga nativa do contentor, o tráfego do balanceador de carga é distribuído diretamente para os pods que devem receber o tráfego, eliminando o salto de rede adicional. O balanceamento de carga nativa do contentor também ajuda a melhorar a verificação do estado de funcionamento, uma vez que segmenta diretamente os pods.

Comparação do comportamento predefinido (à esquerda) com o comportamento do balanceador de carga nativa do contentor.
Desempenho da rede melhorado
Uma vez que o balanceador de carga nativo do contentor comunica diretamente com os pods e as ligações têm menos saltos de rede, a latência e o débito são melhorados.
Visibilidade aumentada
Com o balanceamento de carga nativa do contentor, tem visibilidade da latência do balanceador de carga de aplicações para os pods. A latência do balanceador de carga de aplicações para cada pod é visível, tendo sido agregada com o balanceamento de carga nativa do contentor baseado no IP do nó. Isto facilita a resolução de problemas dos seus serviços ao nível do GNE.
Suporte para funcionalidades avançadas de balanceamento de carga
O balanceamento de carga nativa do contentor no GKE suporta várias funcionalidades dos balanceadores de carga de aplicações externos, como a integração com serviços como o Google Cloud Armor, o Cloud CDN e o Identity-Aware Proxy. Trusted Cloud by S3NS Também inclui algoritmos de balanceamento de carga para uma distribuição precisa do tráfego.
Apoio técnico para o Cloud Service Mesh
O modelo de dados do NEG é necessário para usar o Cloud Service Mesh, Trusted Cloud's plano de controlo de tráfego totalmente gerido para a malha de serviços.

Disposição do agrupamento

Para os pods relevantes, o controlador de entrada correspondente gere um limite de disponibilidade do tipo cloud.google.com/load-balancer-neg-ready. O controlador Ingress consulta o estado da verificação de funcionamento do balanceador de carga, que inclui o estado de funcionamento de todos os pontos finais no NEG. Quando o estado da verificação de funcionamento do balanceador de carga indica que o ponto final correspondente a um determinado Pod está em bom estado, o controlador Ingress define o valor do gate de disponibilidade do Pod como True. O kubelet em execução em cada nó calcula a disponibilidade efetiva do pod, tendo em conta o valor deste gate de disponibilidade e, se definido, a sondagem de disponibilidade do pod.

Os gates de prontidão dos pods são ativados automaticamente quando usa o equilíbrio de carga nativo do contentor através do Ingress.

Os limites de disponibilidade controlam a taxa de uma atualização contínua. Quando inicia uma atualização incremental, à medida que o GKE cria novos pods, é adicionado um ponto final para cada novo pod a um NEG. Quando o ponto final está em bom estado do ponto de vista do balanceador de carga, o controlador de entrada define o portão de prontidão como True. Um pod criado recentemente tem de passar, pelo menos, o respetivo gate de prontidão antes de o GKE remover um pod antigo. Isto garante que o ponto final correspondente do pod já passou na verificação de estado do balanceador de carga e que a capacidade do back-end é mantida.

Se o indicador de disponibilidade de um Pod nunca indicar que o Pod está pronto, devido a uma imagem de contentor incorreta ou a uma verificação de estado do balanceador de carga mal configurada, o balanceador de carga não direciona o tráfego para o novo Pod. Se ocorrer uma falha deste tipo durante a implementação de uma implementação atualizada, a implementação fica bloqueada após tentar criar um novo pod, porque o gate de disponibilidade desse pod nunca é verdadeiro. Consulte a secção de resolução de problemas para ver informações sobre como detetar e corrigir esta situação.

Sem o equilíbrio de carga nativo do contentor e os gates de disponibilidade, o GKE não consegue detetar se os pontos finais de um equilibrador de carga estão em bom estado antes de marcar os pods como prontos. Nas versões anteriores do Kubernetes, controla a taxa de remoção e substituição de pods especificando um período de atraso (minReadySeconds na especificação de implementação).

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

  • Nenhum dos endereços IP do Pod é um ponto final num NEG gerido pelo plano de controlo do GKE.GCE_VM_IP_PORT
  • Um ou mais dos endereços IP do Pod são pontos finais num GCE_VM_IP_PORTNEG gerido pelo plano de controlo do GKE. O NEG está associado a um serviço de back-end. O serviço de back-end tem uma verificação do estado do balanceador de carga bem-sucedida.
  • Um ou mais dos endereços IP do Pod são pontos finais num GCE_VM_IP_PORTNEG gerido pelo plano de controlo do GKE. O NEG está anexado a um serviço de back-end. A verificação de funcionamento do balanceador de carga para o serviço de back-end expira.
  • Um ou mais dos endereços IP do pod são pontos finais num ou mais NEGs.GCE_VM_IP_PORT Nenhum dos NEGs está associado a um serviço de back-end. Não estão disponíveis dados de verificação de funcionamento do balanceador de carga.

Afinidade de sessão

O balanceamento de carga nativa do contentor suporta a afinidade de sessão baseada em pods.

Requisitos para usar o balanceamento de carga nativa do contentor

Os balanceadores de carga nativos do contentor através da entrada no GKE têm os seguintes requisitos:

  • O cluster tem de ser nativo de VPC.
  • O cluster tem de ter o suplemento HttpLoadBalancing ativado. Os clusters do GKE têm o suplemento HttpLoadBalancing ativado por predefinição. Não o deve desativar.

Limitações para balanceadores de carga nativos do contentor

Os balanceadores de carga nativa do contentor através da entrada no GKE têm as seguintes limitações:

  • Não suportam equilibradores de carga de rede de passagem externos.
  • Não deve alterar nem atualizar manualmente a configuração do Application Load Balancer que o GKE cria. Quaisquer alterações que fizer são substituídas pelo GKE.

O que se segue?