Container Service for Kubernetes:Container networking FAQ

Índice

Qual é a diferença entre os modos de rede Shared ENI e Exclusive ENI do Terway?

O Terway oferece dois modos principais de rede que determinam como as Elastic Network Interfaces (ENIs) são alocadas aos Pods.

• Modo Shared ENI: Vários Pods em um único nó compartilham um conjunto de ENIs. Este é o modo padrão e o mais eficiente em termos de recursos. Esse modo é obrigatório para os recursos de aceleração de rede do Terway (DataPathv2 ou IPvlan+eBPF).

• Modo Exclusive ENI: Cada Pod recebe sua própria ENI dedicada. Isso proporciona melhor desempenho e isolamento de rede, mas consome significativamente mais recursos de ENI.

Para obter mais informações sobre cada modo, consulte Modo Shared ENI e modo Exclusive ENI.

Como identificar se meu cluster ACK usa o Terway no modo Shared ENI ou Exclusive ENI?

Identifique o modo verificando o nome do DaemonSet do Terway em execução no namespace kube-system.

1. Execute o seguinte comando para listar os DaemonSets do Terway:

2. Identifique o modo com base na saída:

   • Se o DaemonSet tiver o nome terway-eniip, você usa o modo Shared ENI.

   • Se o DaemonSet tiver o nome terway-eni, você usa o modo Exclusive ENI.

Como verificar se o modo Shared ENI do Terway usa DataPathv2 ou IPvlan+eBPF legado para aceleração de rede?

Apenas o modo shared ENI do Terway suporta aceleração de rede (DataPathv2 ou IPvlan+eBPF). O DataPathv2 é uma versão aprimorada do modo de aceleração IPvlan+eBPF. No Terway v1.8.0 e versões posteriores, o DataPathv2 é a única opção de aceleração disponível ao criar um cluster e instalar o plugin Terway.

Verifique o valor de eniip_virtual_type no ConfigMap eni-config no namespace kube-system.

1. Recupere os dados do ConfigMap:

2. Na seção

   • datapathv2: Seu cluster usa a aceleração DataPathv2 atual.

   • ipvlan: Seu cluster usa a aceleração legada IPvlan+eBPF.

   • Se o campo estiver ausente, a aceleração de rede está desativada.

O tráfego ignora o IPVS ao usar os modos de aceleração de rede do Terway (DataPathv2 ou IPvlan+eBPF)?

Sim. Para tráfego de Pod para Service dentro do cluster, os modos de aceleração do Terway ignoram o IPVS.

Com a aceleração ativada (DataPathv2 ou IPvlan+eBPF), o Terway usa eBPF para traduzir endereços de Service para Pod de backend diretamente no kernel. Isso evita as regras IPVS padrão do kube-proxy e a pilha de rede do nó, resultando em menor latência e maior throughput na comunicação de serviços internos ao cluster.

Para obter mais informações sobre fluxos de tráfego, consulte Aceleração de rede.

É possível alterar o plugin de rede CNI em um cluster ACK existente?

Não. Não é possível alterar o plugin de rede CNI (por exemplo, de Flannel para Terway) em um cluster ACK existente.

O plugin de rede é um componente fundamental selecionado durante a criação do cluster. Para trocar de plugin, crie um novo cluster com o plugin CNI desejado e migre suas cargas de trabalho.

Para obter mais informações, consulte Criar um cluster gerenciado ACK.

Por que meus Pods não acessam a Internet após adicionar um novo vSwitch para o Terway no cluster ACK?

Provavelmente o novo vSwitch não possui rota para a Internet. Os Pods que adquirem IPs desse vSwitch falharão ao estabelecer conexões públicas de saída.

Solução

Configure uma regra de Source NAT (SNAT) para o bloco CIDR do novo vSwitch usando um NAT Gateway. Isso permite traduzir o tráfego originado dos Pods nesse vSwitch para um endereço IP público, concedendo acesso à Internet.

Para obter mais informações, consulte Habilitar acesso à Internet para um cluster.

Meus nós estão NotReady após atualizar o cluster para Kubernetes 1.16+. Como corrigir uma incompatibilidade do Flannel?

Esse problema ocorre porque você atualizou manualmente a imagem do Flannel sem atualizar sua configuração CNI para compatibilidade com versões mais recentes do Kubernetes.

Causa

O Kubernetes 1.16 e versões posteriores exigem que a configuração CNI especifique explicitamente um cniVersion. Configurações antigas do Flannel não possuem esse campo, fazendo com que o Kubelet falhe na inicialização da rede e marque o nó como NotReady.

Solução

Adicione o campo cniVersion ao ConfigMap do Flannel.

Etapas

1. Edite o ConfigMap kube-flannel-cfg:

   kubectl edit cm kube-flannel-cfg -n kube-system 

   Nos dados net-conf.json, adicione "cniVersion": "0.3.1" ao objeto de configuração.

   "name": "cb0",   
   "cniVersion":"0.3.1",
   "type": "flannel",

2. Reinicie os pods do Flannel para aplicar a nova configuração:

   kubectl delete pod -n kube-system -l app=flannel

   Os nós devem agora inicializar corretamente a rede e passar para o estado Ready.

Como corrigir problemas de latência de rede logo após o início de um Pod?

Sintoma

Há um atraso perceptível (alguns segundos) antes que um Pod recém-iniciado possa se comunicar na rede.

Causa

Essa latência é frequentemente introduzida pelo mecanismo de aplicação de NetworkPolicy no Terway. Quando um Pod inicia, o agente de políticas precisa de tempo para calcular e aplicar as regras eBPF ou iptables necessárias.

Solução

Se você não utiliza Kubernetes Network Policies, desative o recurso para eliminar essa latência de inicialização.

1. Edite o ConfigMap eni-config do Terway:

   kubectl edit cm -n kube-system eni-config 

   Na seção data.eni_conf, adicione a flag disable_network_policy: "true".

   disable_network_policy: "true"

2. Opcional:Se você não estiver usando a versão mais recente do Terway, atualize-o no console.

   3. Na página Add-ons, clique na aba Networking e, em seguida, clique em Upgrade para o add-on Terway.

   4. Na caixa de diálogo exibida, siga as instruções para concluir a configuração e clique em OK.

3. Reinicie os pods do Terway para aplicar a alteração:

    kubectl delete pod -n kube-system -l app=terway-eniip

Por que meus Pods recebem erros de conexão ao tentar acessar um Service que eles mesmos expõem (hairpinning)?

Esse problema, conhecido como "hairpinning", ocorre quando um Pod tenta acessar um Service que roteia o tráfego de volta para ele mesmo. O comportamento depende do seu plugin de rede.

Causa

Solução recomendada

• Use um Headless Service: Esta é a abordagem mais limpa e confiável. Um Headless Service não possui ClusterIP e não envolve o kube-proxy. O DNS resolve o nome do serviço diretamente para os IPs dos Pods, permitindo que o Pod se conecte a si mesmo através de seu próprio endereço IP, sem loops de rede.

  Para obter mais informações, consulte Headless Services.

• Recrie o cluster e use o plugin de rede Terway. Para obter mais informações, consulte Usar o plugin de rede Terway.

• Modifique a configuração do Flannel e, em seguida, recrie o plugin Flannel e o pod.

Soluções alternativas

• Ative o Hairpin Mode no Flannel (Não Recomendado): É possível ativar o hairpinning manualmente, mas essa configuração pode ser sobrescrita por futuras atualizações de componentes.

1. Edite o ConfigMap kube-flannel-cfg no namespace kube-system.

kubectl edit cm kube-flannel-cfg -n kube-system

2. Adicione hairpinMode: true à seção delegate da configuração CNI.

Exemplo:

cni-conf.json: |
    {
      "name": "cb0",
      "cniVersion":"0.3.1",
      "type": "flannel",
      "delegate": {
        "isDefaultGateway": true,
        "hairpinMode": true
      }
    }

3. Reinicie todos os pods do Flannel e, em seguida, recrie os pods da sua aplicação.

kubectl delete pod -n kube-system -l app=flannel   

• Use o Plugin Terway: O plugin de rede Terway lida com o tráfego hairpin corretamente por padrão. Se este for um requisito crítico, considere criar um novo cluster com o Terway.

Qual é a diferença entre os plugins de rede Terway e Flannel para um cluster Kubernetes ACK?

A escolha do plugin de rede adequado depende dos seus requisitos específicos de recursos e desempenho.

Qual é a maneira correta de planejar a rede para um cluster ACK?

Um planejamento de rede adequado é crucial para evitar exaustão de IPs e conflitos de rede. Antes de criar um cluster, defina três blocos CIDR principais:

1. CIDR da VPC e do vSwitch: Espaço de endereçamento para seus nós ECS. Garanta que seja grande o suficiente para seus nós atuais e futuros.

2. Bloco CIDR de Pod: Espaço de endereçamento para todos os Pods no cluster.

   • Ele não deve se sobrepor ao CIDR da VPC ou a quaisquer redes on-premises conectadas.

   • Escolha um bloco grande o suficiente para acomodar o número máximo de Pods previsto. Um erro comum é escolher um bloco muito pequeno.

3. Bloco CIDR de Service: Espaço de endereçamento para IPs virtuais atribuídos aos Services do Kubernetes.

   • Ele não deve se sobrepor ao CIDR da VPC ou ao CIDR de Pod.

Planeje esses intervalos cuidadosamente com antecedência, pois eles não podem ser alterados após a criação do cluster.

Para obter mais informações, consulte Planejar a rede para um cluster gerenciado ACK.

O ACK suporta hostPort para Pods?

O suporte para hostPort depende do plugin de rede CNI.

• Flannel: Suporta hostPort.

• Terway: Não suporta hostPort.

Em geral, o uso de hostPort é desencorajado no Kubernetes. As maneiras recomendadas de expor um serviço são:

• Service NodePort: Expõe o serviço em uma porta estática no IP de cada nó.

• Service LoadBalancer: Provisiona um balanceador de carga externo na nuvem para rotear o tráfego para o serviço.

Com o Terway, os Pods são acessíveis diretamente dentro da VPC através de seus próprios IPs, tornando o hostPort frequentemente desnecessário para comunicação intra-VPC.

Como identificar o plugin de rede e os vSwitches usados pelo meu cluster?

Encontre essas informações no console ACK.

1. Para encontrar o plugin de rede:

• Faça login no console ACK. No painel de navegação à esquerda, clique em Clusters.

• Clique na aba Basic Information.

• O campo Network Plug-in mostrará Flannel ou Terway.

1. Para encontrar o(s) vSwitch(es) do Nó:

• Acesse Nodes > Node Pools.

• Clique em Details para um node pool.

• O campo Node vSwitch mostra o(s) vSwitch(es) onde os nós estão localizados.

1. Para encontrar o(s) vSwitch(es) de Pod (apenas Terway):

• Acesse Add-ons na página do seu cluster.

• Localize o componente terway-eniip e clique em Configuration.

• O campo PodVswitchId lista o(s) vSwitch(es) usado(s) para alocar IPs de Pod. (Isso não se aplica ao Flannel).

Como visualizar os recursos de nuvem usados pelo meu cluster ACK?

Qual é a maneira correta de modificar a configuração do kube-proxy em um cluster ACK?

Personalize o comportamento do kube-proxy, como seu modo (IPVS/iptables) ou configurações de rastreamento de conexão, editando seu ConfigMap.

Procedimento

1. Identifique o ConfigMap:

   • Para Clusters Gerenciados ACK, edite apenas o kube-proxy-worker.

   • Para Clusters Dedicados ACK, edite tanto o kube-proxy-worker quanto o kube-proxy-master.

2. Edite o ConfigMap:

   Localize o ConfigMap apropriado no namespace kube-system e edite seu YAML. A configuração segue a API padrão KubeProxyConfiguration do Kubernetes. Personalize a configuração com base nesse padrão. Para obter mais informações, consulte Configuração do kube-proxy.

3. Aplique as Alterações:

   Após salvar o ConfigMap, reinicie os pods do kube-proxy para que a nova configuração tenha efeito. O controlador do DaemonSet recriará automaticamente os pods com a configuração atualizada.

Como aumentar o limite de rastreamento de conexões Linux (conntrack) nos meus nós?

# Snippet from kube-proxy config.conf
conntrack:
  maxPerCore: 65536

Como alterar o algoritmo de balanceamento de carga IPVS no kube-proxy?

Como reduzir o tempo limite de sessão UDP no modo IPVS do kube-proxy para corrigir atrasos de DNS?

Quando um backend UDP (como um pod CoreDNS) é removido, o kube-proxy no modo IPVS pode continuar a descartar tráfego para ele durante a duração do tempo limite de sessão UDP (padrão: 300 segundos). Isso pode causar atrasos significativos na resolução de DNS durante rollouts do CoreDNS ou reinicializações de nós.

Solução

Reduza o tempo limite UDP na configuração do kube-proxy.

Para Kubernetes v1.18 e posteriores:

1. Edite o ConfigMap kube-proxy-worker (e kube-proxy-master para clusters dedicados) no namespace kube-system.

2. Adicione ou modifique o campo ipvs.udpTimeout. Um valor de 10s é uma escolha razoável para minimizar o impacto.

3. Reinicie os pods do kube-proxy para aplicar a alteração.

Para Kubernetes v1.16 e anteriores:

Essas versões não suportam o parâmetro udpTimeout. Modifique a configuração diretamente em cada nó usando ipvsadm. Recomenda-se usar uma ferramenta como o OOS (CloudOps Orchestration Service) para executar esse comando em lote em todos os nós do cluster.

# This command sets the TCP, TCP-FIN, and UDP timeouts respectively.
# The third parameter '10' sets the UDP timeout to 10 seconds.
ipvsadm --set 900 120 10

Como solucionar problemas comuns em um cluster dual-stack IPv6?

• Problema: kubectl get pod mostra apenas um endereço IPv4.

  • Solução: Um Pod pode ter vários IPs. Use JSONPath para visualizar todos eles. Um endereço IPv6 deve estar presente na lista podIPs.

• Problema: kubectl get svc mostra apenas um CLUSTER-IP IPv4.

  • Solução: Garanta que o ipFamilyPolicy do Service esteja definido como PreferDualStack ou RequireDualStack. Visualize todos os IPs do cluster com JSONPath:

• Problema: Não consigo acessar meu Pod via endereço IPv6.

  • Causa: A aplicação dentro do contêiner pode não estar escutando no endereço any-address IPv6 (::). Por exemplo, alguns servidores web têm como padrão escutar em 0.0.0.0 (apenas IPv4).

  • Solução: Execute exec no Pod e rode netstat -anp. Verifique a coluna "Local Address". Uma entrada tcp6 ou udp6 escutando em ::: indica que está escutando corretamente em IPv6. Caso contrário, reconfigure sua aplicação.

• Problema: Meu Pod é acessível via IPv6 dentro do cluster, mas não pela internet.

  • Causa: O endereço IPv6 do Pod não tem largura de banda pública configurada.

  • Solução: No console Alibaba Cloud, ative a largura de banda pública para o endereço IPv6 via IPv6 Gateway.

• Problema: Os Pods não conseguem acessar a internet via IPv6.

  • Solução: Para habilitar o acesso de saída à internet via IPv6, você deve ter um IPv6 Gateway configurado para sua VPC e garantir que os Pods tenham endereços IPv6 com largura de banda pública ativada.

Meus Pods estão travados em ContainerCreating com erros "InvalidVSwitchId.IpNotEnough". Como adicionar mais endereços IP?

Esse erro indica que o vSwitch usado pelo Terway para IPs de Pod esgotou os endereços disponíveis. Para resolver isso, expanda o pool de IPs adicionando um novo vSwitch.

Etapas

1. Crie um Novo vSwitch: No console VPC, crie um novo vSwitch na mesma região e zona de disponibilidade daquele que esgotou. Recomenda-se usar um bloco CIDR grande (por exemplo, /19 ou menor) para fornecer amplos endereços IP.

2. Atualize a Configuração do Terway: No console ACK, acesse Add-ons > terway-eniip > Configuration. Adicione o ID do vSwitch recém-criado ao campo PodVswitchId.

3. Reinicie os Pods do Terway: Aplique a configuração reiniciando os pods do DaemonSet do Terway.

4. Verifique: Novos Pods devem agora conseguir iniciar com sucesso adquirindo IPs do novo vSwitch.

Por que meus Pods recebem IPs de um bloco CIDR de vSwitch antigo mesmo após atualizar a configuração do Terway?

Isso acontece porque as Elastic Network Interfaces (ENIs) existentes nos nós ainda estão associadas à configuração antiga do vSwitch. O Terway só aplica as novas configurações de vSwitch quando precisa criar uma nova ENI.

Causa

Se um nó já tiver uma ENI anexada, quaisquer novos Pods nesse nó continuarão a obter IPs do pool dessa ENI existente, ignorando as configurações atualizadas do vSwitch. Isso é comum ao reutilizar nós que faziam parte de um cluster diferente ou após modificar manualmente a configuração do Terway sem reciclar os nós.

Solução

O método mais confiável para impor a nova configuração é rotacionar seus nós.

Etapas para rotacionar um nó

1. Drene e remova: Drene as cargas de trabalho com segurança e remova o nó do cluster.

2. Desanexe ENIs: No console ECS, desanexe manualmente quaisquer ENIs remanescentes da instância removida.

3. Readicione o nó: Adicione a instância de volta ao cluster. Ela iniciará do zero e criará novas ENIs com base na configuração atual do Terway.

Adicionei um novo vSwitch à configuração do Terway, mas meus Pods ainda falham ao obter IP. Por que isso acontece?

Esse problema geralmente ocorre quando os nós atingiram sua cota máxima de anexos de ENI para seu tipo de instância ECS.

Causa

Mesmo que você tenha adicionado um novo vSwitch à configuração do Terway, o Terway não consegue criar uma nova ENI para usá-lo porque o limite de hardware do nó para ENIs anexadas foi atingido. Como as ENIs existentes estão vinculadas aos vSwitches antigos e esgotados, nenhum novo IP pode ser alocado.

Solução

A única maneira de resolver isso é rotacionar os nós afetados para limpar seus anexos de ENI existentes e permitir que novos sejam criados com a configuração atualizada.

Etapas para rotacionar um nó

1. Drene e remova: Drene as cargas de trabalho com segurança e remova o nó do cluster.

2. Desanexe ENIs: Acesse o console ECS e desanexe manualmente todas as ENIs da instância.

3. Readicione o nó: Adicione a instância de volta ao cluster. Ela poderá agora anexar uma nova ENI usando a configuração atualizada do vSwitch.

Como ativar o balanceamento de carga interno no cluster para Services ExternalIP e LoadBalancer em um cluster Terway IPvlan existente?

Esse recurso permite que Pods dentro do cluster acessem services LoadBalancer ou ExternalIP usando seu IP externo, com o tráfego sendo roteado internamente ("hairpinning") em vez de sair do cluster. Ele é ativado por padrão em novos clusters Terway IPvlan (v1.2.0+), mas deve ser ativado manualmente em clusters mais antigos.

Pré-requisitos

• Terway v1.2.0 ou posterior.

• O cluster deve estar configurado no modo IPvlan.

Solução

Ative o recurso editando o ConfigMap eni-config.

Etapas

1. Edite o ConfigMap eni-config no namespace kube-system:

2. Na seção data.eni_conf, adicione a flag in_cluster_loadbalance: "true":

3. Reinicie os pods do Terway para aplicar a alteração:

4. Para verificar, consulte os logs de um novo pod do Terway. Eles devem conter a mensagem enable-in-cluster-loadbalance=true.

Como atribuir Pods a um bloco vSwitch/CIDR específico em um cluster Terway para listas de permissões baseadas em IP?

Force um grupo de Pods a adquirir IPs de um bloco CIDR previsível, o que é útil para listas de permissões com serviços externos como bancos de dados. Isso é alcançado usando o recurso de configuração dinâmica do Terway, que substitui as configurações padrão para nós específicos.

Solução

1. Crie um ConfigMap personalizado do Terway:

   Crie um novo ConfigMap no namespace kube-system (por exemplo, eni-config-fixed) que especifique o vSwitch dedicado para seus Pods permitidos.

   Este exemplo usa vsw-2zem796p76viir02c**** e 10.2.1.0/24.

   apiVersion: v1
   data:
     eni_conf: |
       {
          "vswitches": {"cn-beijing-h":["vsw-2zem796p76viir02c****"]},
          "security_group": "sg-bp19k3sj8dk3dcd7****",
          "security_groups": ["sg-bp1b39sjf3v49c33****","sg-bp1bpdfg35tg****"]
       }
   kind: ConfigMap
   metadata:
     name: eni-config-fixed
     namespace: kube-system
   
                           

2. Configure um Node Pool:

   Crie um novo node pool ou use um existente. Aplique o seguinte rótulo aos seus nós: terway-config: eni-config-fixed.

1. Implante Pods com Node Selector e Toleration:

   Implante sua aplicação com um nodeSelector que corresponda ao rótulo da etapa 2 e uma toleration para a taint.

   apiVersion: apps/v1 # For versions earlier than 1.8.0, use apps/v1beta1.
   kind: Deployment
   metadata:
     name: nginx-fixed
     labels:
       app: nginx-fixed
   spec:
     replicas: 2
     selector:
       matchLabels:
         app: nginx-fixed
     template:
       metadata:
         labels:
           app: nginx-fixed
       spec:
         tolerations:        # Add a toleration.
         - key: "fixed"
           operator: "Equal"
           value: "true"
           effect: "NoSchedule"
         nodeSelector:
           terway-config: eni-config-fixed
         containers:
         - name: nginx
           image: nginx:1.9.0 # Replace with your actual image <image_name:tags>.
           ports:
           - containerPort: 80

   Verificação

   Os Pods implantados neste node pool agora obterão seus IPs exclusivamente do vSwitch vsw-dedicated-for-allowlist. Agora você pode adicionar com segurança o bloco CIDR deste vSwitch à lista de permissões do seu serviço externo.

Em um cluster Flannel, por que meus Pods fazem ping em algumas instâncias ECS, mas não em outras?

Assumindo que suas rotas de VPC estejam configuradas corretamente para a rede overlay do Flannel, esse problema é quase sempre causado por regras de grupo de segurança.

• Causa 1: A instância ECS está na mesma VPC, mas em um grupo de segurança diferente.

  • Solução: Adicione uma regra de entrada ao grupo de segurança da instância ECS de destino que permita tráfego do intervalo de IPs de origem dos nós do seu cluster. Para uma solução mais robusta, permita tráfego do bloco CIDR de Pod do cluster.

• Causa 2: A instância ECS está em uma VPC diferente.

  • Solução: Os Pods devem acessar a instância ECS via seu endereço IP público. Adicione uma regra de entrada ao grupo de segurança da instância ECS que permita tráfego do endereço IP de saída pública do seu cluster (por exemplo, o IP do seu NAT Gateway).

Por que os nós recém-adicionados no cluster Flannel recebem uma taint NodeNetworkUnavailable?

Essa taint indica que a rede do nó ainda não está pronta para Pods. O cloud-controller-manager (CCM) é responsável por configurar as rotas necessárias da VPC e remover essa taint. Se ela persistir, o CCM está falhando.

Causas comuns

1. Tabela de rotas da VPC cheia: A tabela de rotas da VPC atingiu sua cota e o CCM não consegue adicionar uma nova rota para o bloco CIDR de Pod do novo nó.

2. Múltiplas tabelas de rotas na VPC: Sua VPC usa múltiplas tabelas de rotas, mas o CCM não está configurado para gerenciá-las. Por padrão, ele interage apenas com a tabela de rotas principal da VPC.

Solução

1. Inspecione os eventos do nó em busca de mensagens de erro do CCM:

2. Se a tabela de rotas estiver cheia, exclua rotas não utilizadas para liberar espaço.

3. Se você usar múltiplas tabelas de rotas, configure o CCM para reconhecer todos os IDs de tabela de rotas relevantes. Consulte a documentação do ACK sobre Usar múltiplas tabelas de rotas em uma VPC.

Por que meus Pods falham ao iniciar com o erro failed to allocate for range 0: no IP addresses available in range set?

Esse erro significa que o nó esgotou sua sub-rede designada de endereços IP para Pods. Isso é tipicamente causado por um vazamento de endereços IP, onde os IPs não são liberados corretamente após a exclusão dos Pods.

Causas comuns de vazamentos de IP

• Versões antigas do Kubernetes (< 1.20): Em versões mais antigas, reinicializações rápidas de Pods ou Pods de CronJob de curta duração podem levar a vazamentos de IP devido a condições de corrida.

• Versões antigas do Flannel: Em versões que armazenam o banco de dados de alocação de IP em disco (/var/lib/cni/networks/), um desligamento inesperado do nó pode impedir a limpeza, fazendo com que os IPs permaneçam marcados como "alocados".

Solução de longo prazo (recomendada)

1. Atualize o cluster: Atualize seu cluster ACK para Kubernetes 1.20 ou uma versão posterior.

2. Atualize o Flannel e configure tmpfs: Atualize o componente Flannel para uma versão recente. Em seguida, edite o ConfigMap kube-flannel-cfg para configurar o diretório de dados IPAM para usar um sistema de arquivos temporário (/var/run/cni/networks), que é limpo automaticamente na reinicialização. Isso evita vazamentos persistentes. Após a configuração, reinicie os nós.

Solução alternativa temporária (se não puder atualizar imediatamente):

1. Drene o nó afetado.

2. Faça login no nó e execute manualmente um script de limpeza. O script deve comparar os arquivos de alocação de IP em /var/lib/cni/networks/cb0/ com a lista de contêineres em execução (docker ps ou crictl pods) e excluir quaisquer arquivos correspondentes a contêineres inexistentes.

3. Remova o cordão (uncordon) do nó.

Como alterar o CIDR de Pod, CIDR de Service ou IPs por nó em um cluster ACK existente?

Não é possível modificar esses parâmetros fundamentais de rede após a criação de um cluster ACK.

O bloco CIDR de Pod, o bloco CIDR de Service e o tamanho da sub-rede alocada a cada nó (no Flannel) são definidos na criação do cluster. Alterá-los exigiria uma reconfiguração completa da rede e roteamento do cluster, o que não é uma operação suportada. Se precisar alterar esses valores, crie um novo cluster com o plano de rede correto.

Quando configurar o cloud-controller-manager (CCM) para múltiplas tabelas de rotas em um cluster Flannel?

Configure o CCM para gerenciar múltiplas tabelas de rotas em um cluster Flannel nos seguintes cenários:

• Cenário 1: Uso de tabelas de rotas personalizadas

  Se os nós do seu cluster residirem em sub-redes associadas a uma tabela de rotas personalizada (não a principal), o CCM falhará ao adicionar rotas para CIDRs de Pod, a menos que seja explicitamente configurado com o ID dessa tabela de rotas personalizada.

• Cenário 2: Logs do CCM mostram erro multiple route tables found

  Essa mensagem de erro declara explicitamente que o CCM detectou mais de uma tabela de rotas na VPC e não sabe qual usar para gerenciar rotas de rede de Pod.

• Cenário 3: Taint NodeNetworkUnavailable persistente em novos nós

  Se novos nós ficarem consistentemente travados com essa taint, é um forte indicador de que o CCM não consegue configurar suas rotas, muitas vezes devido a uma tabela de rotas personalizada não configurada.

É possível instalar um plugin de rede CNI de terceiros em um cluster ACK?

Não. Clusters ACK não suportam a instalação ou configuração de plugins de rede de terceiros.

O ACK é profundamente integrado aos seus plugins CNI fornecidos (Terway e Flannel) para gerenciar roteamento VPC, ENIs e outros recursos de nuvem. Tentar instalar outro plugin CNI (como Calico ou Cilium) manualmente entrará em conflito com o sistema gerenciado e provavelmente causará uma falha completa de rede no seu cluster.

Por que recebo o erro no IP addresses available in range set no meu cluster Flannel?

Esse erro significa que um nó não tem mais endereços IP para atribuir a novos Pods de sua sub-rede CIDR de Pod designada.

Causa

Este é um limite rígido. Em um cluster Flannel, o bloco CIDR total de Pod é dividido em sub-redes menores, e uma sub-rede é atribuída a cada nó. Uma vez que a sub-rede de um nó está cheia, ele não pode criar mais Pods. Esse problema surge de um planejamento de rede inadequado.

Solução

• Curto prazo: Exclua Pods não utilizados no nó afetado para liberar IPs. Você também pode adicionar um novo nó ao cluster, que receberá sua própria sub-rede nova de IPs.

• Longo prazo: A única correção permanente é recriar o cluster com um bloco CIDR de Pod maior. Planeje sua rede cuidadosamente para alocar endereços IP suficientes para o número esperado de nós e pods por nó.

O que determina o número máximo de Pods por nó em um cluster Terway?

O número máximo de Pods por nó em um cluster Terway é determinado pela capacidade de IP do tipo de instância ECS subjacente.

O Terway atribui IPs de ENIs anexadas ao nó. Cada tipo de instância ECS tem um limite específico para:

1. O número máximo de ENIs que pode anexar.

2. O número máximo de endereços IP privados por ENI.

O número total de IPs disponíveis (e, portanto, de Pods) é calculado como (Número de ENIs) × (IPs por ENI). Encontre esses limites na documentação do Alibaba Cloud ECS para seu tipo de instância específico.

O que é o modo DataPath V2 do Terway e qual a diferença para o modo IPvlan original?

• DataPath V2 é o plano de dados de próxima geração para o recurso de aceleração de rede do Terway, servindo como uma melhoria ao modo IPvlan+eBPF original.

  Pontos principais

  • Padrão para novos clusters: Para clusters criados com Terway v1.8.0 ou posterior onde a aceleração IPvlan está ativada, o DataPath V2 é usado por padrão.

  • Compatibilidade retroativa: Clusters existentes que já usavam o modo IPvlan legado continuarão a usá-lo mesmo após atualizar o componente Terway. O plano de dados não é migrado automaticamente para evitar interrupções.

  • Benefícios: O DataPath V2 oferece compatibilidade e desempenho aprimorados em relação à implementação original.

O que significam os diferentes status de Pod, como Pending e ContainerCreating, no contexto de rede do Terway?

Ao observar o status de um Pod, você entende o progresso de sua inicialização de rede em um ambiente Terway.

• Pending: O agendador ainda não atribuiu o Pod a um nó. Isso geralmente ocorre devido a restrições de recursos (CPU, memória) ou regras de agendamento (taints, afinidade). O Terway ainda não está envolvido nesta fase.

• ContainerCreating: O Pod foi agendado para um nó e o Kubelet instruiu o runtime de contêineres a criá-lo. Para o Terway, esta é a fase ativa onde o plugin CNI está configurando a rede do Pod. Isso inclui anexar uma ENI (se necessário) e atribuir um endereço IP privado. Atrasos ou falhas neste estado frequentemente apontam para problemas de recursos de rede, como falta de IPs disponíveis no vSwitch.

• Running: Todos os contêineres no Pod foram criados e o Terway configurou sua rede com sucesso. O Pod deve estar operacional e acessível.

Inspecione o status detalhado e os eventos de um Pod usando kubectl describe pod <pod-name>.

Por que a atualização do componente Terway falhou com o erro eip pool is not supported?

Esse erro ocorre porque o recurso de pool EIP (Elastic IP) foi descontinuado e removido das versões recentes do componente Terway.

Solução

Antes de atualizar o Terway, migre o gerenciamento de EIP do Terway para o componente ack-extend-network-controller. Este controlador agora é responsável por lidar com atribuições de EIP para Pods. Siga a documentação oficial da Alibaba Cloud para migrar sua configuração.

Por que meus Pods às vezes falham na criação em um cluster Terway com o erro can't found dev by mac?

Esse erro, failed to do add; error parse config, can't found dev by mac..., significa que o plugin CNI Terway não conseguiu encontrar a interface de rede (ENI) no nó que corresponde ao endereço MAC esperado.

Existem duas causas comuns:

1. Anexo assíncrono de ENI (problema transitório):

   • Explicação: Quando uma nova ENI é anexada a uma instância ECS, pode haver um leve atraso antes que o dispositivo de rede seja totalmente inicializado no sistema operacional. Se o plugin CNI tentar configurar a rede durante essa breve janela, ele falhará ao encontrar o dispositivo.

   • Solução: Geralmente é um problema temporário de sincronismo. O plugin CNI é projetado para tentar novamente automaticamente. Na maioria dos casos, terá sucesso em uma tentativa subsequente e o Pod eventualmente iniciará. Se o Pod tornar-se Running, ignore com segurança esses erros transitórios nos logs.

2. Falha no driver do nó (problema persistente):

   • Explicação: Se o erro persistir e o Pod nunca iniciar, pode indicar um problema mais sério. O driver subjacente no nó pode ter falhado ao inicializar a ENI corretamente, o que pode acontecer se a instância ECS tiver memória de ordem alta insuficiente no momento do anexo.

   • Solução: Reiniciar a instância ECS afetada geralmente resolve essa falha no nível do driver.

O que considerar ao configurar um Cluster Domain personalizado para meu cluster ACK?

O Cluster Domain (padrão: cluster.local) é o sufixo DNS para todos os serviços internos ao cluster. Se você personalizá-lo durante a criação do cluster, siga estas regras para evitar conflitos de resolução de DNS.

• Não pode ser alterado: O Cluster Domain só pode ser definido no momento da criação do cluster e não pode ser modificado posteriormente.

• Deve ser único: O Cluster Domain não deve se sobrepor a nenhum domínio público externo ou zonas DNS privadas que você utilize (por exemplo, no Alibaba Cloud DNS PrivateZone).

Por que isso é importante?

O CoreDNS, servidor DNS do cluster, é configurado para lidar internamente com todas as consultas para o Cluster Domain e não as encaminhará para servidores DNS upstream. Isso visa segurança e desempenho.

Se o seu Cluster Domain for, por exemplo, mycompany.com, e você também tiver um site público em www.mycompany.com, seus Pods não conseguirão resolver www.mycompany.com porque o CoreDNS assumirá que mycompany.com é uma zona apenas interna e não encaminhará a consulta. Isso levará a falhas na resolução de DNS para todos os serviços externos sob esse domínio.