Por que meu pod do Amazon EKS está preso no estado ContainerCreating com o erro "Failed to create pod sandbox"?

Resolução

Pré-requisitos

Identifique qual pod tem um problema. Conclua as etapas a seguir:

1. Execute o comando a seguir para listar os pods em seu cluster e identificá-los no estado ContainerCreating:

   kubectl get pods --all-namespaces -o wide

2. Execute o comando a seguir para recuperar os detalhes sobre cada pod no estado ContainerCreating:

   kubectl describe pod pod-name -n pod-namespace

   Observação: substitua pod-name pelo nome do seu pod e o pod-namespace pelo namespace em que seu pod está localizado.

3. Analise a saída em Eventos para identificar os pods e use as seções a seguir para solucionar seu problema.

Erro "Resource temporarily unavailable"

Se suas configurações de kernel definidas para PID ou arquivos excederem o limite máximo para o sistema operacional (SO), você receberá uma mensagem de erro semelhante à seguinte:

"kubelet, ip-192-168-0-1.us-east-1.compute.internal Failed to create Pod sandbox: rpc error: code = Unknown desc = failed to start sandbox container for Pod "example_pod" Error response from daemon: failed to start shim: fork/exec /usr/bin/containerd-shim: resource temporarily unavailable: unknown"

Para resolver temporariamente o problema, reinicie o nó.

Para solucionar o problema, conclua as etapas a seguir:

1. Reúna os logs do nó do Containerd e do Kubelet.
   No Windows, conecte-se à sua instância. Abra um prompt de comando do PowerShell e, em seguida, use o script do coletor de log do Windows EKS para coletar os logs do nó de processamento. Para obter mais informações, consulte EKS Logs Collector (Windows) (Coletor de logs do EKS (Windows)) no site do GitHub. Execute o seguinte comando:

   Invoke-WebRequest -OutFile eks-log-collector.ps1 https://raw.githubusercontent.com/awslabs/amazon-eks-ami/main/log-collector-script/windows/eks-log-collector.ps1
   .\eks-log-collector.ps1

   No Linux, conecte-se à sua instância. Em seguida, use o script do coletor de log do Linux EKS para coletar os logs do nó de processamento. Para obter mais informações, consulte EKS Logs Collector (Linux) (Coletor de logs do EKS (Linux)) no site do GitHub. Execute o comando a seguir para baixar o script do coletor de log:

   curl -O https://raw.githubusercontent.com/awslabs/amazon-eks-ami/master/log-collector-script/linux/eks-log-collector.sh

2. Em seguida, execute o script baixado:

   sudo bash eks-log-collector.sh

3. Consulte o log do Kubelet para ver as seguintes respostas de erro:
   "kubelet[5267]: runtime: failed to create new OS thread (have 2 already; errno=11)""kubelet[5267]: runtime: may need to increase max user processes (ulimit -u)"

4. Identifique os processos dos zumbis e, em seguida, interrompa os que não são necessários.
   No Windows, abra o Gerenciador de tarefas e clique na guia Detalhes. Verifique os processos que mostram o status Não está respondendo para identificar os processos zumbis.
   No Linux, execute o seguinte comando ps para verificar se há processos zumbis listados no estado Z:

   ps aux | egrep "Z|defunct"

   Para obter mais informações, consulte How to kill Zombie processes on Linux (Como eliminar processos zumbis no Linux) no site do Linux Journal.

Erro "Network plugin cni failed to set up pod network"

Se a Container Network Interface (CNI) não conseguir atribuir um endereço IP ao seu pod recém-criado, é possível receber a seguinte mensagem de erro:

"Network plugin cni failed to set up pod network: add cmd: failed to assign an IP address to container"

Esse erro pode ocorrer por vários motivos, principalmente em três categorias:

Limitações de recursos:

• IPs de sub-rede esgotados
• Limite máximo de conexão ENI atingido

Problemas de configuração:

• Política de CNI do IAM ausente nos nós de processamento
• O pod CNI da VPC (aws-node) não está Em execução
• Versões desatualizadas da CNI da VPC, kube-proxy ou CoreDNS
• Grupos de segurança ou listas de controle de acesso mal configurados

Desafios específicos da arquitetura:

• Desalinhamento da configuração da CNI da VPC com seu caso de uso
• Falta a configuração do OpenID Connect (OIDC)
• Complementos autogerenciados em vez de complementos gerenciados pelo EKS

Para obter etapas detalhadas de solução de problemas, consulte Como resolver problemas com o kubelet ou o plug-in CNI para o Amazon EKS?

É uma prática recomendada fazer o seguinte:

• Use redes personalizadas na CNI da sua VPC, que permite implantar pods em sub-redes alternativas.
• Ative o modo de delegação de prefixo. Para obter mais informações, consulte Modo de prefixo para Windows.
• Use um grupo de segurança para Pods para atribuir grupos de segurança personalizados a vários pods por meio de ENIs de ramificação em um nó de processamento.

Observação: se você fizer alguma alteração na configuração da sua CNI, deve reiniciar os nós afetados para que as alterações entrem em vigor.

Erro "Error while dialing"

Se o pod aws-node não conseguiu se comunicar com o IPAM porque o pod aws-node falhou ao ser executado no nó, você receberá um erro semelhante ao seguinte:

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

O erro ocorre nos seguintes cenários:

CNI da VPC no estado Pendente

Falhas na sonda de atividade ou prontidão podem ocorrer devido a configurações de regras de segurança ou erros de aplicações. O esgotamento de recursos também pode causar atrasos. Normalmente, as falhas podem ocorrer se DISABLE_TCP_EARLY_DEMUX for definido como false com POD_SECURITY_GROUP_ENFORCING_MODE no modo estrito.

Se você usar grupos de segurança por Pods e sondas de atividade ou prontidão, defina DISABLE_TCP_EARLY_DEMUX como true no modo estrito. Isso permite que o kubelet use o TCP para se conectar a Pods em interfaces de rede de ramificação.

Problemas com plug-ins gerenciados pela CNI

O aws-node falha nas sondas quando adicionado como um plug-in gerenciado no Console de gerenciamento da AWS. Isso acontece porque os plug-ins gerenciados substituem a conta de serviço.

Para resolver isso, faça o seguinte:

• Remova o complemento gerenciado do Console de gerenciamento da AWS. Em seguida, recrie-o com o perfil do IAM correto que fornece a política do IAM AmazonEKS_CNI_Policy necessária.
• Edite a conta de serviço aws-node existente para associá-la ao perfil do IAM correto que tenha as permissões de CNI necessárias.
• Se você usar a Identidade de Pods no cluster, crie a Associação de identidade de pods necessária que vincule a conta de serviço aws-node ao perfil do IAM a ser usado pela CNI da VPC.

Recomendações extras:

• Use as versões mais recentes da CNI da VPC (aws-node), kube-proxy e coredns.

Erro "Failed to setup network for sandbox"

Se você usar a delegação Habilitar prefixo em seus pods VPC-CNI (aws-node), pode receber a seguinte mensagem de erro:

"Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox"

Para obter mais detalhes sobre esse problema, verifique os logs do IP Address Management Daemon (IPAMD) em /var/log/aws-routed-eni/ipamd.log no seu nó de processamento.

Mesmo que sua sub-rede tenha endereços IP disponíveis, se a sub-rede não tiver nenhum bloco /28 contíguo de IPs disponíveis, ocorrerá um erro. O erro ocorre quando a fragmentação dos endereços IP secundários existentes se espalha por uma sub-rede. O erro aparece no plug-in CNI da Amazon VPC em logs do Kubernetes ou em seus eventos do CloudTrail no nó de processamento afetado. É possível receber a seguinte mensagem de erro:

"InsufficientCidrBlocks: The specified subnet does not have enough free cidr blocks to satisfy the request"

Para resolver esse erro, conclua uma das seguintes opções:

Crie uma nova sub-rede e, em seguida, execute os pods lá.

-ou-

Use uma Reserva CIDR de sub-rede do Amazon EC2 para reservar espaço em uma sub-rede com uma atribuição de prefixo.

Se você fizer a transição da atribuição de endereço IP para a atribuição de prefixo IP, crie novos grupos de nós. Em seguida, é possível aumentar o número de endereços IP disponíveis em vez de fazer uma substituição gradual dos seus nós existentes.

Se você executar Pods em um nó que tenha endereços IP e prefixos atribuídos, isso poderá causar inconsistência na capacidade do endereço IP anunciado. Esse cenário pode afetar os futuros workloads no nó. Para resolver esse problema, siga as etapas em Atribuir mais endereços IP aos nós do Amazon EKS com prefixos.

Erro "Container image authentication"

Se o runtime do contêiner não tiver as permissões necessárias para extrair uma imagem, você poderá receber uma mensagem de erro semelhante à seguinte:

"pull access denied, repository does not exist or may require authorization: authorization failed: no basic auth credentials"

Para resolver esse erro, verifique o seguinte:

• Analise o perfil do IAM vinculado ao nó de processamento do EKS. Se não houver a política do IAM AmazonEC2ContainerRegistryReadOnly, anexe a política.
• Se você extrair imagens de um repositório do ECR de uma conta cruzada, consulte Como posso permitir que uma conta secundária envie ou extraia imagens nos meus repositórios de imagens do Amazon ECR? Certifique-se de que a política em nível de repositório esteja definida com as permissões adequadas.
• Se você usa endpoints da VPC do ECR para extrair imagens. Em seguida, certifique-se de que o grupo de segurança do endpoint da VPC permita HTTPS de entrada na porta 443 do grupo de segurança do nó do EKS. Para obter mais informações, consulte Amazon ECR interface VPC endpoints (AWS PrivateLink) (Endpoints da VPC de interface do Amazon ECR (AWS PrivateLink)).
• No containerd, a pausa na extração da imagem só é feita durante o bootstrap. Depois disso, a imagem deve ser retida na instância. Não use scripts de limpeza personalizados ou comandos de exclusão manual, como crictl rmi —prune, para remover as imagens de pausa. Deixe o kubelet lidar com a coleta de resíduos (gc), que é executada automaticamente a cada 1-2 minutos. Quando você remove as imagens do contêiner de pausa do containerd, os novos pods não são iniciados. Os pods atuais são executados sem problemas nos nós e os logs do kubelet mostram o erro "Failed to create pod sandbox".

Se você excluiu a imagem do contêiner de pausa do seu nó de processamento do EKS, conclua as seguintes etapas:

1. Para verificar se seu nó de processamento do EKS tem imagens de pausa, execute o seguinte comando:

   ctr -n k8s.io images ls | grep -o "602401143452.dkr.ecr.YOUR-REGION.amazonaws.com/eks/pause:3.10"

   Observação: substitua YOUR-REGION pela sua região da AWS.

   Se o nó de processamento do EKS tiver imagens de pausa, a saída terá a seguinte aparência:

   602401143452.dkr.ecr.aws.example.region.amazonaws.com/eks/pause:3.10
   602401143452.dkr.ecr.aws.example.region.amazonaws.com/eks/pause:3.10

   Para verificar se seu nó de processamento do EKS foi excluído, execute o seguinte comando:

   ctr -n k8s.io images ls | grep -o "localhost/kubernetes/pause:latest"

   Se as imagens forem excluídas, a saída terá a seguinte aparência:

   ctr -n k8s.io images list |grep -i pause

2. Para extrair a imagem e obter o token de autenticação do ECR, execute os seguintes comandos:

   ECR_REGION=YOUR-REGION
   ECR_PASSWORD=$(aws ecr get-login-password --region $ECR_REGION)

   Observação: substitua YOUR-REGION pela sua região da AWS.

3. Extraia a imagem de pausa do ECR. Certifique-se de que você tem a versão correta da imagem de pausa. Se você não tiver certeza da versão da imagem, faça login em qualquer um dos seus nós de processamento e escolha a versão da imagem.

   Por exemplo:

   sudo ctr -n k8s.io image pull --user "AWS:$ECR_PASSWORD" 602401143452.dkr.ecr.aws.example.region.amazonaws.com/eks/pause:<ImageVersion>

   Observação: é possível selecionar a versão mais recente da imagem em Releases (Lançamentos) no site do GitHub.

4. Marque a imagem como localhost para o EKS.

   Por exemplo:

   sudo ctr -n k8s.io image tag 602401143452.dkr.ecr.aws.example.region.amazonaws.com/eks/pause:<ImageVersion> localhost/kubernetes/pause:latest

5. Depois que for feito backup na imagem de pausa, os novos pods estarão ativos e funcionarão sem problemas.

Erro "Container image authentication"

Se o runtime do contêiner não tiver as permissões necessárias para extrair uma imagem, você poderá receber uma mensagem de erro semelhante à seguinte:

"pull access denied, repository does not exist or may require authorization: authorization failed: no basic auth credentials"

Para resolver esse erro, verifique o seguinte:

• Analise o perfil do IAM vinculado ao nó de processamento do EKS. Se estiver faltando a política do IAM AmazonEC2ContainerRegistryReadOnly, anexe essa política.
• Se você extrair imagens de um repositório do ECR de uma conta cruzada, consulte Como posso permitir que uma conta secundária envie ou extraia imagens nos meus repositórios de imagens do Amazon ECR? Certifique-se de que a política em nível de repositório esteja definida com as permissões adequadas.
• Se você usa endpoints da VPC do ECR para extrair imagens, certifique-se de que o grupo de segurança do endpoint da VPC permita HTTPS de entrada na porta 443 do grupo de segurança do nó do EKS. Para obter mais informações, consulte Amazon ECR interface VPC endpoints (AWS PrivateLink) (Endpoints da VPC de interface do Amazon ECR (AWS PrivateLink)).
• No containerd, a pausa na extração da imagem só é feita durante o bootstrap. Depois disso, a imagem deve ser retida na instância. Não use scripts de limpeza personalizados ou comandos de exclusão manual, como crictl rmi —prune, para remover as imagens de pausa. Deixe o kubelet lidar com a coleta de resíduos (gc), que é executada automaticamente a cada 1-2 minutos. Quando você remove as imagens do contêiner de pausa do containerd, os novos pods não são iniciados. Os pods atuais são executados sem problemas nos nós e os logs do kubelet mostram o erro "Failed to create pod sandbox".

Erro "Pod does not have label" em nós do Windows

Se um Pod não tiver um nodeSelector programado em um nó do Windows, é possível receber uma mensagem de erro semelhante à seguinte:

"Failed to parse Kubernetes args: pod does not have label vpc.amazonaws.com/PrivateIPv4Address" or "Pod does not have label vpc.amazonaws.com/PrivateIPv4Address"

Para resolver o problema, certifique-se de incluir os seguintes rótulos no PodSpec para o parâmetro nodeSelector:

nodeSelector:
    kubernetes.io/os: windows
    kubernetes.io/arch: amd64

Confirme se você definiu o parâmetro enable-windows-ipam como true em seu configmap amazon-vpc-cni.

Se você não tiver um configmap amazon-vpc-cni, use o modelo a seguir e faça o upload para seu cluster:

apiVersion: v1
kind: ConfigMap
metadata:
  name: amazon-vpc-cni
  namespace: kube-system
data:
  enable-windows-ipam: "true"

Reinicie os Pods aws-node e node-windows.

Para obter mais informações sobre como implantar nós do Windows em clusters do Amazon EKS, consulte Implantar nós Windows em clusters EKS.

Erro no grupo de segurança

Se você tiver um problema com o grupo de segurança, receberá um erro semelhante ao seguinte:

"Plugin type="aws-cni" name="aws-cni" failed (add): add cmd: failed to assign an IP address to container
Vpc-resource-controller failed to allocate branch ENI to pod: creating network interface, NoCredentialProviders: no valid providers in chain. Deprecated."

Essa resposta de erro pode indicar um problema com o ambiente de gerenciamento health.kubernetes. Para resolver esse problema, entre em contato com o AWS Support.

Informações relacionadas

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

Como solucionar problemas de um provedor de OIDC e IRSA no Amazon EKS?

Como solucionar erros de IRSA no Amazon EKS?

Configurar o plug-in CNI da Amazon VPC para usar IRSA

Perfis do IAM para contas de serviço