Container Service for Kubernetes:Container networking FAQ

Índice

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

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

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

O Terway possui dois modos de alocação de ENI para Pods.

• Modo Shared ENI: Vários Pods compartilham ENIs em cada nó. É o modo padrão e o mais eficiente em termos de recursos. Necessário para aceleração de rede (DataPathv2 ou IPvlan+eBPF).

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

Consulte Use the Terway network plugin.

Como identifico se meu cluster ACK está usando o Terway no modo Shared ENI ou Exclusive ENI?

Como verifico se meu modo Terway Shared ENI está usando DataPathv2 ou o legado IPvlan+eBPF para aceleração de rede?

Apenas o modo Shared ENI suporta network acceleration (DataPathv2 ou IPvlan+eBPF). O DataPathv2 substituiu o IPvlan+eBPF no Terway v1.8.0+; novos clusters utilizam exclusivamente o DataPathv2.

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

1. Execute o seguinte comando para recuperar os dados do ConfigMap eni-config:

   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

2. Na saída, verifique o valor do campo eniip_virtual_type:

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

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 Serviço dentro do cluster, os modos de aceleração do Terway ignoram o IPVS.

Com a aceleração habilitada, o Terway usa eBPF para traduzir endereços de Serviço diretamente para IPs de Pods de backend no kernel, contornando o IPVS do kube-proxy e a pilha de rede do nó para obter menor latência e maior taxa de transferência.

Consulte Terway network plugin.

É 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 é definido na criação do cluster. Para fazer a troca, crie um novo cluster e migre as cargas de trabalho.

Consulte Create an ACK managed cluster.

Por que meus Pods não conseguem acessar a Internet após adicionar uma nova vSwitch para o Terway no meu cluster ACK?

Provavelmente a nova vSwitch não possui uma rota para a Internet, impedindo que Pods que utilizam seus IPs estabeleçam conexões de saída.

Solução

Configure uma regra SNAT para o bloco CIDR da nova vSwitch usando um NAT Gateway para conceder acesso à Internet aos Pods.

Consulte Enable Internet access for a cluster.

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

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

Causa

O Kubernetes 1.16+ exige um cniVersion na configuração CNI. Configurações antigas do Flannel não possuem esse campo, fazendo com que os nós fiquem NotReady.

Solução

Adicione o campo cniVersion ao ConfigMap do Flannel.

Etapas

1. Edite o ConfigMap kube-flannel-cfg:

   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

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

   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

2. Reinicie os pods do Flannel:

   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

   Os nós devem agora passar para o estado Ready.

Como resolvo 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

O mecanismo NetworkPolicy do Terway introduz esse atraso enquanto calcula e aplica regras eBPF ou entradas iptables para o novo Pod.

Solução

Se você não utiliza Network Policies, desabilite o recurso para eliminar esse atraso na inicialização.

1. Edite o ConfigMap eni-config do Terway:

   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

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

   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

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

   1. Faça login no ACK console. No painel de navegação esquerdo, clique em Clusters.

   2. Na página Clusters, clique no nome do seu cluster. No painel de navegação esquerdo, clique em Add-ons .

   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:

   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

Por que meus Pods recebem erros de conexão ao tentar acessar um Serviço que eles próprios expõem (hairpinning)?

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

Causa

Solução recomendada

• Use um Headless Service: Um Headless Service não possui ClusterIP e ignora o kube-proxy. O DNS resolve diretamente para os IPs dos Pods, eliminando loops de rede.

  Consulte Headless Services.

• Recrie o cluster com o Terway network plugin.

• Modifique a configuração do Flannel e recrie o plugin e os pods do Flannel.

Soluções alternativas

• Habilite o Modo Hairpin no Flannel (Não Recomendado): Você pode habilitar o hairpinning manualmente, mas as atualizações podem sobrescrever essa configuração.

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

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

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

Exemplo:

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

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

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

• Use o Plugin Terway: O plugin de rede Terway lida corretamente com o tráfego hairpin por padrão. Se este for um requisito crítico, considere criar um novo cluster com 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 forma correta de planejar a rede de um cluster ACK?

Um planejamento de rede adequado é essencial para evitar o esgotamento de IPs e conflitos de rede. Antes de criar um cluster, você deve definir três blocos CIDR fundamentais:

1. CIDR da VPC e da vSwitch: Este é o espaço de endereçamento para seus nós ECS. Garanta que seja amplo o suficiente para acomodar os nós atuais e futuros.

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

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

   • Dimensione o bloco considerando a quantidade máxima prevista de Pods. Escolher um bloco muito pequeno é um erro comum.

3. Bloco CIDR de Service: Este é o espaço de endereçamento para os IPs virtuais atribuídos aos Services do Kubernetes (ClusterIPs).

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

Planeje esses intervalos com antecedência — eles não podem ser alterados após a criação.

Consulte Plan the network for an ACK managed cluster.

O ACK suporta hostPort para Pods?

O suporte a hostPort depende do plugin de rede CNI utilizado.

• Flannel: Suporta hostPort.

• Terway: Não suporta hostPort.

O uso de hostPort não é recomendado. Alternativas sugeridas:

• 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 por meio de seus próprios IPs, tornando o hostPort desnecessário para comunicação intra-VPC.

Como identifico o plugin de rede e as vSwitches usadas pelo meu cluster?

Verifique no console do ACK.

1. Para encontrar o plugin de rede:

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

• Na página Clusters, clique no nome do seu cluster. No painel de navegação à esquerda, clique em Cluster Information.

• Clique na aba Basic Information.

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

2. Para encontrar a(s) vSwitch(es) de Nó:

• Navegue até Nodes > Node Pools.

• Clique em Details referente a um node pool.

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

3. Para encontrar a(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 a(s) vSwitch(es) usadas para alocação de IPs de Pod. (Isso não se aplica ao Flannel).

Como visualizo os recursos de nuvem utilizados 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 o modo (IPVS/iptables) ou o rastreamento de conexões, editando seu ConfigMap.

Procedimento

1. Identifique o ConfigMap:

   • Para Clusters Gerenciados ACK, basta editar o kube-proxy-worker.

   • Para Clusters Dedicados ACK, é necessário editar tanto o kube-proxy-worker quanto o kube-proxy-master.

2. Edite o ConfigMap:

   Encontre o ConfigMap no namespace kube-system e edite seu YAML. A configuração segue a API padrão KubeProxyConfiguration do Kubernetes. Consulte kube-proxy Configuration.

3. Aplique as alterações:

   Após salvar, reinicie os pods do kube-proxy. O controlador do DaemonSet os recria automaticamente com a configuração atualizada.

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

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

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

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

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

Quando um backend UDP (como o CoreDNS) é removido, o kube-proxy no modo IPVS pode descartar o tráfego destinado a ele por até 300 segundos (tempo limite padrão), causando atrasos de DNS durante rollouts ou reinícios.

Solução

Reduza o tempo limite de 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 impactos.

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

Para Kubernetes v1.16 e anteriores:

Essas versões não possuem suporte a udpTimeout. Modifique a configuração em cada nó via ipvsadm. Utilize o OOS (CloudOps Orchestration Service) para executar comandos em lote.

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

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

• Problema: O comando kubectl get pod exibe apenas um endereço IPv4.

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

• Problema: O comando kubectl get svc exibe apenas um CLUSTER-IP IPv4.

  • Solução: Certifique-se de que o ipFamilyPolicy do Service esteja definido como PreferDualStack ou RequireDualStack. Visualize todos os IPs do cluster usando JSONPath:

• Problema: Não consigo acessar meu Pod pelo 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 escutam por padrão apenas em 0.0.0.0 (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á ouvindo 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 possui largura de banda pública configurada.

  • Solução: No console do Alibaba Cloud, habilite a largura de banda pública para o endereço IPv6 por meio de um 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, é necessário ter um IPv6 Gateway configurado para sua VPC e garantir que os Pods possuam endereços IPv6 com largura de banda pública ativada.

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

A vSwitch usada para IPs de Pod esgotou seus endereços. Adicione uma nova vSwitch para expandir o pool de IPs.

Passos

1. Crie uma nova vSwitch: No console da VPC, crie uma vSwitch na mesma região e AZ. Utilize um bloco CIDR amplo (por exemplo, /19 ou menor).

2. Atualize a configuração do Terway: No console do ACK, acesse Add-ons > terway-eniip > Configuration. Adicione o ID da nova vSwitch criada ao campo PodVswitchId.

3. Reinicie os Pods do Terway: Reinicie os pods do DaemonSet do Terway.

4. Verifique: Novos Pods devem iniciar e obter IPs da nova vSwitch.

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

As ENIs existentes nos nós permanecem vinculadas à vSwitch antiga. O Terway aplica as novas configurações de vSwitch apenas ao criar uma nova ENI.

Causa

Se um nó já possui uma ENI, novos Pods continuam utilizando o pool de IPs dessa ENI, ignorando as configurações atualizadas da vSwitch. Isso ocorre ao reutilizar nós de outro cluster ou após modificar a configuração do Terway sem reciclar os nós.

Solução

Faça a rotação dos nós afetados para impor a nova configuração.

Passos para rotacionar um nó

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

2. Desanexe as ENIs: No console do 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 baseadas na configuração atual do Terway.

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

Esse problema geralmente ocorre quando os nós atingiram a cota máxima de anexação de ENIs para seu tipo de instância ECS.

Causa

Embora a nova vSwitch esteja configurada, o Terway não consegue criar uma nova ENI porque o nó atingiu seu limite físico de anexação de ENIs. As ENIs existentes estão vinculadas a vSwitches esgotadas, impedindo a alocação de novos IPs.

Solução

Realize a rotação dos nós afetados para limpar as anexações de ENI existentes e permitir novas anexações com a configuração atualizada.

Passos para rotacionar um nó

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

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

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

Como habilito o balanceamento de carga intra-cluster para Services ExternalIP e LoadBalancer em um cluster Terway IPvlan existente?

Permite que os Pods acessem serviços LoadBalancer ou ExternalIP via IP externo com tráfego roteado internamente. Habilitado por padrão em novos clusters Terway IPvlan (v1.2.0+), mas requer ativação manual em clusters mais antigos.

Pré-requisitos

• Terway v1.2.0 ou superior.

• O cluster deve estar configurado no modo IPvlan.

Solução

Habilite o recurso editando o ConfigMap eni-config.

Passos

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:

4. Verifique consultando os logs de um novo pod do Terway em busca de enable-in-cluster-loadbalance=true.

Como posso atribuir Pods a uma vSwitch/bloco CIDR específico em um cluster Terway para allowlisting baseado em IP?

Force os Pods a usar um bloco CIDR específico para allowlisting baseado em IP sobrescrevendo as configurações padrão de vSwitch do Terway por node pool.

Solução

1. Crie um ConfigMap personalizado do Terway:

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

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

   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

   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

2. Configure um Node Pool:

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

3. Implante Pods com Node Selector e Toleration:

   Implante sua aplicação com um nodeSelector que corresponda ao label da etapa 2 e uma toleration para o 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 neste node pool obtêm IPs exclusivamente da vSwitch vsw-2zem796p76viir02c****. Adicione o bloco CIDR desta vSwitch à lista de permissões do seu serviço externo.

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

Assumindo que as rotas da sua VPC estejam configuradas corretamente para a rede overlay do Flannel, esse problema é quase sempre causado por regras de security group.

• Causa 1: A instância ECS está na mesma VPC, mas em um security group diferente.

  • Solução: Adicione uma regra de entrada ao security group da instância ECS de destino que permita tráfego proveniente do intervalo de IPs de origem dos nós do seu cluster. Para uma solução mais robusta, permita o 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 por meio de seu endereço IP público. É necessário adicionar uma regra de entrada ao security group da instância ECS que permita tráfego proveniente 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 meu cluster Flannel estão recebendo um taint NodeNetworkUnavailable?

Esse taint indica que a rede do nó não está pronta. O cloud-controller-manager (CCM) configura as rotas da VPC e remove esse taint; sua persistência indica falha no CCM.

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 utiliza várias 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. Caso utilize múltiplas tabelas de rotas, configure o CCM com todos os IDs de tabela de rotas relevantes. Consulte Use multiple route tables in a VPC.

Por que meus Pods não iniciam com o erro failed to allocate for range 0: no IP addresses available in range set?

O nó esgotou a sub-rede de IPs dos Pods. Geralmente, isso ocorre devido a vazamentos de IP, quando endereços não são liberados após a exclusão do Pod.

Causas comuns de vazamento de IP

• Versões antigas do Kubernetes (< 1.20): Reinícios rápidos de Pods ou CronJobs de curta duração podem provocar vazamentos de IP em razão de condições de corrida.

• Versões antigas do Flannel: Versões que armazenam a alocação de IP em disco (/var/lib/cni/networks/) podem deixar IPs marcados como alocados após desligamentos inesperados.

Solução definitiva (recomendada)

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

2. Atualize o Flannel e configure o tmpfs: Atualize o Flannel e edite o ConfigMap kube-flannel-cfg para definir o diretório de dados do IPAM como /var/run/cni/networks (limpo na reinicialização). Reinicie os nós após a configuração.

Solução temporária (caso não seja possível atualizar imediatamente):

1. Drene o nó afetado.

2. Acesse o nó e execute um script de limpeza que compare os arquivos de IP em /var/lib/cni/networks/cb0/ com os containers em execução (docker ps ou crictl pods), removendo as entradas referentes a containers inexistentes.

3. Remova o cordon do nó.

Como alterar o Pod CIDR, Service CIDR ou a quantidade de 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 Pod CIDR, o Service CIDR e o tamanho da sub-rede por nó são definidos no momento da criação do cluster. Para alterá-los, crie um novo cluster com o planejamento de rede adequado.

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

Você deve configurar 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 estiverem em sub-redes associadas a uma tabela de rotas personalizada (e não à tabela principal), o CCM não conseguirá adicionar rotas para os Pod CIDRs, a menos que seja explicitamente configurado com o ID dessa tabela personalizada.

• Cenário 2: Logs do CCM exibem o erro multiple route tables found****

  Essa mensagem de erro indica explicitamente que o CCM detectou mais de uma tabela de rotas na VPC e não sabe qual delas usar para gerenciar as rotas de rede dos Pods.

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

  Se novos nós ficarem consistentemente travados com essa taint, é um forte indício 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, os clusters ACK não suportam a instalação ou configuração de plugins de rede de terceiros.

O ACK possui integração profunda com Terway e Flannel para roteamento VPC e gerenciamento de ENI. A instalação de outro plugin CNI (como Calico ou Cilium) entra em conflito com o sistema gerenciado e causa falhas na rede.

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

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

Causa

Trata-se de um limite rígido. Em um cluster Flannel, o bloco total do Pod CIDR é dividido em sub-redes menores, sendo uma sub-rede atribuída a cada nó. Quando a sub-rede de um nó se enche, ele não consegue criar mais Pods. Esse problema decorre 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 Pod CIDR 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 IPs do tipo de instância ECS subjacente.

O Terway atribui IPs a partir das ENIs conectadas ao nó. Cada tipo de instância ECS possui um limite específico para:

1. O número máximo de ENIs que podem ser anexadas.

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

O total de IPs disponíveis (e, consequentemente, de Pods) é calculado como (Number of ENIs) × (IPs per ENI). Você pode encontrar esses limites na documentação do Alibaba Cloud ECS para o seu tipo de instância específico.

O que é o modo DataPath V2 do Terway e qual a diferença em relação ao modo IPvlan original?

• O DataPath V2 é a próxima geração do plano de dados para o recurso de aceleração de rede do Terway, servindo como uma evolução do 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á habilitada, o DataPath V2 é usado por padrão.

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

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

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

O status do Pod reflete o progresso da inicialização da rede em um ambiente Terway.

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

• ContainerCreating: O Pod foi agendado e o plugin CNI está configurando sua rede (anexando ENI, atribuindo IP). Atrasos aqui frequentemente indicam problemas de recursos de rede, como exaustão de IPs no vSwitch.

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

Inspecione os detalhes com kubectl describe pod <pod-name>.

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

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

Solução

Antes de atualizar, migre o gerenciamento de EIP do Terway para o componente ack-extend-network-controller, que agora lida com as atribuições de EIP aos Pods.

Por que meus Pods às vezes falham ao serem criados em um cluster Terway com o erro can't found dev by mac?

O erro failed to do add; error parse config, can't found dev by mac... significa que o Terway não conseguiu encontrar a ENI correspondente ao endereço MAC esperado no nó.

Existem duas causas comuns:

1. Anexação assíncrona de ENI (problema transitório):

   • Explicação: Uma ENI recém-anexada leva um momento para inicializar no sistema operacional. Se o plugin CNI configurar a rede durante essa janela, ele falhará ao tentar localizar o dispositivo.

   • Solução: Trata-se de um problema temporário de sincronismo. O plugin CNI tenta novamente automaticamente. Se o Pod atingir o status Running, ignore esses erros nos logs.

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

   • Explicação: Se o erro persistir, o driver do nó pode ter falhado ao inicializar a ENI devido à insuficiência de memória de ordem superior.

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

O que devo 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 do cluster. Se você personalizá-lo durante a criação do cluster, deverá seguir 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 sobrepor a nenhum domínio público externo ou zona de DNS privada que você utilize (por exemplo, no Alibaba Cloud DNS PrivateZone).

Por que isso é importante?

O CoreDNS trata todas as consultas do Cluster Domain internamente e não as encaminha para upstream (por motivos de segurança e desempenho).

Se o seu Cluster Domain for mycompany.com e você tiver um site público em www.mycompany.com, os Pods não conseguirão resolver www.mycompany.com porque o CoreDNS trata mycompany.com como uma zona exclusivamente interna e recusa o encaminhamento da consulta.