Como resolver problemas com o plug-in CNI da Amazon VPC no Amazon EKS?

Resolução

O Amazon EKS exige a atribuição adequada do IP do pod para que o plug-in CNI (Container Network Interface) da Amazon Virtual Private Cloud (Amazon VPC) funcione corretamente. Para resolver problemas com o plug-in CNI da VPC, verifique as seguintes configurações:

• Permissões do AWS Identity and Access Management (AWS IAM), incluindo AmazonEKS_CNI_Policy vinculada aos perfis do IAM do seu nó de processamento. Ou permissões do IAM que você fornece por meio de perfis do IAM de conta de serviço.
• Um endpoint de servidor de API do Amazon EKS que pode ser acessado a partir do nó de processamento.
• Acesso de rede a endpoints de API no Amazon Elastic Compute Cloud (Amazon EC2), Amazon Elastic Container Registry (Amazon ECR) e Amazon Simple Storage Service (Amazon S3).
• Endereços IP disponíveis suficientes nas suas sub-redes.
• Um kube-proxy que é executado com êxito para que o pod aws-node avance para o status Pronto.
• Versão Kube-proxy e versão CNI da VPC compatíveis com a versão do cluster do Amazon EKS.

Conclua as etapas de solução de problemas a seguir para resolver os problemas do plug-in CNI da VPC.

Verifique se o pod aws-node está no estado Em execução

O plug-in CNI da VPC é executado como um pod DaemonSet chamado aws-node no namespace kube-system. Um pod aws-node é executado em cada nó de processamento em seu cluster.

1. Para verificar se o pod aws-node está sendo executado em cada nó de processamento, execute o seguinte comando:

   kubectl get pods -n kube-system -l k8s-app=aws-node -o wide

   Observação: substitua k8s-app=aws-node pelo seu seletor de rótulo.

2. Se a saída do comando mostrar que a contagem de RESTARTS é maior que 0, verifique o status dos contêineres e das mensagens de erro. Execute o seguinte comando describe:

   kubectl describe pod aws-node-pod-name -n kube-system

   Observação: substitua aws-node-pod-name pelo nome do seu pod de nó da AWS.

3. Se o pod aws-node estiver preso no estado ContainerCreating, a saída describe mostrará a seguinte mensagem de erro nos eventos:

   "Error while dialing dial tcp 127.0.0.1:50051: connect: connection refused"

   Conclua as etapas em Por que meu pod do Amazon EKS está preso no estado ContainerCreating com o erro "failed to create pod sandbox"?

4. Para visualizar os logs do pod aws-node, execute os seguintes comandos logs:

   kubectl logs daemonset/aws-node -n kube-system

   -ou-

   kubectl logs aws-node-pod-name -n kube-system

   Observação: substitua aws-node-pod-name pelo nome do seu pod aws-node.

5. Verifique os logs do plug-in CNI da VPC no nó de processamento. Faça login no nó de processamento e, em seguida, vá para o diretório /var/log/aws-routed-eni/. Localize os nomes dos arquivos plugin.log e ipamd.log e, em seguida, verifique os logs nesses arquivos.

6. Verifique se os nós de processamento podem alcançar o endpoint do servidor de API do seu cluster do Amazon EKS. Para fazer login no seu nó de processamento, use o SSH ou o Gerenciador de sessões do AWS Systems Manager e execute o seguinte comando:

   curl -ivk https://eks-api-server-endpoint-url

   Observação: substitua eks-api-server-endpoint-url pelo URL do endpoint do servidor da API do Amazon EKS.

Verifique a versão do CNI da VPC

Verifique se a versão do plug-in CNI da VPC está atualizada e é compatível com a versão do cluster do Amazon EKS.

Para verificar a versão atual do CNI da VPC, execute o seguinte comando:

kubectl describe daemonset aws-node -n kube-system | grep Image | cut -d "/" -f 2

Compare sua versão atual com a versão mais recente disponível nas versões do plug-in CNI da Amazon VPC no site do GitHub.

Se sua versão estiver desatualizada, atualize o plug-in CNI da VPC para a versão mais recente. Para obter mais informações, consulte Atualização do plug-in da CNI da Amazon VPC (complemento do Amazon EKS).

Verifique a configuração e os requisitos da rede

Verifique se as configurações de grupo de segurança e sub-rede do seu cluster do Amazon EKS estão configuradas corretamente.

Verifique as regras do grupo de segurança

Os grupos de segurança devem permitir a conectividade entre o ambiente de gerenciamento e o plano de dados.

Se você usar um grupo de segurança personalizado nos nós de processamento, verifique as portas. As regras mínimas do grupo de nós permitem a entrada 10250 da porta do grupo de segurança do ambiente de gerenciamento e a saída 443 do grupo de segurança do ambiente de gerenciamento. Para obter mais informações, consulte Segurança de rede.

Se o atributo de grupo de segurança do pod estiver ativo, verifique se os limites do seu grupo de segurança foram atingidos. Se você atingir os limites por interface de rede elástica do seu grupo de segurança, a configuração de rede do seu pod pode falhar. Para obter mais informações, consulte Cotas da Amazon VPC.

Para obter mais informações sobre as regras de grupos de segurança necessárias, consulte Exibir os requisitos para grupos de segurança do Amazon EKS em clusters.

Verifique a configuração da sub-rede

Para listar os endereços IP disponíveis em cada sub-rede no ID da Amazon VPC, execute o seguinte comando:

aws ec2 describe-subnets —filters "Name=vpc-id,Values= VPCID" | jq '.Subnets[] | .SubnetId + "=" + "\(.AvailableIpAddressCount)"'

Verifique se as regras da lista de controle de acesso à rede (ACL da rede) do seu nó de processamento nas suas sub-redes permitem a comunicação com o servidor de API do Amazon EKS. Para obter mais informações sobre como configurar ACLs da rede, consulte Controlar o tráfego da sub-rede com listas de controle de acesso à rede.

Verifique se as sub-redes do seu ambiente de gerenciamento têm endereços IP livres suficientes disponíveis. Cada sub-rede do ambiente de gerenciamento deve ter pelo menos seis endereços IP que o Amazon EKS possa usar. No entanto, a AWS recomenda que cada sub-rede tenha pelo menos 16 endereços IP. AvailableIpAddressCount deve ser maior que 0 na sub-rede em que os pods são executados. Para obter mais informações, consulte Requisitos e considerações para sub-redes.

Verifique se o pod kube-proxy está no estado Em execução

O pod kube-proxy deve estar em execução para uma conectividade de rede adequada.

Para verificar se kube-proxy está em execução, execute o seguinte comando:

kubectl get pods -n kube-system -l k8s-app=kube-proxy

Confirme se todos os pods kube-proxy estão no estado Em execução. Se o kube-proxy não estiver em execução, verifique se há erros nos logs do pod:

kubectl logs -n kube-system POD-NAME

Observação: substitua POD-NAME pelo nome do seu pod kube-proxy.

Verifique o valor de WARM_PREFIX_TARGET

Se a delegação de prefixo estiver ativada, verifique a seguinte mensagem de erro no arquivo de log:

"Error: Setting WARM_PREFIX_TARGET = 0 is not supported while WARM_IP_TARGET/MINIMUM_IP_TARGET is not set. Please configure either one of the WARM_{PREFIX/IP}_TARGET or MINIMUM_IP_TARGET env variable"

Para resolver o erro, WARM_PREFIX_TARGET deve estar definido com um valor maior ou igual a 1. Se a delegação de prefixo estiver ativada e WARM_PREFIX_TARGET estiver definido como 0, atualize o valor para pelo menos 1:

kubectl set env daemonset aws-node -n kube-system WARM_PREFIX_TARGET=1

Verifique o espaço reservado na sub-rede

Quando a delegação de prefixo estiver ativada, verifique se suas sub-redes têm blocos CIDR /28 de IP suficientes disponíveis. Todos os 16 endereços IP devem ser contíguos. Se a delegação de prefixo estiver ativada, verifique a seguinte mensagem de erro no arquivo de log:

"InsufficientCidrBlocks"

Para resolver esse erro, crie uma nova sub-rede e execute os pods a partir dela. Use uma reserva CIDR de sub-rede do Amazon EC2 para reservar espaço em uma sub-rede com um prefixo atribuído. Para obter mais informações, consulte Reservas do CIDR da sub-rede.

Verifique a configuração de rede personalizada

Para verificar se a rede personalizada está ativa em seu cluster do Amazon EKS, execute o seguinte comando:

kubectl describe pod -n kube-system $(kubectl get pods -n kube-system -l k8s-app=aws-node -o jsonpath='{.items[0].metadata.name}')

Se essa variável estiver definida como True, a rede personalizada está ativa.

Se a rede personalizada estiver ativa, os CRDs ENIConfig deverão ser configurados corretamente para atender aos requisitos de rede do cluster. Execute o comando a seguir para recuperar uma lista e inspecionar todos os CRDs ENIConfig:

kubectl get ENIConfig -A -o yaml

Para descrever um ENIConfig específico, execute o seguinte comando:

kubectl describe ENIConfig eni-config-name

Observação: substitua Eni-config-name pelo seu nome ENIConfig.

Verifique se cada ENIConfig tem a configuração correta de sub-rede e grupo de segurança para cada Zona de disponibilidade.

Confirme se a sub-rede especificada no ENIConfig corresponde à Zona de disponibilidade dos seus nós de processamento.

Para obter mais informações sobre redes personalizadas, consulte Implementar pods em sub-redes alternativas com rede personalizada.

Configure a resolução de conflitos para evitar reversões

Ao usar o AWS Cloud Development Kit (AWS CDK), o AWS CloudFormation ou o eksctl com complementos gerenciados, defina um método de resolução de conflitos para evitar reversões.

Os métodos corretos são NONE, OVERWRITE ou PRESERVE.

• Se nenhum método for definido, o padrão será NONE. Quando o sistema detecta conflitos, a atualização na pilha do CloudFormation é revertida e nenhuma alteração é feita.
• Para definir a configuração padrão dos complementos, use o método de substituição. Você deve usar OVERWRITE ao migrar de complementos autogerenciados para gerenciados pelo Amazon EKS.
• Use o método PRESERVE ao usar configurações personalizadas definidas, como WARM_IP_TARGET ou redes personalizadas.

Para obter mais informações sobre como definir métodos de resolução de conflitos, consulte Atualizar um complemento do Amazon EKS.