Sobre os serviços LoadBalancer

Autopilot Standard

Nesta página, apresentamos uma visão geral de como o Google Kubernetes Engine (GKE) cria e gerencia balanceadores de carga Google Cloud quando você aplica um manifesto dos serviços do LoadBalancer do Kubernetes. Ele descreve os tipos de LoadBalancer, os parâmetros de configuração e oferece recomendações de práticas recomendadas.

Antes de ler esta página, você precisa conhecer bem o GKE de rede.

Visão geral

Quando você cria um serviço LoadBalancer, o GKE configura um balanceador de carga de passagem Google Cloud cujas características dependem dos parâmetros do seu manifesto de Serviço.

Personalizar o serviço LoadBalancer

Ao escolher a configuração do serviço LoadBalancer, considere os seguintes aspectos:

• Tipo de balanceador de carga: interno ou externo
• Política de tráfego externo
• Balanceamento de carga ponderado
• Afinidade zonal

Figura : árvore de decisão do serviço LoadBalancer

Tipo de balanceador de carga: interno ou externo

Ao criar um serviço LoadBalancer no GKE, você especifica se o balanceador de carga tem um endereço interno ou externo:

• Os serviços LoadBalancer externos são implementados usando balanceadores de carga de rede de passagem externa. Os clientes localizados fora da rede VPC e as VMs com acesso à Internet podem acessar um serviço LoadBalancer externo. Google Cloud

  Para criar um serviço LoadBalancer externo, use uma das seguintes técnicas:

  • Em clusters que executam o GKE 1.33.1-gke.1779000 ou versões mais recentes, adicione spec.loadBalancerClass: "networking.gke.io/l4-regional-external" ao manifesto do serviço antes de enviar o manifesto ao cluster. Recomendamos usar esse campo porque ele sempre cria um balanceador de carga de rede de passagem externa baseado em serviço de back-end com back-ends de NEG GCE_VM_IP. O campo spec.loadBalancerClass é imutável e não pode ser alterado depois que o serviço é criado.

  • Em clusters que executam qualquer versão compatível do GKE, é possível adicionar a anotação cloud.google.com/l4-rbs: "enabled" ao manifesto do serviço antes de enviar o manifesto ao cluster. Essa anotação também cria um balanceador de carga de rede de passagem externa baseado em serviço de back-end. O balanceador de carga usa back-ends de NEG GCE_VM_IP se o manifesto for enviado a um cluster que executa o GKE 1.32.2-gke.1652000 ou mais recente. Caso contrário, o balanceador de carga usará back-ends de grupo de instâncias. O GKE só avalia essa anotação quando o manifesto do serviço é aplicado ao cluster pela primeira vez.

• Os serviços LoadBalancer internos são implementados usando balanceadores de carga de rede de passagem interna. Os clientes localizados na mesma rede VPC ou em uma rede conectada à rede VPC do cluster podem acessar um serviço LoadBalancer interno.

  Como prática recomendada, antes de criar um serviço LoadBalancer interno, verifique se a criação de subconjuntos do GKE está ativada. A criação de subconjuntos do GKE é ativada automaticamente se o cluster executar o GKE 1.36 ou uma versão mais recente. Em versões anteriores do GKE, é necessário ativar explicitamente a criação de subconjuntos do GKE.

  Para criar um serviço LoadBalancer interno, use uma das seguintes técnicas:

  • Em clusters que executam o GKE 1.33.1-gke.1779000 ou versões mais recentes com criação de subconjuntos do GKE ativada, adicione spec.loadBalancerClass: "networking.gke.io/l4-regional-internal" ao manifesto do serviço antes de enviar o manifesto ao cluster. Recomendamos usar esse campo porque ele sempre cria um balanceador de carga de rede de passagem interna com back-ends de NEG GCE_VM_IP. O campo spec.loadBalancerClass é imutável e não pode ser alterado depois que o serviço é criado.

  • Em clusters que executam qualquer versão compatível do GKE, é possível adicionar a anotação networking.gke.io/load-balancer-type: "Internal" ao manifesto do serviço antes de enviá-lo ao cluster. Isso também cria um balanceador de carga de rede de passagem interna. O balanceador de carga usa back-ends de NEG GCE_VM_IP se o manifesto for enviado a um cluster com a criação de subagrupamentos do GKE ativada. Caso contrário, o balanceador de carga usará back-ends de grupo de instâncias.

Os manifestos de serviço LoadBalancer que não têm spec.loadBalancerClass e que não têm as anotações cloud.google.com/l4-rbs: "enabled" ou networking.gke.io/load-balancer-type: "Internal" criam um balanceador de carga de rede de passagem externa baseado em pool de destino. Não recomendamos o uso de balanceadores de carga de rede de passagem externa baseados em pool de destino.

Pré-requisito do HttpLoadBalancing

Para criar serviços LoadBalancer com tecnologia de balanceadores de carga de rede de passagem externa baseados em serviço de back-end ou balanceadores de carga de rede de passagem interna, verifique se o complemento HttpLoadBalancing está ativado se o cluster executar uma versão do GKE anterior à 1.36. O complemento HttpLoadBalancing é ativado por padrão.

Os serviços LoadBalancer no GKE versão 1.36 e mais recentes não dependem do complemento HttpLoadBalancing.

Efeito de externalTrafficPolicy

O parâmetro externalTrafficPolicy controla o seguinte:

• Quais nós recebem pacotes do balanceador de carga
• Se os pacotes podem ser roteados entre nós no cluster depois que o balanceador de carga os entrega a um nó.
• Se o endereço IP original do cliente é preservado ou perdido

O externalTrafficPolicy pode ser Local ou Cluster:

• Use externalTrafficPolicy: Local para garantir que os pacotes sejam apenas entregues a um nó com pelo menos um pod de exibição pronto e não encerrado, preservando o endereço IP de origem do cliente original. Essa opção é melhor para cargas de trabalho com um número relativamente constante de nós com pods de serviço, mesmo que o número geral de nós no cluster varie. Essa opção é necessária para oferecer suporte ao balanceamento de carga ponderado.

Observação: o uso da política Local para preservar endereços IP de origem não vai funcionar se ip-masq-agent estiver em execução no cluster e o intervalo de endereços IP do pod não for excluído do mascaramento de IP. Consulte custom nonMasqueradeCIDRs list in the ip-masq-agent configMap para instruções sobre como excluir intervalos de endereços IP do mascaramento.

• Use externalTrafficPolicy: Cluster em situações em que o número geral de nós no cluster é relativamente constante, mas o número de nós com pods de veiculação varia. Essa opção não preserva os endereços IP de origem do cliente original e pode adicionar latência porque os pacotes podem ser roteados para um pod de serviço em outro nó depois de serem entregues a um nó do balanceador de carga. Essa opção é incompatível com o balanceamento de carga ponderado.

Para mais informações sobre como externalTrafficPolicy afeta o roteamento de pacotes nos nós, consulte processamento de pacotes.

Importante: para serviços LoadBalancer internos, o externalTrafficPolicy também determina indiretamente quantos nós com pods de exibição são compatíveis. Para mais informações, consulte Considerações sobre a contagem de nós.

Balanceamento de carga ponderado

Os serviços LoadBalancer externos oferecem suporte ao balanceamento de carga ponderado, o que permite que nós com mais pods em execução, prontos e não encerrados recebam uma proporção maior de novas conexões em comparação com nós com menos pods. Para mais informações sobre como as configurações do balanceador de carga mudam com o balanceamento de carga ponderado, consulte Efeito do balanceamento de carga ponderado.

Figura: distribuição de tráfego do balanceamento de carga ponderado

Como ilustra o diagrama, os serviços com balanceamento de carga ponderado ativado distribuem novas conexões proporcionalmente ao número de pods prontos em cada nó.

Para usar o balanceamento de carga ponderado, você precisa atender a todos os requisitos a seguir:

• Seu cluster do GKE precisa usar a versão 1.31.0-gke.1506000 ou mais recente.

• Você precisa criar um serviço LoadBalancer externo que resulte em um balanceador de carga de rede de passagem externa baseado em serviço de back-end. Use uma das seguintes técnicas:

  • Em clusters que executam o GKE 1.33.1-gke.1779000 ou mais recente, adicione spec.loadBalancerClass: "networking.gke.io/l4-regional-external" ao manifesto do serviço antes de enviar o manifesto ao cluster. Esse é o método preferencial.

  • Em clusters que executam qualquer versão compatível do GKE, adicione a anotação cloud.google.com/l4-rbs: "enabled" ao manifesto do serviço antes de enviar o manifesto ao cluster.

• Inclua a anotação networking.gke.io/weighted-load-balancing: pods-per-node no manifesto do serviço para ativar o recurso de balanceamento de carga ponderado.

• O manifesto do serviço LoadBalancer precisa usar externalTrafficPolicy: Local. O GKE não impede o uso de externalTrafficPolicy: Cluster, mas externalTrafficPolicy: Cluster desativa o balanceamento de carga ponderado porque o pacote pode ser encaminhado, após o balanceador de carga, para um nó diferente.

Para usar o balanceamento de carga ponderado, consulte Ativar o balanceamento de carga ponderado.

Afinidade zonal

Os serviços LoadBalancer internos são compatíveis com a afinidade zonal (prévia), que pode rotear novas conexões para nós com pods de disponibilização na mesma zona que um cliente. Se não houver pods íntegros na zona, o GKE vai rotear o tráfego para outra zona. Manter o tráfego dentro de uma zona pode minimizar o tráfego entre zonas, o que reduz o custo e a latência. Para ativar a afinidade zonal em um cluster do GKE, é necessário ativar a criação de subconjuntos do GKE.

Para mais informações sobre como as configurações do balanceador de carga mudam com a afinidade zonal, incluindo quando é possível manter o tráfego em uma zona, consulte Efeito da afinidade zonal. Para mais informações sobre como a afinidade zonal e externalTrafficPolicy influenciam o roteamento de pacotes em VMs de nós, consulte Conversão de endereços de rede de origem e roteamento em nós.

Considerações especiais para serviços LoadBalancer internos

Esta seção descreve o recurso de subconfiguração do GKE, que é exclusivo dos serviços LoadBalancer internos, e como a subconfiguração do GKE interage com o externalTrafficPolicy para influenciar o número máximo de nós balanceados por carga.

Subconfiguração do GKE

A subconfiguração do GKE para serviços LoadBalancer internos é ativada por padrão para clusters do GKE que executam a versão 1.36 e mais recentes. Para essas versões, a criação de subconjuntos do GKE permanece ativa mesmo que a flag --enable-l4-ilb-subsetting no nível do cluster esteja definida como false na configuração do cluster ou em ferramentas de Infraestrutura como código (IaC), como o Terraform.

Essa opção de configuração em todo o cluster melhora a escalonabilidade dos balanceadores de carga de rede de passagem internos ao agrupar com mais eficiência os endpoints do nó em GCE_VM_IP grupos de endpoints de rede (NEGs). Os NEGs são usados como back-ends do balanceador de carga.

O diagrama a seguir mostra dois serviços em um cluster zonal com três nós. O cluster tem a criação de subconjuntos do GKE ativada. Cada serviço tem dois pods. O GKE cria um NEG GCE_VM_IP para cada serviço. Os endpoints em cada NEG são os nós com os pods de exibição para o respectivo serviço.

Para clusters que executam versões anteriores à 1.36, é possível ativar manualmente a subdivisão do GKE ao criar ou atualizar um cluster. Depois que a criação de subconjuntos do GKE é ativada, não é possível desativá-la.

A subconfiguração do GKE requer:

• GKE versão 1.18.19-gke.1400 ou posterior e
• Se o cluster estiver em uma versão anterior à 1.36, o complemento HttpLoadBalancing precisa ser ativado. Esse complemento é ativado por padrão. Ele permite que o cluster gerencie balanceadores de carga que usam serviços de back-end. Se o cluster estiver na versão 1.36 ou mais recente, o complemento HttpLoadBalancing não será um pré-requisito para a criação de subconjuntos do GKE.

Observação :o subagrupamento do GKE é diferente da subconfiguração de back-end do balanceador de carga de rede de passagem interna do Google Cloud. Os balanceadores de carga de rede de passagem interna criados pelo GKE nunca são configurados para usar a subconfiguração de back-end do balanceador de carga de rede de passagem interna.

Contagem de nós

Um cluster com a subconfiguração do GKE desativada pode ter problemas com serviços LoadBalancer internos se tiver mais de 250 nós no total, entre todos os pools de nós. Isso acontece porque os balanceadores de carga de rede de passagem interna criados pelo GKE só podem distribuir pacotes para 250 ou menos VMs de nós de back-end. Essa limitação existe pelos seguintes motivos:

• O GKE não usa subconjunto de back-end do balanceador de carga.
• Um balanceador de carga de rede de passagem interna está limitado à distribuição de pacotes para 250 back-ends ou menos quando a criação de sub-rede de back-end do balanceador de carga está desativada.

Um cluster com subconfiguração do GKE aceita serviços LoadBalancer internos em clusters com mais de 250 nós no total.

O número de nós compatíveis com a criação de subconjuntos do GKE depende do valor do campo externalTrafficPolicy para o serviço LoadBalancer interno:

• externalTrafficPolicy: Local: oferece suporte a até 250 nós com pods de exibição para um determinado serviço.

• externalTrafficPolicy: Cluster: não impõe um limite ao número de nós com pods de serviço. Isso acontece porque o GKE configura um máximo de 25 endpoints de nós em NEGs GCE_VM_IP para cada serviço. Para mais informações, consulte Assinatura de nós em back-ends de NEG GCE_VM_IP.

Distribuição de tráfego

Por padrão, os serviços LoadBalancer internos e externos criam balanceadores de carga de rede de passagem com afinidade da sessão definida como NONE. Os balanceadores de carga de rede de passagem usam afinidade de sessão, informações de integridade e, em determinadas circunstâncias, detalhes como peso para identificar e selecionar um back-end de nó qualificado para uma nova conexão.

Novas conexões criam entradas na tabela de rastreamento de conexão, que são usadas para rotear rapidamente pacotes subsequentes da conexão para o back-end do nó qualificado selecionado anteriormente. Para mais informações sobre como os balanceadores de carga de rede de passagem identificam e selecionam back-ends qualificados e usam o rastreamento de conexão, consulte o seguinte:

• Distribuição de tráfego para balanceadores de carga de rede de passagem interna

• Distribuição de tráfego para balanceadores de carga de rede de passagem externa

Efeito do balanceamento de carga ponderado

Quando você configura o balanceamento de carga ponderado para um serviço de balanceador de carga externo, o GKE ativa o balanceamento de carga ponderado no balanceador de carga de rede de passagem externa correspondente. O GKE configura o software kube-proxy ou cilium-agent para incluir um cabeçalho de resposta na resposta à verificação de integridade do balanceador de carga. Esse cabeçalho de resposta define um peso proporcional ao número de pods em serviço, prontos e não encerrados em cada nó.

O balanceador de carga usa as informações de ponderação da seguinte forma:

• O conjunto de back-ends de nós qualificados do balanceador de carga consiste em todos os nós íntegros e com peso diferente de zero.

• O balanceador de carga considera o peso ao selecionar um dos back-ends de nó qualificados. Quando o serviço usa externalTrafficPolicy: Local (necessário para que o balanceamento de carga ponderado seja eficaz), um back-end de nó qualificado que tem mais pods de exibição, prontos e não encerrados tem mais chances de ser selecionado do que um back-end de nó qualificado com menos pods.

Efeito da afinidade zonal

Quando você configura a afinidade zonal para um serviço LoadBalancer interno, o GKE configura o balanceador de carga de rede de passagem interno correspondente com a opção ZONAL_AFFINITY_SPILL_CROSS_ZONE e uma taxa de transbordamento zero.

Com essa configuração de afinidade zonal, o balanceador de carga restringe o conjunto original de back-ends de nós qualificados apenas aos que estão na mesma zona do cliente quando todas as condições a seguir são verdadeiras:

• O cliente é compatível com a afinidade zonal.

• Pelo menos um back-end de nó íntegro e qualificado está na zona do cliente.

Em todas as outras situações, o balanceador de carga continua usando o conjunto original de back-ends de nós qualificados, sem aplicar nenhuma otimização de afinidade zonal.

Para mais detalhes sobre como a configuração de afinidade zonal afeta o comportamento do balanceador de carga, consulte a documentação Afinidade zonal.

Agrupamento de nós

A versão do GKE, as anotações do manifesto do serviço e, para serviços LoadBalancer internos, a opção subconfiguração do GKE determinam o balanceador de carga Google Cloud resultante e o tipo de back-ends.

A tabela a seguir descreve os métodos de agrupamento de nós para diferentes configurações de serviço LoadBalancer:

Detalhes do serviço e do cluster	Balanceador de carga Google Cloud resultante	Método de agrupamento de nós
Serviços LoadBalancer internos
GKE versão 1.33.1-gke.1779000 ou mais recente em um cluster com a criação de subconjuntos do GKE ativada^1. Manifesto de serviço enviado ao cluster com spec.loadBalancerClass: "networking.gke.io/l4-regional-internal".	Um balanceador de carga de rede de passagem interna cujo serviço de back-end usa back-ends de grupo de endpoints de rede (NEG, na sigla em inglês) GCE_VM_IP	As VMs de nós são agrupadas em GCE_VM_IP NEGs zonais por serviço de acordo com o externalTrafficPolicy do serviço e o número de nós no cluster. O externalTrafficPolicy do serviço também controla quais nós passam na verificação de integridade do balanceador de carga e no processamento de pacotes.
Todas as versões compatíveis do GKE em um cluster com a subconfiguração do GKE ativada^1. Manifesto de serviço enviado ao cluster com a anotação networking.gke.io/load-balancer-type: "Internal".
Versões do GKE anteriores à 1.36 em um cluster com a criação de subconjuntos do GKE desativada^1. Manifesto de serviço enviado ao cluster com a anotação networking.gke.io/load-balancer-type: "Internal".	Um balanceador de carga de rede de passagem interna cujo serviço de back-end usa back-ends zonais de grupos de instâncias não gerenciadas .	Todas as VMs de nós são colocadas em grupos de instâncias não gerenciadas zonais que o GKE usa como back-ends para o serviço de back-end do balanceador de carga de rede de passagem interna. O externalTrafficPolicy do serviço controla quais nós passam na verificação de integridade do balanceador de carga e no processamento de pacotes. Os mesmos grupos de instâncias não gerenciadas são usados para outros serviços de back-end do balanceador de carga criados no cluster devido à limitação do grupo de instâncias com balanceamento de carga único.
Serviços LoadBalancer externos
GKE versão 1.33.1-gke.1779000 ou posterior. Manifesto de serviço enviado ao cluster com spec.loadBalancerClass: "networking.gke.io/l4-regional-external".	Um balanceador de carga de rede de passagem externa baseado em serviço de back-end com back-ends de grupo de endpoints de rede (NEG) GCE_VM_IP	As VMs de nós são agrupadas em GCE_VM_IP NEGs zonais por serviço de acordo com o externalTrafficPolicy do serviço e o número de nós no cluster. O externalTrafficPolicy do serviço também controla quais nós passam na verificação de integridade do balanceador de carga e no processamento de pacotes.
GKE versão 1.32.2-gke.1652000 ou posterior. Manifesto de serviço enviado ao cluster com a anotação cloud.google.com/l4-rbs: "enabled"^2.
Versão do GKE anterior à 1.32.2-gke.1652000^3. Manifesto de serviço enviado ao cluster com a anotação cloud.google.com/l4-rbs: "enabled"^2.	Um balanceador de carga de rede de passagem externa baseado em serviço de back-end com back-ends zonais de grupo de instâncias não gerenciadas	Todas as VMs de nós são colocadas em grupos de instâncias não gerenciadas zonais que o GKE usa como back-ends para o serviço de back-end do balanceador de carga de rede de passagem externa. O externalTrafficPolicy do serviço controla quais nós passam na verificação de integridade do balanceador de carga e no processamento de pacotes. Os mesmos grupos de instâncias não gerenciadas são usados para outros serviços de back-end do balanceador de carga criados no cluster devido à limitação do grupo de instâncias com balanceamento de carga único.
Todas as versões compatíveis do GKE. Manifesto de serviço enviado ao cluster sem todos os seguintes itens: spec.loadBalancerClass networking.gke.io/load-balancer-type anotação cloud.google.com/l4-rbs anotação	Um balanceador de carga de rede de passagem externa baseado em pool de destino em que o pool de destino contém todos os nós do cluster	O pool de destino é uma API legada que não depende de NEGs ou grupos de instâncias. Todos os nós têm associação direta no pool de destino. O externalTrafficPolicy do serviço controla quais nós passam na verificação de integridade do balanceador de carga e no processamento de pacotes.

¹A criação de subconjuntos do GKE é ativada automaticamente na versão 1.36 e mais recentes do GKE. Não é possível desativar a criação de subconjuntos do GKE depois de ativá-la.

²A anotação cloud.google.com/l4-rbs: "enabled" só é respeitada quando o manifesto do serviço é enviado ao cluster. Adicionar essa anotação a um manifesto de serviço atual não converte um balanceador de carga de rede de passagem externa baseado em pool de destino em um balanceador de carga de rede de passagem externa baseado em serviço de back-end.

³O GKE não atualiza automaticamente os balanceadores de carga de rede de passagem externa baseados em serviço de back-end com back-ends de grupo de instâncias para balanceadores de carga de rede de passagem externa baseados em serviço de back-end com back-ends de NEG GCE_VM_IP. Para instruções de migração manual, consulte Migrar para back-ends do NEG GCE_VM_IP.

Assinatura de nós em GCE_VM_IP back-ends NEG

Quando o GKE cria um balanceador de carga de rede de passagem interno ou um balanceador de carga de rede de passagem externa baseado em serviço de back-end com back-ends de NEG GCE_VM_IP, ele cria e gerencia os NEGs da seguinte maneira:

• O GKE cria um NEG GCE_VM_IP exclusivo em cada zona para cada serviço LoadBalancer. Ao contrário dos grupos de instâncias, os nós podem ser membros de mais de um NEG GCE_VM_IP com balanceamento de carga.

• O externalTrafficPolicy do serviço e o número de nós no cluster determinam quais nós são adicionados como endpoints aos NEGs GCE_VM_IP do serviço.

Observação: as NEGs GCE_VM_IP são diferentes das NEGs GCE_VM_IP_PORT. GCE_VM_IP_PORT Os NEGs contêm endpoints de IP do pod e porta do contêiner e são usados pelo gateway e pelo Entrada (nativo de contêiner). GCE_VM_IP NEGs identificam as interfaces de rede de VMs de nós usando o endereço IP do nó, mesmo que os pacotes com balanceamento de carga tenham destinos que correspondam ao endereço IP da regra de encaminhamento do balanceador de carga e a uma das portas configuradas para a regra de encaminhamento.

O plano de controle do cluster gerencia endpoints de nós em NEGs GCE_VM_IP de acordo com o valor de externalTrafficPolicy do serviço e o número de nós no cluster, conforme resumido nas tabelas a seguir.

Nós no balanceador de carga de rede de passagem interna

externalTrafficPolicy	Número de nós no cluster	Associação de endpoint
Cluster	1 a 25 nodes	O GKE usa todos os nós do cluster como endpoints para os NEGs do serviço, mesmo que um nó não contenha um pod de exibição para o serviço.
Cluster	Mais de 25 nós	O GKE usa um subconjunto aleatório de até 25 nós como endpoints para o(s) NEG(s) do serviço, mesmo que um nó não contenha um pod de exibição para o Serviço.
Local	qualquer número de nós^1	O GKE usa apenas nós que têm pelo menos um dos pods de exibição do serviço como endpoints para os NEGs do serviço.

¹Limitado a 250 nós com pods de exibição. Mais de 250 nós podem estar presentes no cluster, mas os balanceadores de carga de rede de passagem interna só podem ser distribuídos para 250 VMs de back-end quando a subconfiguração de back-end do balanceador de carga de rede de passagem interna está desativada. Mesmo com a subconfiguração do GKE ativada, o GKE nunca configura os balanceadores de carga de rede de passagem interna com a subconfiguração de back-end do balanceador de carga de rede interno de passagem. Para detalhes sobre esse limite, consulte Número máximo de instâncias de VM por serviço de back-end interno.

Nós no balanceador de carga de rede de passagem externa

externalTrafficPolicy	Número de nós no cluster	Associação de endpoint
Cluster	1 a 250 nós	O GKE usa todos os nós do cluster como endpoints para os NEGs do serviço, mesmo que um nó não contenha um pod de exibição para o serviço.
Cluster	Mais de 250 nós	O GKE usa um subconjunto aleatório de até 250 nós como endpoints para o(s) NEG(s) do serviço, mesmo que um nó não contenha um pod de exibição para o serviço.
Local	qualquer número de nós^1	O GKE usa apenas nós que têm pelo menos um dos pods de exibição do serviço como endpoints para os NEGs do serviço.

¹Limitado a 3.000 nós com pods de exibição. Mais de 3.000 nós podem estar presentes no cluster, mas o GKE só permite criar até 3.000 endpoints ao criar balanceadores de carga de rede de passagem externa baseados em serviço de back-end que usam back-ends de NEG GCE_VM_IP.

Limitação única de grupos de instâncias com carga balanceada

A API Compute Engine proíbe VMs de serem membros de mais de um grupo de instâncias com carga balanceada. Os nós do GKE estão sujeitos a essa restrição.

Ao usar back-ends de grupos de instâncias não gerenciadas, o GKE cria ou atualiza grupos de instâncias não gerenciadas com todos os nós de todos os pools de nós em cada zona que o cluster usa. Esses grupos de instâncias não gerenciadas são back-ends para os seguintes balanceadores de carga criados pelo GKE:

• Um balanceador de carga de rede de passagem interna criado para um serviço LoadBalancer interno cujo manifesto tem a anotação networking.gke.io/load-balancer-type: "Internal", enviado a um cluster que executa uma versão do GKE anterior à 1.36, com a subconfiguração do GKE desativada.
• Um balanceador de carga de rede de passagem externa baseado em serviço de back-end criado para um serviço LoadBalancer externo cujo manifesto tem a anotação cloud.google.com/l4-rbs: "enabled", enviado a um cluster que executa uma versão do GKE anterior a 1.32.2-gke.1652000.
• Um balanceador de carga de aplicativo externo criado para uma Entrada do GKE externa, usando o controlador de Entrada do GKE, mas não usando balanceamento de carga nativo de contêiner.

Como as VMs de nós não podem ser membros de mais de um grupo de instâncias de carga balanceada, o GKE não pode criar e gerenciar balanceadores de carga de rede de passagem interna, de passagem externa com base em serviço de back-end e os aplicativos externos Balanceadores de carga criados para recursos de Entrada do GKE se uma das seguintes condições for true:

• Fora do GKE, você criou pelo menos um balanceador de carga baseado em serviço de back-end e usou os grupos de instâncias gerenciadas do cluster como back-ends para o serviço de back-end do balanceador de carga.
• Fora do GKE, você cria um grupo personalizado de instâncias não gerenciadas que contém alguns ou todos os nós do cluster e, em seguida, anexa esse grupo personalizado a um serviço de back-end para um balanceador de carga.

Para contornar essa limitação, instrua o GKE a usar back-ends de NEG:

• Crie serviços LoadBalancer que usam NEGs GCE_VM_IP. Para mais informações, consulte Agrupamento de nós.
• Configure recursos externos do Ingress do GKE para usar o balanceamento de carga nativo do contêiner. Para mais informações, consulte Balanceamento de carga nativo do contêiner do GKE.

Verificações de integridade do balanceador de carga

Todos os serviços do GKE LoadBalancer implementam uma verificação de integridade do balanceador de carga. O sistema de verificação de integridade do balanceador de carga opera fora do cluster e é diferente de uma sondagem de prontidão, atividade ou inicialização do pod.

Os pacotes de verificação de integridade do balanceador de carga são respondidos pelo software kube-proxy (plano de dados legado) ou cilium-agent (GKE Dataplane V2) em execução em cada nó. As verificações de integridade do balanceador de carga para serviços LoadBalancer não podem ser respondidas por pods.

O externalTrafficPolicy do serviço determina quais nós passam na verificação de integridade do balanceador de carga. Para mais informações sobre como o balanceador de carga usa informações de verificação de integridade, consulte Distribuição de tráfego.

externalTrafficPolicy	Quais nós passam na verificação de integridade	Qual porta é usada
Cluster	Todos os nós do cluster passam na verificação de integridade, incluindo aqueles sem pods de exibição. Se houver pelo menos um pod de exibição em um nó, ele vai passar na verificação de integridade do balanceador de carga, seja qual for o estado do pod.	A porta de verificação de integridade do balanceador de carga precisa ser a porta TCP 10256. Ela não pode ser personalizada.
Local	A verificação de integridade do balanceador de carga considera um nó íntegro se houver pelo menos um pod de exibição pronto e não encerrado nele, independente do estado de outros pods. Nós sem um pod de exibição, nós com pods de exibição que falham em sondagens de prontidão e nós com pods de exibição em encerramento são reprovados na verificação de integridade do balanceador de carga. Durante as transições de estado, um nó ainda passa na verificação de integridade do balanceador de carga até que o limite não íntegro da verificação de integridade do balanceador de carga seja atingido. O estado de transição ocorre quando todos os pods de exibição em um nó começam a falhar nas sondagens de prontidão ou quando todos os pods de exibição em um nó estão sendo encerrados. O modo como o pacote é processado nesta situação depende da versão do GKE. Para mais detalhes, consulte a próxima seção, Processamento de pacotes.	O plano de controle do Kubernetes atribui a porta de verificação de integridade do intervalo de portas do nó, a menos que você especifique uma porta de verificação de integridade personalizada.

Quando o balanceamento de carga ponderado está ativado, o balanceador usa informações de integridade e peso para identificar o conjunto de back-ends de nós qualificados. Para mais informações, consulte Efeito do balanceamento de carga ponderado.

Quando a afinidade zonal está ativada, o balanceador de carga pode refinar o conjunto de back-ends de nós qualificados. Para mais informações, consulte Efeito da afinidade zonal.

Processamento de pacotes

As seções a seguir detalham como o balanceador de carga e os nós do cluster trabalham juntos para rotear pacotes recebidos para os serviços LoadBalancer.

Balanceamento de carga de passagem

Os balanceadores de carga de rede de passagem encaminham pacotes para a interface nic0 dos nós do cluster do GKE. Cada pacote com carga balanceada recebido em um nó tem as seguintes características:

• O endereço IP de destino do pacote corresponde ao endereço IP da regra de encaminhamento do balanceador de carga.
• O protocolo e a porta de destino do pacote correspondem a estes dois protocolos:
  • um protocolo e uma porta especificados em spec.ports[] do manifesto do serviço
  • um protocolo e uma porta configurados na regra de encaminhamento do balanceador de carga

Conversão de endereços de rede de destino nos nós

Depois que o nó recebe o pacote, ele realiza esse processamento extra. Em clusters do GKE que usam o plano de dados legado, os nós usam iptables para processar pacotes com balanceamento de carga. Em clusters do GKE com o GKE Dataplane V2 ativado, os nós usam eBPF. O processamento de pacotes no nível do nó sempre inclui as seguintes ações:

• O nó executa a conversão de endereços de rede de destino (DNAT, na sigla em inglês) no pacote, definindo o endereço IP de destino como um endereço IP do pod de exibição.
• O nó altera a porta de destino do pacote para targetPort do spec.ports[] do serviço correspondente.

Conversão de endereços de rede de origem e roteamento em nós

A tabela a seguir mostra a relação entre externalTrafficPolicy e se o nó que recebeu pacotes balanceados por carga executa a conversão de endereços de rede de origem (SNAT) antes de enviar os pacotes balanceados por carga para um pod:

externalTrafficPolicy	Comportamento de SNAT
Cluster	Em clusters do GKE que usam o plano de dados legados, cada nó que recebeu pacotes balanceados por carga sempre muda o endereço IP de origem desses pacotes para corresponder ao endereço IP do nó, seja o nó roteando os pacotes para um pod local ou um pod em um nó diferente. Em clusters do GKE que usam o GKE Dataplane V2, cada nó que recebeu pacotes balanceados por carga muda o endereço IP de origem desses pacotes para corresponder ao endereço IP do nó somente se o nó de recebimento rotear os pacotes para um pod em um nó diferente. Se o nó que recebeu pacotes com balanceamento de carga rotear os pacotes para um pod local, o nó não vai mudar o endereço IP de origem desses pacotes.
Local	Cada nó que recebeu pacotes com balanceamento de carga roteia os pacotes exclusivamente para um pod local, e o nó não muda o endereço IP de origem desses pacotes.

A tabela a seguir mostra como externalTrafficPolicy controla o roteamento de pacotes com balanceamento de carga e pacotes de resposta pelos nós:

externalTrafficPolicy	Roteamento de pacotes com balanceamento de carga	Roteamento de pacotes de resposta
Cluster	Este é o comportamento de referência para roteamento de pacotes com balanceamento de carga: Se o nó que recebeu pacotes balanceados por carga não tiver um pod de exibição, pronto e não encerrado, ele vai encaminhar os pacotes para um nó diferente que tenha um pod de exibição, pronto e não encerrado. Se o nó que recebeu pacotes com balanceamento de carga tiver um pod de disponibilização, pronto e não encerrado, ele poderá encaminhar os pacotes para um dos seguintes: Um pod local. Um nó diferente com um pod de veiculação, pronto e não encerrado. Em clusters regionais, se o nó que recebeu pacotes com balanceamento de carga encaminhar pacotes para um nó diferente, a afinidade zonal terá o seguinte efeito: Se a afinidade zonal não estiver ativada, o nó diferente poderá estar em qualquer zona. Se a afinidade zonal estiver ativada, o nó que recebeu pacotes com balanceamento de carga tentará roteá-los para um nó diferente na mesma zona. Se isso não for possível, o nó diferente poderá estar em qualquer zona. Como último recurso, se não houver pods de serviço, prontos e não encerrados para o serviço em todos os nós do cluster, o seguinte vai acontecer: Se a opção "Endpoints de encerramento de proxy" estiver ativada^1, o nó que recebeu pacotes balanceados por carga os roteará para um pod de exibição, mas de encerramento, se possível. Se os endpoints de encerramento de proxy estiverem desativados ou não houver pods em todo o cluster, o nó que recebeu pacotes com balanceamento de carga vai fechar a conexão com uma redefinição de TCP.	Os pacotes de resposta são sempre enviados de um nó usando o retorno direto do servidor: Se o nó com o pod de veiculação não for o nó que recebeu os pacotes correspondentes com balanceamento de carga, o nó de veiculação enviará os pacotes de resposta de volta para o nó de recebimento. Em seguida, o nó de recebimento envia os pacotes de resposta usando o retorno direto do servidor. Se o nó com o pod de veiculação for o mesmo que recebeu os pacotes balanceados por carga, ele enviará os pacotes de resposta usando o retorno direto do servidor.
Local	Este é o comportamento padrão para rotear pacotes com carga balanceada: o nó que recebeu pacotes com carga balanceada geralmente tem um pod de exibição, pronto e não encerrado (porque ter um pod assim é necessário para passar na verificação de integridade do balanceador de carga). O nó roteia pacotes com balanceamento de carga para um pod local. Em clusters regionais, a afinidade zonal não muda o comportamento de base para o roteamento de pacotes com balanceamento de carga. Como último recurso, se não houver pods de serviço, prontos e não encerrados para o serviço no nó que recebeu pacotes balanceados por carga, o seguinte vai acontecer: Se a opção "Terminar endpoints de proxy" estiver ativada^1, o nó que recebeu pacotes balanceados por carga os roteará para um pod de exibição local, mas de encerramento, se possível. Se a opção "Encerrar endpoints de proxy" estiver desativada ou se o nó que recebeu pacotes balanceados por carga não tiver um pod de exibição, ele encerrará a conexão com uma redefinição de TCP.	O nó com o pod de veiculação é sempre o nó que recebeu os pacotes com balanceamento de carga, e esse nó envia os pacotes de resposta usando o retorno direto do servidor.

¹ Os endpoints de encerramento de proxy estão ativados nestas configurações:

• Clusters do GKE que usam o plano de dados legado: GKE versão 1.26 e mais recentes
• Clusters do GKE que usam o GKE Dataplane V2: GKE versão 1.26.4-gke.500 e mais recentes

Preços e cotas

Os preços de rede se aplicam aos pacotes processados por um balanceador de carga. Para mais informações, consulte Preços do Cloud Load Balancing e de regras de encaminhamento. Também é possível estimar as cobranças de faturamento usando a Google Cloud calculadora de preços.

O número de regras de encaminhamento que você pode criar é controlado por cotas do balanceador de carga:

• Os balanceadores de carga de rede de passagem interna usam a cota de serviços de back-end por projeto, a cota de verificações de integridade por projeto e as regras de encaminhamento do balanceador de carga de rede de passagem interna por cota de rede da nuvem privada virtual.
• Os balanceadores de carga de rede de passagem externa baseados em serviço de back-end usam a cota de serviços de back-end por projeto, a cota de verificações de integridade por projeto e a passagem externa de cota de regras de encaminhamento do balanceador de carga de rede.
• Os balanceadores de carga de rede de passagem externa baseados em pool de destino usam a cota de pools de destino por projeto, a cota de verificações de integridade por projeto e a passagem externa de cota de regras de encaminhamento do balanceador de carga de rede.

A seguir

• Saiba mais sobre os parâmetros de serviço LoadBalancer.
• Saiba como configurar um balanceador de carga interno.
• Leia uma visão geral da Entrada para balanceadores de carga de aplicativo.
• Saiba como usar NEGs independentes.
• Saiba mais sobre a API Gateway.