Como resolver problemas com o kubelet ou o plug-in CNI para o Amazon EKS?

Breve descrição

Para atribuir e executar um endereço IP ao pod no seu nó de processamento com seu plug-in CNI (no site do Kubernetes), você deve ter as seguintes configurações:

• Permissões do AWS Identity and Access Management (IAM), incluindo uma política de CNI vinculada ao perfil do IAM do seu nó de trabalho. Ou permissões do IAM que você fornece por meio de perfis do IAM de contas 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 para o Amazon Elastic Compute Cloud (Amazon EC2), o Amazon Elastic Container Registry (Amazon ECR) e o Amazon Simple Storage Service (Amazon S3).
• Endereços IP disponíveis suficientes na sua sub-rede.
• Um kube-proxy que é executado com êxito para que o pod aws-node avance ao status Pronto.
• A versão kube-proxy e a versão do CNI da VPC que oferecem suporte à versão do Amazon EKS.

Resolução

Verificar se o pod aws-node está no status Em execução em cada nó de processamento

Para verificar se o pod aws-node está no status Em execução em um nó de processamento, execute o seguinte comando:

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

Se a saída do comando mostrar que a contagem de RESTARTS é 0, significa que o pod aws-node está no status Em execução. Experimente as etapas na seção Verificar se a sub-rede tem endereços IP livres suficientes disponíveis.

Se a saída do comando mostrar que a contagem de RESTARTS é maior que 0, verifique se o nó de processamento consegue acessar o endpoint do servidor de API do seu cluster do Amazon EKS. Execute o seguinte comando:

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

Verificar a conectividade com seu cluster Amazon EKS

1.    Verifique se as configurações do grupo de segurança do seu nó de processamento para o Amazon EKS estão definidas corretamente. Para obter mais informações, consulte Considerações e requisitos sobre grupos de segurança do Amazon EKS.

2.    Verifique se as regras da lista de controle de acesso à rede (ACL da rede) do seu nó de processamento para a sua sub-rede permitem a comunicação com o endpoint do servidor de API Amazon EKS.

Importante: permita tráfego de entrada e saída na porta 443.

3.    Verifique se o pod kube-proxy está no status Em execução em cada nó de processamento:

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

4.    Verifique se o nó de processamento consegue acessar endpoints de API para o Amazon EC2, o Amazon ECR e o Amazon S3.

Observação: configure esses serviços por meio de endpoints públicos ou do AWS PrivateLink.

Verificar se a sub-rede tem endereços IP livres suficientes disponíveis

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

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

Observação: AvailableIpAddressCount deve ser maior que 0 para a sub-rede em que os pods são iniciados.

Verificar 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 pod poderá falhar.

Para obter mais informações, consulte Amazon VPC quotas.

Verificar se você está executando a versão estável mais recente do plug-in CNI

Para confirmar que você tem a versão mais recente do plug-in CNI, consulte Updating the Amazon VPC CNI plugin for Kubernetes self-managed add-on.

Para obter mais soluções de problemas, consulte a página de problemas do AWS GitHub e as notas de lançamento do plug-in CNI.

Verificar os logs do plug-in CNI da VPC no nó de processamento

Se você criar um pod, e um endereço IP não for atribuído ao contêiner, receberá o seguinte erro:

failed to assign an IP address to container

Para verificar os logs, acesse o diretório /var/log/aws-routed-eni/ e localize os nomes dos arquivos plugin.log e ipamd.log.

Verifique se seu kubelet extrai as imagens do contêiner do Docker

Se o seu kubelet não extrair as imagens do contêiner do Docker para os contêineres kube-proxy e amazon-k8s-cni, você receberá o seguinte erro:

network plugin is not ready: cni config uninitialized

Verifique se você consegue acessar o endpoint do servidor de API do Amazon EKS a partir do nó de processamento.

Verificar se o valor WARM_PREFIX_TARGET está definido corretamente

Observação: isso apenas será aplicável se a delegação de prefixos estiver ativada. Se a delegação de prefixos estiver ativada, verifique a seguinte mensagem de erro registrada:

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

WARM_PREFIX_TARGET deve estar definida com um valor maior que ou igual a 1. Se estiver definida como 0, você receberá o seguinte erro:

Consulte as variáveis de configuração CNI no site do GitHub para obter mais informações.

Verificar o espaço reservado na sub-rede

Observação: isso apenas será aplicável se a delegação de prefixos estiver ativada. Se a delegação de prefixos estiver ativada, verifique a seguinte mensagem de erro registrada:

InsufficientCidrBlocks

Verifique se você tem blocos CIDR /28 IP (16 IPs) suficientes disponíveis na sub-rede. Todos os 16 IPs devem ser contíguos. Se você não tiver um intervalo /28 de IPs contínuos, receberá o erro InsufficientCidrBlocks.

Para resolver esse erro, crie uma nova sub-rede e inicie os pods de lá. Além disso, 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 Use subnet CIDR reservations.

Atualizações feitas com infraestrutura como código (IaC) são revertidas com conflitos

Se você usa complementos gerenciados do Amazon EKS, os erros de atualização que usam os seguintes serviços são revertidos quando o método de conflito é indefinido:

• AWS Cloud Development Kit (AWS CDK)
• AWS CloudFormation
• eksctl (do site eksctl)

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.

Os nós estão no status NotReady

Quando você tem aws-nodes que não estão no status Em execução, é comum que os nós estejam no status NotReady. Para obter mais informações, consulte Como faço para alterar o status de um nó de NotReady ou de Unknown para Ready?

Desafios da configuração de redes personalizadas

Quando redes personalizadas estão ativas para o CNI da VPC, definições de recursos personalizadas (CRDs) de EniConfig devem definir a sub-rede e os grupos de segurança corretos.

Para verificar se redes personalizadas estão ativas, descreva o pod aws-node no namespace kube-system. Em seguida, veja se a seguinte variável de ambiente está definida como true:

AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG

Se redes personalizadas estiverem ativas, verifique se os CRDs estão configurados corretamente.

kubectl get ENIConfig -A -o yaml

Descreva cada entrada que corresponde ao nome da zona de disponibilidade. Os IDs de sub-rede correspondem ao posicionamento da VPC e do nó de processamento. Os grupos de segurança são acessíveis ou compartilhados com o grupo de segurança do cluster. Para obter mais informações sobre as melhores práticas, consulte os guias de melhores práticas do Amazon EKS no site do GitHub.

---