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

  Quando você cria um serviço LoadBalancer e não especifica nenhuma configuração personalizada, ele usa essa configuração por padrão.

  Como prática recomendada, ao criar um serviço LoadBalancer externo, inclua a anotação cloud.google.com/l4-rbs: "enabled" no manifesto do serviço. Incluir essa anotação no manifesto do serviço cria um balanceador de carga de rede de passagem externa baseado em serviço de back-end.

  Os manifestos do serviço LoadBalancer que omitem a anotação cloud.google.com/l4-rbs: "enabled" criam um balanceador de carga de rede de passagem externa baseado em pool de destino. Não é mais recomendável usar balanceadores de carga de rede de passagem externa baseados em pool de destino.

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

  Para criar um serviço LoadBalancer interno:

  • Como prática recomendada, verifique se a subcriação do GKE está ativada para que o GKE possa agrupar nós de maneira eficiente usando grupos de endpoints de rede (NEGs) GCE_VM_IP. A subconfiguração do GKE não é obrigatória, mas é altamente recomendada.

  • Inclua a anotação networking.gke.io/load-balancer-type: "Internal" no manifesto do serviço.

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 do cliente original é 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 de 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ó. Isso garante que os nós com mais pods recebam uma parte maior das novas conexões.

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

• O complemento HttpLoadBalancing precisa estar ativado para seu cluster. Esse complemento é ativado por padrão. Ele permite que o cluster gerencie balanceadores de carga que usam serviços de back-end.

• Inclua a anotação cloud.google.com/l4-rbs: "enabled" no manifesto do serviço LoadBalancer para que o GKE crie um balanceador de carga de rede de passagem externa baseado em serviço de back-end. Os balanceadores de carga de rede de passagem externa baseados em pool de destino não são compatíveis com o balanceamento de carga ponderado.

• Inclua a anotação networking.gke.io/weighted-load-balancing: pods-per-node no manifesto do serviço LoadBalancer 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. 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 usar a afinidade zonal, consulte Como usar a afinidade zonal. 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 Traduçã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 a opção de subconfiguração do GKE, que é exclusiva 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

Prática recomendada:

Ative a criação de subconjuntos do GKE para melhorar a escalonabilidade dos serviços LoadBalancer internos.

A subconfiguração do GKE, também chamada de subconfiguração do GKE para balanceadores de carga internos da camada 4, é uma opção de configuração em todo o cluster que 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.

É possível ativar a subconfiguração do GKE ao criar ou atualizar um cluster. Depois de ativada, não é possível desativar a criação de subconjuntos do GKE. A subconfiguração do GKE requer:

• GKE versão 1.18.19-gke.1400 ou posterior e
• O complemento HttpLoadBalancing ativado para o cluster. Esse complemento é ativado por padrão. Ele permite que o cluster gerencie balanceadores de carga que usam serviços de back-end.

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.

• Um serviço LoadBalancer interno que usa externalTrafficPolicy: Local em um cluster com a subconfiguração do GKE ativada aceita até 250 nós com pods de exibição que oferecem suporte a esse serviço.

• Um serviço LoadBalancer interno que usa externalTrafficPolicy: Cluster em um cluster com a subconfiguração do GKE ativada não impõe nenhuma limitação ao número de nós com pods de exibição, porque o GKE não configura mais de 25 endpoints de nós em NEGs GCE_VM_IP. Para mais informações, consulte Associação de nós a back-ends de GCE_VM_IP NEG.

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. O balanceador de carga e o tipo de back-end determinam como os nós são agrupados em NEGs GCE_VM_IP, grupos de instâncias ou pools de destino. Em todas as circunstâncias,os balanceadores de carga de passagem Google Cloudidentificam a interface de rede (NIC) do nó do GKE, não um nó específico ou endereço IP do pod.

Serviço LoadBalancer do GKE	Balanceador de carga Google Cloud resultante	Método de agrupamento de nós
Serviço interno LoadBalancer criado em um cluster com a subconfiguração do GKE ativada^1	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 por zona em NEGs de GCE_VM_IP 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.
Serviço interno LoadBalancer criado em um cluster com a subconfiguração do GKE desativada	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ço LoadBalancer externo com a anotação cloud.google.com/l4-rbs: "enabled"^2 aplicada a um cluster que executa o GKE versão 1.32.2-gke.1652000 ou mais recente^4	Um balanceador de carga de rede de passagem externa baseado em serviço de back-end cujo serviço de back-end usa back-ends de grupo de endpoints de rede (NEG) GCE_VM_IP	As VMs de nós são agrupadas por zona em NEGs de GCE_VM_IP 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.
Serviço LoadBalancer externo com a anotação cloud.google.com/l4-rbs: "enabled"^2 aplicada a um cluster que executa uma versão do GKE anterior a 1.32.2-gke.1652000^4	Um balanceador de carga de rede externo de passagem baseada em serviço de back-end cujo serviço de back-end usa back-ends por grupo de instâncias não gerenciadas zonais	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.
Serviço externo do LoadBalancer sem a anotação cloud.google.com/l4-rbs: "enabled"^3	um balanceador de carga de rede externo de passagem baseado no 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 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.

¹ Somente os balanceadores de carga de rede de passagem interna criados após a ativação da subconfiguração do GKE usam NEGs GCE_VM_IP. Todos os serviços LoadBalancer internos criados antes de ativar a subconfiguração do GKE continuam usando back-ends de grupos de instâncias não gerenciadas. Para exemplos e orientações de configuração, consulte Como criar serviços internos do LoadBalancer.

²O GKE não migra automaticamente os serviços LoadBalancer externos atuais de balanceadores de carga de rede de passagem externa baseados em pool de destino para balanceadores de carga de rede de passagem externa baseados em serviço de back-end. Para criar um serviço LoadBalancer externo com a tecnologia de um balanceador de carga de rede baseado em serviço de back-end, inclua a anotação cloud.google.com/l4-rbs: "enabled" no manifesto do serviço no momento da criação.

³A remoção da anotação cloud.google.com/l4-rbs: "enabled" de um serviço LoadBalancer externo com a tecnologia de um balanceador de carga de rede de passagem externa baseado em serviço de back-end não faz com que o GKE crie um destino Passagem externa de carga de rede baseada em pool. Para criar um serviço LoadBalancer externo com a tecnologia de um balanceador de carga de rede de passagem baseado em pool de destino, omita a anotação cloud.google.com/l4-rbs: "enabled" do manifesto do serviço no momento da criação.

⁴O GKE não migra automaticamente os serviços LoadBalancer externos atuais com a tecnologia de 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 criar um serviço LoadBalancer externo com a tecnologia de um balanceador de carga de rede de passagem externa baseado em serviço de back-end que usa back-ends de NEG GCE_VM_IP, inclua a anotação cloud.google.com/l4-rbs: "enabled" no manifesto do serviço e aplique o manifesto a um cluster que executa a versão 1.32.2-gke.1652000 ou mais recente do GKE. 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 a subconfiguração do GKE está ativada em um cluster ou balanceadores de carga de rede de passagem externa com cloud.google.com/l4-rbs: "enabled" foram criados na versão 1.32.2-gke.1652000 ou mais recente do GKE, 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: o NEG GCE_VM_IP é diferente do tipo GCE_VM_IP_PORT de NEG zonal usado para balanceamento de carga de entrada nativo de contêiner. GCE_VM_IP NEGs identificam as interfaces de rede de VMs de nós pelo endereço IP do nó. No entanto, os pacotes têm destinos que correspondem 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 adiciona nós como endpoints aos NEGs GCE_VM_IP de acordo com o valor de externalTrafficPolicy do Serviço e com 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 usados para:

• Balanceadores de carga de rede de passagem interna criados para serviços LoadBalancer internos quando a criação de subconjuntos do GKE está desativada.
• Balanceadores de carga de rede de passagem externa baseados em serviço de back-end criados para serviços LoadBalancer externos com a anotação cloud.google.com/l4-rbs: "enabled".
• Balanceadores de carga de aplicativo externos criados para recursos externos de Entrada do GKE, 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, é possível instruir o GKE a usar back-ends de NEG sempre que possível:

• Ativar o subagrupamento do GKE. Como resultado, os novos serviços internos do LoadBalancer usam NEGs GCE_VM_IP.
• 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 carga balanceada. 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 os pacotes balanceados por 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 do GKE.
• Saiba mais sobre os Serviços do Kubernetes.