Considerations and CCM resource update policies for configuring Service load balancing - Container Service for Kubernetes: Central de Documentação do Alibaba Cloud

Quando você define um Service como Type=LoadBalancer, o ACK Cloud Controller Manager (CCM) cria ou configura um balanceador de carga (Classic Load Balancer ou Network Load Balancer), incluindo a instância, os listeners e os grupos de servidores de backend. Este tópico descreve as considerações para configurar o balanceamento de carga de Service e as políticas de atualização de recursos do CCM.

Considerações

Quais instâncias de SLB são reutilizáveis?

Somente instâncias criadas no console do Server Load Balancer (SLB) são reutilizáveis. Instâncias de SLB criadas automaticamente pelo cloud-controller-manager ou gerenciadas pelo ACK (como a instância do API Server) não são reutilizáveis.
Para reutilizar uma instância de SLB privada, ela deve estar na mesma Virtual Private Cloud (VPC) do cluster. A reutilização entre VPCs aplica-se apenas a instâncias NLB.
O tipo de endereço da instância de SLB reutilizada deve corresponder ao tipo de acesso do Service. Se o Service estiver configurado para Public Access (usando a anotação service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: "internet"), a IP Version da instância de SLB deve ser Public. Se o Service estiver configurado para acesso interno (usando a anotação service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: "intranet"), a IP Version da instância de SLB deve ser Private.
Vários Services não podem usar a mesma porta de listener na mesma instância de SLB.
Ao reutilizar uma instância de SLB entre clusters, garanta que a combinação de namespace e nome do Service seja exclusiva em cada cluster.

Considerações sobre instâncias de SLB gerenciadas pelo CCM

O CCM configura o balanceamento de carga apenas para Services Type=LoadBalancer.

Importante

Se um Service Type=LoadBalancer for alterado para outro tipo, o CCM exclui as configurações do SLB. O Service torna-se inacessível por meio da instância de SLB.

O CCM usa uma API declarativa e pode atualizar a configuração do SLB com base nas alterações do Service. O CCM pode sobrescrever modificações manuais feitas no console do SLB.

Importante

Não modifique as configurações de instâncias de SLB gerenciadas pelo ACK no console do SLB. Você pode perder suas alterações e o Service pode se tornar inacessível.

Não exclua nem modifique o finalizer service.k8s.alibaba/resources ou service.k8s.alibaba/nlb. Isso pode impedir a recuperação correta dos recursos do CLB ou NLB.
No Cloud Controller Manager v2.5.0 ou posterior, especificar uma instância CLB ao criar um Service requer inclusão na lista de permissões. Envie uma solicitação no Quota Center.

Considerações sobre o acesso ao IP externo de um Service LoadBalancer de dentro do cluster

Ao acessar o endereço IP do SLB de um Service LoadBalancer de dentro do cluster, a rede do cluster pode interceptar o tráfego e encaminhá-lo diretamente para o endpoint do Service de backend. Isso depende do tipo de plug-in de rede, da versão do plug-in e da versão do cluster.

Isso contorna a instância externa do SLB e causa falhas nas configurações que dependem dela. Os principais cenários afetados incluem:

externalTrafficPolicy definido como Local: o acesso pode falhar se o tráfego for encaminhado para um nó sem pods de backend.
Proxy Protocol ativado: o serviço de backend não consegue obter o cabeçalho do Proxy Protocol da instância de SLB, o que causa falha no handshake.
Listener HTTP/HTTPS: operações dependentes do SLB, como terminação TLS ou adição de cabeçalhos como X-Forwarded-For, não entram em vigor.

Portanto, para acessar um Service LoadBalancer de dentro de um cluster, siga estas recomendações:

Use o endereço interno do Service no cluster (ClusterIP ou nome DNS, como <service-name>.<namespace>.svc.cluster.local) para garantir uma comunicação estável entre serviços.
Para acessar pelo ponto de entrada do SLB, adicione a anotação service.beta.kubernetes.io/alibaba-cloud-loadbalancer-hostname e use o nome de domínio configurado em vez do endereço IP. Consulte Defina um nome de host para um Service.

Importante
Ao usar este recurso, evite agendar o pod cliente e o pod servidor no mesmo nó. O roteamento assimétrico pode causar falhas de acesso.

Considerações sobre o gerenciamento de balanceamento de carga em grande escala em um único cluster com o CCM

Em clusters grandes, o CCM pode demorar para processar eventos do Service. Os cenários a seguir podem atrasar operações como a criação ou exclusão de instâncias de SLB e a atualização de endpoints de grupos de servidores:

Criação ou exclusão de vários Services LoadBalancer ao mesmo tempo.
Atualização de vários endpoints de Service ao mesmo tempo.
Adição ou exclusão de nós em lotes quando há muitos Services LoadBalancer.

Siga estas práticas:

Antes de alterações em grande escala, avalie a capacidade e faça testes de estresse. Reserve margem de processamento suficiente para evitar interrupções.
Use configurações como hooks readinessGates e preStop para evitar interrupções de tráfego durante as alterações. Consulte Implement zero-downtime rolling deployments.
Ao usar muitos Services LoadBalancer, monitore atentamente os limites de cota de CLB e NLB.
Atualize o cluster e o CCM para as versões mais recentes para obter otimizações em cenários de grande escala.

Substitua a instância de SLB de um Service

Você não pode substituir diretamente a instância de SLB de um Service LoadBalancer existente. Em vez disso, exclua e recrie o Service.

Acesso externo e caminho do tráfego de rede

Ao usar um Service LoadBalancer para expor aplicações externamente, compreender o caminho do tráfego ajuda a dimensionar corretamente a largura de banda e a localizar os dados de monitoramento.

Caminho do tráfego

O caminho da requisição é: Cliente → Internet → Balanceador de carga (CLB/NLB) → Rede interna da Alibaba Cloud → Contêineres/nós de backend. O tráfego entre o balanceador de carga e os nós de backend trafega pela rede interna da Alibaba Cloud, e não pela largura de banda pública dos nós do cluster.

Equívoco comum sobre a largura de banda

Aumentar a largura de banda pública dos nós do ACK não resolve problemas de alta concorrência ou picos de tráfego para serviços expostos externamente, pois o tráfego de negócios não passa pela saída de rede pública do nó. O consumo de largura de banda pública ocorre apenas entre o cliente e o balanceador de carga. Para resolver gargalos de desempenho no acesso externo, ajuste a especificação de largura de banda do balanceador de carga em vez da largura de banda pública do nó.

Monitoramento do tráfego de entrada e saída

Para visualizar o tráfego de entrada e saída de um Service, faça logon no console do CLB ou NLB e verifique os dados de monitoramento na página de monitoramento da instância correspondente. O monitoramento no nível do nó não reflete o throughput real do tráfego do Service exposto externamente.

Métodos e restrições de acesso de fora do cluster

Restrições de acesso ao ClusterIP

Instâncias ECS ou outros recursos fora do cluster na mesma VPC não podem acessar diretamente o ClusterIP de um Service. O ClusterIP é um endereço IP virtual alcançável apenas dentro da rede do cluster. Tentativas de acessar o ClusterIP a partir de uma instância ECS externa falharão.

Método de acesso recomendado: LoadBalancer privado

Para acessar aplicações do cluster a partir de outras instâncias ECS na mesma VPC, crie um Service do tipo LoadBalancer com tipo de endereço intranet. Para isso, adicione a seguinte anotação:

service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: intranet

Isso cria uma instância de SLB privada acessível de dentro da VPC. Use o endereço IP do SLB privado gerado para acessar o Service a partir de instâncias ECS externas.

Instabilidade do IP do pod

Os endereços IP dos pods são atribuídos dinamicamente e mudam quando um pod é reiniciado, o que os torna inadequados como endpoints de acesso fixos. Use um LoadBalancer privado ou um Service NodePort para fornecer um ponto de entrada de acesso estável e persistente para as aplicações do cluster.

Limites de cota

VPC

Cada nó do cluster usa uma entrada na tabela de rotas da VPC. O limite padrão é de 200 entradas. Se o seu cluster ultrapassar 200 nós, faça logon no console do Quota Center e envie uma solicitação.
Consulte Limites e cotas da VPC.

Para consultar as cotas de VPC, consulte o Gerenciamento de cotas da VPC.

Server Load Balancer

O CCM cria uma instância de SLB para cada Service Type=LoadBalancer. A cota padrão é de 60 instâncias CLB e 60 instâncias NLB. Para aumentar essa cota, faça logon no console do Quota Center e envie uma solicitação.
O CCM anexa instâncias ECS ou Elastic Network Interfaces (ENIs) ao grupo de servidores de backend do SLB com base na configuração do Service e cria um grupo de servidores separado por targetPort. Limites de cota:
- Número de servidores de backend: uma instância CLB suporta até 200 servidores de backend; uma instância NLB suporta até 400 servidores baseados em ECS, ENI ou IP. Fórmula da cota: servidores de backend × targetPorts. Para aumentar a cota, faça logon no console do Quota Center e envie uma solicitação com antecedência.
- Anexos de grupos de servidores por instância: você pode anexar uma instância ECS ou ENI a até 50 grupos de servidores de backend CLB e 200 grupos de servidores de backend NLB. Para aumentar esse limite, faça logon no console do Quota Center e envie uma solicitação.
- Cota extra durante atualizações contínuas: o sistema cria novos pods antes de destruir os pods antigos, o que consome cota extra e pode exceder as expectativas. Reserve cota suficiente com antecedência.
O CCM cria listeners com base nas portas do Service. O limite padrão é de 50 listeners por instância CLB ou NLB. Para adicionar mais, faça logon no console do Quota Center e envie uma solicitação.
Consulte Limites do CLB e Limites do NLB.

Consulte as cotas do SLB no Gerenciamento de cotas do Server Load Balancer.

Políticas de atualização de instância de SLB

Especifique uma instância de SLB existente ou deixe o CCM criar uma. As políticas de atualização diferem entre esses dois métodos.

Objeto de recurso	Especificar uma instância de SLB existente	Instância de SLB gerenciada pelo CCM
Server Load Balancer	Defina a anotação: `service.beta.kubernetes.io/alibaba-cloud-loadbalancer-id`. O CCM usa esta instância como balanceador de carga do Service, configura-a com base em outras anotações e cria grupos vServer. Ao excluir o Service, o CCM mantém a instância de SLB especificada.	O CCM cria e configura recursos como a instância de SLB, listeners e grupos vServer com base na configuração do Service. Ao excluir o Service, o CCM exclui a instância de SLB criada automaticamente.
Listener	Defina a anotação: `service.beta.kubernetes.io/alibaba-cloud-loadbalancer-force-override-listeners`: Se definida como `"false"`, o CCM não gerencia nenhuma configuração de listener para a instância de SLB. Se definida como `"true"`, o CCM gerencia os listeners com base na configuração do Service. Se um listener já existir, o CCM o sobrescreve.	O CCM cria e configura a política do listener com base na configuração do Service.
Grupo de servidores de backend	Quando os endpoints de backend do Service ou os nós do cluster mudam, o CCM atualiza os grupos vServer de backend. Terway: por padrão, o CCM anexa os IPs dos pods ao backend do SLB, em vez dos nós ECS. Flannel: a política de atualização do grupo de servidores de backend varia de acordo com o modo do Service. Modo Cluster (`spec.externalTrafficPolicy = Cluster`): por padrão, o CCM anexa todos os nós ao backend do SLB, a menos que o backend esteja configurado com BackendLabel. Importante Cada instância ECS tem limites de quantas instâncias de SLB pode usar. O modo Cluster consome essa cota rapidamente. Quando esgotada, os Services falham na reconciliação. Use o modo Local para resolver isso. Modo Local (`spec.externalTrafficPolicy = Local`): o CCM adiciona ao backend do SLB apenas os nós que executam os pods do Service. Isso reduz o consumo de cota do SLB e preserva os IPs de origem da Camada 4. Flannel: o CCM nunca adiciona nós mestre ao backend do SLB. Flannel: por padrão, o CCM não remove nós drenados (`kubectl drain`) ou não agendáveis (`kubectl cordon`) do backend do SLB. Para removê-los, defina `service.beta.kubernetes.io/alibaba-cloud-loadbalancer-remove-unscheduled-backend` como `on`.

Ative a proteção contra exclusão para um Service

A proteção contra exclusão evita a remoção acidental de Services que envolvem operações de negócios críticas ou dados confidenciais. Você só pode excluir recursos protegidos após desativar manualmente a proteção. Consulte Ative a proteção contra exclusão para um Service.