Acerca dos serviços LoadBalancer

Esta página oferece uma vista geral de como o Google Kubernetes Engine (GKE) cria e gere Trusted Cloud by S3NS balanceadores de carga quando aplica um manifesto de serviços do balanceador de carga do Kubernetes. Descreve os tipos de LoadBalancer, os parâmetros de configuração e fornece recomendações de práticas recomendadas.

Antes de ler esta página, certifique-se de que conhece os conceitos de rede do GKE.

Vista geral

Quando cria um LoadBalancer Service, o GKE configura um Trusted Cloud balanceador de carga de passagem cujas características dependem dos parâmetros do manifesto do serviço.

Personalize o seu serviço LoadBalancer

Quando escolher a configuração do serviço LoadBalancer a usar, considere os seguintes aspetos:

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

Tipo de balanceador de carga: interno ou externo

Quando cria um serviço LoadBalancer no GKE, especifica se o balanceador de carga tem um endereço interno ou externo:

• Os serviços External LoadBalancer são implementados através de balanceadores de carga de rede de passagem externos. Os clientes localizados fora da sua rede VPC e as VMs com acesso à Internet podem aceder a um serviço LoadBalancer externo. Trusted Cloud

  Quando cria um serviço LoadBalancer e não especifica nenhuma definição personalizada, é utilizada esta configuração por predefinição.

  Como prática recomendada, quando criar um serviço LoadBalancer externo, inclua a anotação cloud.google.com/l4-rbs: "enabled" no manifesto do serviço. A inclusão desta anotação no manifesto do serviço cria um balanceador de carga de rede de encaminhamento externo baseado em serviços 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 externo de passagem direta baseado em conjunto de destino. A utilização de balanceadores de carga de rede de encaminhamento externo baseados em conjunto de destino já não é recomendada.

• Os serviços Internal LoadBalancer são implementados através de balanceadores de carga de rede de encaminhamento direto internos. Os clientes localizados na mesma rede VPC ou numa rede ligada à rede VPC do cluster podem aceder a um serviço LoadBalancer interno.

  Para criar um serviço LoadBalancer interno:

  • Como prática recomendada, certifique-se de que a subdefinição do GKE está ativada para que o GKE possa agrupar nós de forma eficiente através de GCE_VM_IP grupos de pontos finais de rede (NEGs). A criação de subconjuntos do GKE não é obrigatória, mas é vivamente 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:

• Que nós recebem pacotes do balanceador de carga
• Se os pacotes podem ser encaminhados entre nós no cluster, depois de o equilibrador de carga entregar os pacotes 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 são entregues apenas a um nó com, pelo menos, um pod de serviço pronto e não de terminação, preservando o endereço IP de origem do cliente original. Esta 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 total de nós no cluster varie. Esta opção é necessária para suportar o equilíbrio de carga ponderado.

• 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 publicação varia. Esta opção não preserva os endereços IP de origem do cliente originais e pode adicionar latência porque os pacotes podem ser encaminhados para um pod de serviço noutro nó depois de serem entregues a um nó do equilibrador de carga. Esta opção é incompatível com o equilíbrio de carga ponderado.

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

Balanceamento de carga ponderado

Os serviços de balanceamento de carga externos suportam o balanceamento de carga ponderado, o que permite que os nós com mais Pods de serviço, prontos e não terminados recebam uma proporção maior de novas ligações em comparação com os 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 o artigo Efeito do balanceamento de carga ponderado.

Conforme ilustrado no diagrama, os serviços com o equilíbrio de carga ponderado ativado distribuem novas ligações proporcionalmente ao número de pods prontos em cada nó. Isto garante que os nós com mais pods recebem uma maior parte das novas ligações.

Para usar o equilíbrio de carga ponderado, tem de cumprir todos os seguintes requisitos:

• O cluster do GKE tem de usar a versão 1.31.0-gke.1506000 ou posterior.

• O suplemento HttpLoadBalancing tem de estar ativado para o seu cluster. Este suplemento está ativado por predefinição. Permite que o cluster faça a gestão de balanceadores de carga que usam serviços de back-end.

• Tem de incluir 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 encaminhamento externo baseado em serviço de back-end. Os balanceadores de carga de rede de encaminhamento externo baseados em conjunto de destino não suportam o balanceamento de carga ponderado.

• Tem de incluir a anotação networking.gke.io/weighted-load-balancing: pods-per-node no manifesto do serviço LoadBalancer para ativar a funcionalidade de equilíbrio de carga ponderado.

• O manifesto do serviço LoadBalancer tem de usar externalTrafficPolicy: Local. O GKE não impede a utilização de externalTrafficPolicy: Cluster, mas externalTrafficPolicy: Cluster desativa eficazmente o equilíbrio de carga ponderado porque o pacote pode ser encaminhado, após o equilibrador de carga, para um nó diferente.

Para usar o balanceamento de carga ponderado, consulte o artigo Ative o balanceamento de carga ponderado.

Afinidade zonal

Os serviços de balanceamento de carga interno suportam a afinidade zonal (pré-visualização), que pode encaminhar novas ligações para nós com pods de fornecimento na mesma zona que um cliente. Manter o tráfego numa zona pode minimizar o tráfego entre zonas, o que reduz o custo e a latência.

Para usar a afinidade zonal, consulte o artigo Usar a afinidade zonal. Para mais informações sobre como as configurações do balanceador de carga mudam com a afinidade zonal, incluindo quando pode manter o tráfego numa zona, consulte o artigo Efeito da afinidade zonal. Para mais informações sobre como a afinidade zonal e a externalTrafficPolicy influenciam o encaminhamento de pacotes em VMs de nós, consulte o artigo Tradução de endereços de rede de origem e encaminhamento em nós.

Considerações especiais para serviços LoadBalancer internos

Esta secção descreve a opção de subdefinição do GKE, que é exclusiva dos serviços LoadBalancer internos, e como a subdefinição do GKE interage com o externalTrafficPolicy para influenciar o número máximo de nós com balanceamento de carga.

Subconjuntos do GKE

Prática recomendada:

Ative a subdivisão do GKE para melhorar a escalabilidade dos serviços LoadBalancer internos.

A subdivisão do GKE, também denominada subdivisão do GKE para balanceadores de carga internos de camada 4, é uma opção de configuração ao nível do cluster que melhora a escalabilidade dos balanceadores de carga de rede de encaminhamento interno agrupando os pontos finais dos nós de forma mais eficiente em GCE_VM_IP grupos de pontos finais de rede (NEGs). Os NEGs são usados como back-ends do balanceador de carga.

O diagrama seguinte mostra dois serviços num cluster zonal com três nós. O cluster tem a subdivisão do GKE ativada. Cada serviço tem dois pods. O GKE cria um GCE_VM_IP NEG para cada serviço. Os pontos finais em cada NEG são os nós com os pods de publicação para o serviço respetivo.

Pode ativar a restrição de subconjuntos do GKE quando cria um cluster ou atualiza um cluster existente. Depois de ativado, não pode desativar a subdivisão do GKE. A criação de subconjuntos do GKE requer:

• Versão 1.18.19-gke.1400 ou posterior do GKE e
• O suplemento HttpLoadBalancing está ativado para o cluster. Este suplemento está ativado por predefinição. Permite que o cluster faça a gestão dos balanceadores de carga que usam serviços de back-end.

Número de nós

Um cluster com a subdivisão do GKE desativada pode ter problemas com os serviços LoadBalancer internos se o cluster tiver mais de 250 nós no total (entre todos os conjuntos de nós). Isto acontece porque os equilibradores de carga de rede de encaminhamento interno criados pelo GKE só podem distribuir pacotes a 250 ou menos VMs de nós de back-end. Esta limitação existe pelos seguintes dois motivos:

• O GKE não usa a divisão em subconjuntos do back-end do balanceador de carga.
• Um balanceador de carga de encaminhamento interno está limitado à distribuição de pacotes a 250 ou menos back-ends quando a subdivisão do back-end do balanceador de carga está desativada.

Um cluster com subconjuntos do GKE suporta serviços LoadBalancer internos em clusters com mais de 250 nós no total.

• Um serviço LoadBalancer interno que use externalTrafficPolicy: Local num cluster com a subdivisão do GKE ativada suporta até 250 nós com Pods de publicação a suportar este serviço.

• Um serviço LoadBalancer interno que usa externalTrafficPolicy: Cluster num cluster que tem a subdivisão do GKE ativada não impõe nenhuma limitação ao número de nós com Pods de serviço, porque o GKE não configura mais de 25 pontos finais de nós em NEGs GCE_VM_IP. Para mais informações, consulte o artigo Associação de nós a back-ends de GCE_VM_IPNEG.

Distribuição de tráfego

Por predefinição, os serviços LoadBalancer internos e externos criam balanceadores de carga de rede de passagem com afinidade de sessão definida como NONE. Os balanceadores de carga de rede de passagem usam a afinidade de sessão, as informações de funcionamento e, em determinadas circunstâncias, detalhes como o peso para identificar e selecionar um back-end de nó elegível para uma nova ligação.

As novas ligações criam entradas na tabela de acompanhamento de ligações, que são usadas para encaminhar rapidamente pacotes subsequentes para a ligação ao back-end do nó elegível selecionado anteriormente. Para mais informações sobre como os balanceadores de carga de rede de passagem identificam e selecionam back-ends elegíveis, e usam o acompanhamento de ligações, consulte o seguinte:

• Distribuição de tráfego para balanceadores de carga de rede de encaminhamento interno

• Distribuição de tráfego para equilibradores de carga de rede de encaminhamento externo

Efeito do balanceamento de carga ponderado

Quando 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 encaminhamento externo correspondente. O GKE configura o software kube-proxy ou cilium-agent para incluir um cabeçalho de resposta na resposta à verificação do estado do balanceador de carga. Este cabeçalho de resposta define uma ponderação proporcional ao número de agrupamentos de publicação, prontos e não terminados 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 elegíveis do balanceador de carga consiste em todos os nós com estado de funcionamento, com peso diferente de zero.

• O balanceador de carga tem em conta o peso quando seleciona um dos back-ends de nós elegíveis. Quando o serviço usa externalTrafficPolicy: Local (necessário para que o equilíbrio de carga ponderado seja eficaz), é mais provável que seja selecionado um back-end de nó elegível que tenha mais Pods de publicação, prontos e não terminados do que um back-end de nó elegível com menos Pods.

Efeito da afinidade zonal

Quando configura a afinidade zonal para um serviço de balanceador de carga interno, o GKE configura o balanceador de carga de rede de encaminhamento interno correspondente com a opção ZONAL_AFFINITY_SPILL_CROSS_ZONE e uma taxa de transbordo zero.

Com esta configuração de afinidade zonal, o equilibrador de carga restringe o conjunto original de back-ends de nós elegíveis apenas aos back-ends de nós elegíveis que estão na mesma zona que o cliente quando todos os seguintes requisitos são cumpridos:

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

• Pelo menos um back-end de nó elegível e em bom estado está na zona do cliente.

Em todas as outras situações, o balanceador de carga continua a usar o conjunto original de back-ends de nós elegíveis, sem aplicar qualquer otimização de afinidade zonal.

Para mais detalhes sobre como a configuração da afinidade zonal afeta o comportamento do equilibrador 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 os serviços InternalLoadBalancer, a opção GKE subsetting determinam o balanceador de carga resultante e o tipo de back-ends. Trusted Cloud O balanceador de carga e o tipo de back-end determinam como os nós são agrupados em GCE_VM_IP NEGs, grupos de instâncias ou grupos de destino. Em todas as circunstâncias, Trusted Cloud os equilibradores de carga de passagem identificam a interface de rede (NIC) do nó do GKE e não um nó específico nem um endereço IP do pod.

Serviço LoadBalancer do GKE	Balanceador de carga Trusted Cloud resultante	Método de agrupamento de nós
Serviço de balanceamento de carga interno criado num cluster com subdefinição do GKE ativada1	Um Network Load Balancer de passagem interno cujo serviço de back-end usa back-ends de GCE_VM_IP grupos de pontos finais da rede (NEG)	As VMs de nós são agrupadas por zonas em GCE_VM_IP NEGs com base no 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 que nós passam na verificação de funcionamento do equilibrador de carga e o processamento de pacotes.
Serviço de balanceador de carga interno criado num cluster com subdefinição do GKE desativada	Um Network Load Balancer de passagem interno cujo serviço de back-end usa back-ends de grupo de instâncias não gerido zonais	Todas as VMs de nós são colocadas em grupos de instâncias não geridos zonais que o GKE usa como back-ends para o serviço de back-end do Network Load Balancer de passagem interna. O externalTrafficPolicy do serviço controla que nós passam na verificação de funcionamento do balanceador de carga e o processamento de pacotes. Os mesmos grupos de instâncias não geridos são usados para outros serviços de back-end do balanceador de carga criados no cluster devido à limitação de um único grupo de instâncias com balanceamento de carga.
Serviço External LoadBalancer com a anotação cloud.google.com/l4-rbs: "enabled"2 aplicada a um cluster que executa a versão 1.32.2-gke.1652000 ou posterior do GKE4	Um Network Load Balancer de encaminhamento externo baseado em serviços de back-end cujo serviço de back-end usa GCE_VM_IP back-ends de grupos de pontos finais da rede (NEGs)	As VMs de nós são agrupadas por zonas em GCE_VM_IP NEGs com base no 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 que nós passam na verificação de funcionamento do equilibrador de carga e o 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.16520004	Um Network Load Balancer de passagem externo baseado num serviço de back-end cujo serviço de back-end usa back-ends de grupos de instâncias não geridos zonais	Todas as VMs de nós são colocadas em grupos de instâncias não geridos zonais que o GKE usa como back-ends para o serviço de back-end do Network Load Balancer de encaminhamento externo. O externalTrafficPolicy do serviço controla que nós passam na verificação de funcionamento do balanceador de carga e o processamento de pacotes. Os mesmos grupos de instâncias não geridos são usados para outros serviços de back-end do balanceador de carga criados no cluster devido à limitação de um único grupo de instâncias com balanceamento de carga.
Serviço LoadBalancer externo sem a anotação cloud.google.com/l4-rbs: "enabled"3	Um balanceador de carga de rede de encaminhamento externo com base no grupo de destino cujo grupo de destino contém todos os nós do cluster	O conjunto de destinos é uma API antiga que não depende de grupos de instâncias. Todos os nós têm associação direta ao conjunto de destino. O externalTrafficPolicy do serviço controla que nós passam na verificação de funcionamento do balanceador de carga e o processamento de pacotes.

Adesão ao nó em back-ends NEG GCE_VM_IP

Quando a subdivisão do GKE está ativada para um cluster ou foram criados balanceadores de carga de rede de passagem externa com cloud.google.com/l4-rbs: "enabled" na versão 1.32.2-gke.1652000 ou posterior 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 com balanceamento de carga GCE_VM_IP. O externalTrafficPolicy do serviço e o número de nós no cluster determinam que nós são adicionados como pontos finais aos GCE_VM_IP NEGs do serviço.

O painel de controlo do cluster adiciona nós como pontos finais aos 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 seguintes.

Nós no balanceador de carga de rede de encaminhamento interno

externalTrafficPolicy	Número de nós no cluster	Associação de pontos finais
Cluster	1 a 25 nós	O GKE usa todos os nós no cluster como pontos finais para os NEGs do serviço, mesmo que um nó não contenha um pod de publicação para o serviço.
Cluster	mais de 25 nós	O GKE usa um subconjunto aleatório de até 25 nós como pontos finais para os NEGs do serviço, mesmo que um nó não contenha um pod de publicação para o serviço.
Local	qualquer número de nós1	O GKE só usa nós que tenham, pelo menos, um dos pods de publicação do serviço como pontos finais para os NEGs do serviço.

Nós no balanceador de carga de rede de encaminhamento externo

externalTrafficPolicy	Número de nós no cluster	Associação de pontos finais
Cluster	1 a 250 nós	O GKE usa todos os nós no cluster como pontos finais para os NEGs do serviço, mesmo que um nó não contenha um pod de publicação para o serviço.
Cluster	mais de 250 nós	O GKE usa um subconjunto aleatório de até 250 nós como pontos finais para os NEGs do serviço, mesmo que um nó não contenha um pod de publicação para o serviço.
Local	qualquer número de nós1	O GKE só usa nós que tenham, pelo menos, um dos pods de publicação do serviço como pontos finais para os NEGs do serviço.

Limitação do grupo de instâncias com balanceamento de carga único

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

Quando usa back-ends de grupos de instâncias não geridos, o GKE cria ou atualiza grupos de instâncias não geridos que contêm todos os nós de todos os conjuntos de nós em cada zona que o cluster usa. Estes grupos de instâncias não geridos são usados para:

• Balanceadores de carga de rede de encaminhamento interno criados para serviços LoadBalancer internos quando a subdivisão do GKE está desativada.
• Balanceadores de carga de rede de encaminhamento externo baseados em serviços de back-end criados para serviços LoadBalancer externos com a anotação cloud.google.com/l4-rbs: "enabled".
• Balanceadores de carga de aplicações externos criados para recursos de entrada do GKE externos, que usam o controlador de entrada do GKE, mas não usam o balanceamento de carga nativo de contentores.

Uma vez que as VMs de nós não podem ser membros de mais do que um grupo de instâncias com balanceamento de carga, o GKE não pode criar nem gerir balanceadores de carga de rede de encaminhamento interno, balanceadores de carga de rede de encaminhamento externo baseados em serviços de back-end e balanceadores de carga de aplicações externos criados para recursos de entrada do GKE se alguma das seguintes afirmações for verdadeira:

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

Para contornar esta limitação, pode instruir o GKE a usar back-ends de NEG sempre que possível:

• Ative a restrição de subconjuntos do GKE. Como resultado, os novos serviços LoadBalancer internos usam, em alternativa, NEGs GCE_VM_IP.
• Configure recursos de entrada do GKE externos para usar o balanceamento de carga nativo do contentor. Para mais informações, consulte o artigo GKE container-native load balancing.

Verificações de funcionamento do balanceador de carga

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

Os pacotes de verificação do estado do balanceador de carga são respondidos pelo software kube-proxy (dataplane antigo) ou cilium-agent (GKE Dataplane V2) executado em cada nó. Não é possível responder às verificações de estado do balanceador de carga para serviços LoadBalancer por parte dos pods.

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

externalTrafficPolicy	Que nós passam na verificação de funcionamento	Que porta é usada
Cluster	Todos os nós do cluster passam na verificação de estado, incluindo os nós sem publicação de pods. Se existir, pelo menos, um pod de publicação num nó, esse nó passa na verificação de funcionamento do equilibrador de carga, independentemente do estado do respetivo pod.	A porta de verificação de funcionamento do balanceador de carga tem de ser a porta TCP 10256. Não pode ser personalizado.
Local	A verificação do estado do balanceador de carga considera um nó como estando em bom estado se existir, pelo menos, um Pod de publicação pronto e não terminado no nó, independentemente do estado de quaisquer outros Pods. Os nós sem um agrupamento de publicação, os nós cujos agrupamentos de publicação falham todos as sondagens de disponibilidade e os nós cujos agrupamentos de publicação estão todos a terminar falham a verificação de funcionamento do equilibrador de carga. Durante as transições de estado, um nó continua a passar na verificação de estado do equilibrador de carga até que o limite de estado não saudável da verificação de estado do equilibrador de carga seja atingido. O estado de transição ocorre quando todos os pods de publicação num nó começam a falhar as sondagens de disponibilidade ou quando todos os pods de publicação num nó estão a terminar. A forma como o pacote é processado nesta situação depende da versão do GKE. Para mais detalhes, consulte a secção seguinte, Processamento de pacotes.	O plano de controlo do Kubernetes atribui a porta de verificação de funcionamento a partir do intervalo de portas do nó, a menos que especifique uma porta de verificação de funcionamento personalizada.

Quando o equilíbrio de carga ponderado está ativado, o equilibrador de carga usa informações de saúde e de peso para identificar o conjunto de back-ends de nós elegíveis. Para mais informações, consulte o artigo Efeito do equilíbrio de carga ponderado.

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

Processamento de pacotes

As secções seguintes detalham como o balanceador de carga e os nós do cluster funcionam em conjunto para encaminhar pacotes recebidos para 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 balanceamento de carga recebido num nó tem as seguintes caraterí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 ambos os seguintes:
  • 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

Tradução de endereços de rede de destino em nós

Depois de o nó receber o pacote, o nó realiza o processamento adicional de pacotes. Nos clusters do GKE que usam o plano de dados antigo, os nós usam o iptables para processar pacotes com balanceamento de carga. Nos clusters do GKE com o GKE Dataplane V2 ativado, os nós usam o eBPF. O processamento de pacotes ao nível do nó inclui sempre as seguintes ações:

• O nó executa a tradução de endereços de rede de destino (DNAT) no pacote, definindo o respetivo endereço IP de destino como um endereço IP do pod de publicação.
• O nó altera a porta de destino do pacote para o targetPort do spec.ports[] do serviço correspondente.

Tradução de endereços de rede de origem e encaminhamento em nós

A tabela seguinte mostra a relação entre externalTrafficPolicy e se o nó que recebeu pacotes com balanceamento de carga realiza a tradução do endereço de rede de origem (SNAT) antes de enviar os pacotes com balanceamento de carga para um pod:

externalTrafficPolicy	Comportamento de SNAT
Cluster	Nos clusters do GKE que usam o plano de dados antigo, cada nó que recebeu pacotes com balanceamento de carga altera sempre o endereço IP de origem desses pacotes para corresponder ao endereço IP do nó, quer o nó encaminhe os pacotes para um pod local ou um pod num nó diferente. Nos clusters do GKE que usam o GKE Dataplane V2, cada nó que recebeu pacotes com balanceamento de carga altera o endereço IP de origem desses pacotes para corresponder ao endereço IP do nó apenas se o nó de receção encaminhar os pacotes para um pod num nó diferente. Se o nó que recebeu pacotes com balanceamento de carga encaminha os pacotes para um pod local, o nó não altera o endereço IP de origem desses pacotes.
Local	Cada nó que recebeu pacotes com equilíbrio de carga encaminha os pacotes exclusivamente para um pod local, e o nó não altera o endereço IP de origem desses pacotes.

A tabela seguinte mostra como externalTrafficPolicy controla o encaminhamento de pacotes com balanceamento de carga e pacotes de resposta pelos nós:

externalTrafficPolicy	Encaminhamento de pacotes com balanceamento de carga	Encaminhamento de pacotes de resposta
Cluster	Segue-se o comportamento de base para encaminhar pacotes com balanceamento de carga: Se o nó que recebeu pacotes com balanceamento de carga não tiver um pod de publicação, pronto e não de terminação, esse nó encaminha os pacotes para um nó diferente que tenha um pod de publicação, pronto e não de terminação. Se o nó que recebeu pacotes com balanceamento de carga tiver um pod de publicação, pronto e não de terminação, o nó pode encaminhar os pacotes para: Um Pod local. Um nó diferente que tenha um Pod de publicação, pronto e não de terminação. Nos clusters regionais, se o nó que recebeu pacotes com balanceamento de carga encaminhar pacotes para um nó diferente, a afinidade zonal tem o seguinte efeito: Se a afinidade zonal não estiver ativada, o nó diferente pode estar em qualquer zona. Se a afinidade zonal estiver ativada, o nó que recebeu pacotes com balanceamento de carga tenta encaminhá-los para um nó diferente na mesma zona. Se isso não for possível, o nó diferente pode estar em qualquer zona. Como último recurso, se não existirem pods de publicação, prontos e não terminados para o serviço em todos os nós no cluster, ocorre o seguinte: Se a opção Proxy Terminating Endpoints estiver ativada1, o nó que recebeu pacotes com balanceamento de carga encaminha-os para um Pod de publicação, mas termina o Pod, se possível. Se os pontos finais de terminação de proxy estiverem desativados ou não existirem pods em todo o cluster, o nó que recebeu pacotes com balanceamento de carga fecha a ligação com uma reposição de TCP.	Os pacotes de resposta são sempre enviados a partir de um nó através do retorno direto do servidor: Se o nó com o pod de publicação não for o nó que recebeu os pacotes com balanceamento de carga correspondentes, o nó de publicação envia os pacotes de resposta de volta para o nó de receção. Em seguida, o nó de receção envia os pacotes de resposta através do retorno direto do servidor. Se o nó com o pod de publicação for o nó que recebeu os pacotes com balanceamento de carga, esse nó envia os pacotes de resposta através do retorno direto do servidor.
Local	Segue-se o comportamento de base para o encaminhamento de pacotes com balanceamento de carga: o nó que recebeu pacotes com balanceamento de carga tem geralmente um pod de serviço, pronto e não de terminação (porque ter um pod deste tipo é necessário para passar na verificação de funcionamento do balanceador de carga). O nó encaminha os pacotes com balanceamento de carga para um pod local. Nos clusters regionais, a afinidade zonal não altera o comportamento de base para o encaminhamento de pacotes com balanceamento de carga. Como último recurso, se não existirem pods de publicação, prontos e não terminados para o serviço no nó que recebeu pacotes com balanceamento de carga, ocorre o seguinte: Se os pontos finais de terminação de proxy estiverem ativados1, o nó que recebeu pacotes com balanceamento de carga encaminha-os para um serviço local, mas termina o pod, se possível. Se a opção Proxy Terminating Endpoints estiver desativada ou o nó que recebeu pacotes com balanceamento de carga não tiver nenhum pod de publicação, esse nó fecha a ligação com uma reposição de TCP.	O nó com o agrupamento de publicação é sempre o nó que recebeu os pacotes com balanceamento de carga e esse nó envia os pacotes de resposta através do retorno direto do servidor.

Quotas

O número de regras de encaminhamento que pode criar é controlado pelas quotas do balanceador de carga:

• Os balanceadores de carga de rede de encaminhamento interno usam a quota de serviços de back-end por projeto, a quota de verificações de funcionamento por projeto e a quota de regras de encaminhamento do balanceador de carga de rede de encaminhamento interno por rede de nuvem privada virtual.
• Os balanceadores de carga de rede de encaminhamento externo baseados em serviços de back-end usam a quota de serviços de back-end por projeto, a quota de verificações de funcionamento por projeto e a quota de regras de encaminhamento do balanceador de carga de rede de encaminhamento externo por projeto.
• Os balanceadores de carga de rede de encaminhamento externo baseados em conjunto de destino usam a quota de conjuntos de destino por projeto, a quota de verificações de funcionamento por projeto e a quota de regras de encaminhamento do balanceador de carga de rede de encaminhamento externo por projeto.

O que se segue?

• Saiba mais acerca dos parâmetros do serviço LoadBalancer do GKE.
• Saiba mais sobre os serviços Kubernetes.