Por que o meu pod do Amazon EKS está paralisado no estado ContainerCreating com o erro “failed to create pod sandbox” (falha ao criar a área restrita para testes do pod)?

Data da última atualização: 9/1/2023

O meu pod do Amazon Elastic Kubernetes Service (Amazon EKS) está paralisado no estado ContainerCreating com o erro “failed to create pod sandbox” (falha ao criar a área restrita para testes do pod).

Resolução

Seus pods do Amazon EKS podem ficar paralisados no estado ContainerCreating com um erro de conectividade de rede por vários motivos. Siga as etapas de soluções de problemas indicadas a seguir de acordo com a mensagem de erro recebida.

Resposta de erro do daemon: failed to start shim: fork/exec /usr/bin/containerd-shim: resource temporarily unavailable: unknown (falha ao iniciar o shim: fork/exec /usr/bin/containerd-shim: recurso temporariamente indisponível: desconhecido)

Esse erro ocorre em função de uma limitação do sistema operacional causada pelas configurações definidas de kernel para PID máximo ou número máximo de arquivos.

Execute o comando a seguir para obter informações sobre seu pod:

$ kubectl describe pod example_pod

Exemplo de saída:

kubelet, ip-xx-xx-xx-xx.xx-xxxxx-x.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 o problema temporariamente, reinicie o nó.

Para solucionar o problema, faça o seguinte:

  • Reúna os logs de nós.
  • Analise os logs do Docker em relação ao erro “dockerd[4597]: runtime/cgo: pthread_create failed: Resource temporarily unavailable” (dockerd[4597]: falha em runtime/cgo: pthread_create: recurso temporariamente indisponível).
  • Analise o log do Kubelet para ver os seguintes erros:
    • “kubelet[5267]: runtime: failed to create new OS thread (have 2 already; errno=11)" (“kubelet [5267]: tempo de execução: falha ao criar um novo thread do sistema operacional [já existem 2; errno=11]”)
    • “kubelet[5267]: runtime: may need to increase max user processes (ulimit -u)” (“kubelet [5267]: tempo de execução: pode ser necessário aumentar o máximo de processos do usuário (ulimit -u)”).
  • Identifique os processos zumbis executando o comando ps. Todos os processos listados com o estado Z na saída são processos zumbis.

O plugin de rede cni falhou ao configurar a rede do pod: add cmd: failed to assign an IP address to container (add cmd: falha ao atribuir um endereço IP ao contêiner)

Esse erro indica que a interface de rede de contêineres (CNI) não pode atribuir um endereço IP ao pod recém-provisionado.

Veja a seguir os motivos pelos quais a CNI não fornece um endereço IP para o pod recém-criado:

  • A instância usou o máximo permitido de interfaces de rede elásticas e endereços IP.
  • As sub-redes da Amazon Virtual Private Cloud (Amazon VPC) têm uma contagem de zero endereços IP.

Veja a seguir um exemplo de esgotamento de endereços IP da interface de rede:

Instance type    Maximum network interfaces    Private IPv4 addresses per interface    IPv6 addresses per interface
t3.medium        3                             6                                       6

Neste exemplo, a instância t3.medium tem no máximo três interfaces de rede e cada interface de rede tem no máximo seis endereços IP. O primeiro endereço IP é usado para o nó e não pode ser atribuído. Isso deixa 17 endereços IP que a interface de rede pode alocar.

Os logs do daemon de gerenciamento de endereços IP locais (ipamD) mostram a seguinte mensagem quando a interface de rede fica sem endereços IP:

"ipamd/ipamd.go:1285","msg":"Total number of interfaces found: 3 "
"AssignIPv4Address: IP address pool stats: total: 17, assigned 17"
"AssignPodIPv4Address: ENI eni-abc123 does not have available addresses"

Execute o comando a seguir para obter informações sobre seu pod:

$ kubectl describe pod example_pod

Exemplo de saída:

Warning FailedCreatePodSandBox 23m (x2203 over 113m) kubelet, ip-xx-xx-xx-xx.xx-xxxxx-x.compute.internal (combined from similar events): Failed create pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" network for pod "provisioning-XXXXXXXXXXXXXXX": networkPlugin cni failed to set up pod "provisioning-XXXXXXXXXXXXXXX" network: add cmd: failed to assign an IP address to container

Analise a sub-rede para identificar se ela ficou sem endereços IP livres. Você pode visualizar os endereços IP disponíveis para cada sub-rede no console da Amazon VPC na seção Sub-redes.

Subnet: XXXXXXXXXX
IPv4 CIDR Block 10.2.1.0/24   Number of allocated ips 254   Free address count 0

Para resolver esse problema, reduza a escala de algumas workloads na vertical para liberar endereços IP disponíveis. Se houver capacidade de sub-rede adicional disponível, você poderá escalar o nó. Você também pode criar uma sub-rede adicional. Para obter mais informações, consulte How do I use multiple CIDR ranges with Amazon EKS? (Como faço para usar vários intervalos CIDR com o Amazon EKS?) Siga as instruções na seção Criar sub-redes com um novo intervalo CIDR.

Error while dialing dial tcp 127.0.0.1:50051: connect: connection refused (Erro ao discar o dial tcp 127.0.0.1:50051: connect: conexão recusada)

Esse erro indica que o pod aws-node falhou ao se comunicar com o IPAM porque o pod aws-node falhou ao ser executado no nó.

Execute os seguintes comandos para obter informações sobre o pod:

$ kubectl describe pod example_pod
$ kubectl describe pod/aws-node-XXXXX -n kube-system

Saídas de exemplo:

Warning  FailedCreatePodSandBox  51s  kubelet, ip-xx-xx-xx-xx.ec2.internal  Failed create pod sandbox: rpc error: code = Unknown desc = [failed to set up sandbox container "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" network for pod "example_pod": NetworkPlugin cni failed to set up pod "example_pod" network: add cmd: Error received from AddNetwork gRPC call: rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing dial tcp 127.0.0.1:50051: connect: connection refused", failed to clean up sandbox container
"XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" network for pod "example_pod": NetworkPlugin cni failed to teardown pod "example_pod" network: del cmd: error received from DelNetwork gRPC call: rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing dial tcp 127.0.0.1:50051: connect: connection refused"]

Para solucionar esse problema, verifique se o pod aws-node está implantado e no estado Em execução:

kubectl get pods --selector=k8s-app=aws-node -n kube-system

Observação: verifique se você está executando a versão correta do plug-in VPC CNI para a versão do cluster.

Os pods podem estar no estado Pendind (Pendente) devido a erros de sondagem Existência e Prontidão. Certifique-se de ter a versão mais recente recomendada do complemento VPC CNI, de acordo com a tabela de compatibilidade.

Execute o comando a seguir para visualizar a última mensagem de log do pod aws-node:

kubectl -n kube-system exec -it aws-node-XXX-- tail -f /host/var/log/aws-routed-eni/ipamd.log | tee ipamd.log

O problema também pode ocorrer porque ocorre uma falha na montagem do ponto de montagem Dockershim. Veja a seguir um exemplo de mensagem que você pode receber quando esse problema ocorre:

Getting running pod sandboxes from \"unix:///var/run/dockershim.sock\
Not able to get local pod sandboxes yet (attempt 1/5): rpc error: code = Unavailable desc = all SubConns are in TransientFailure, latest connection error: connection error: desc = "transport: Error while dialing dial unix /var/run/dockershim.sock: connect: no such file or director

A mensagem anterior indica que o pod não conseguiu montar o var/run/dockershim.sock.

Para resolver esse problema, tente o seguinte:

  • Reinicie o pod aws-node para remapear o ponto de montagem.
  • Isole o nó e escale os nós no grupo de nós.
  • Atualize a interface de rede da Amazon VPC para a versão mais recente do cluster compatível.

Se você adicionou a CNI adicionada como um plugin gerenciado no Console de Gerenciamento da AWS, o aws-node falhará nos testes. Os plugins gerenciados substituem a conta de serviço. No entanto, a conta de serviço não está configurada com a função selecionada. Para resolver esse problema, desative o plugin no Console de Gerenciamento da AWS e crie a conta de serviço usando um arquivo manifesto. Como alternativa, edite a conta de serviço atual do aws-node para adicionar a função usada no plugin gerenciado.

Network plugin cni failed to set up pod "my-app-xxbz-zz" network: failed to parse Kubernetes args: pod does not have label vpc.amazonaws.com/PrivateIPv4Address (O plugin de rede cni falhou ao configurar a rede “my-app-xxbz-zz” do pod: falha ao analisar argumentos do Kubernetes: o pod não tem o rótulo vpc.amazonaws.com/PrivateIPv4Address)

Você recebe esse erro por um dos seguintes motivos:

  • O pod não está funcionando corretamente.
  • O certificado que o pod está usando não foi criado com êxito.

Esse erro está relacionado ao webhook do controlador de admissão da Amazon VPC, que é exigido nos clusters do Amazon EKS para executar workloads do Windows. Esse webhook é um plugin que executa um pod no namespace kube-system. O componente é executado em nós do Linux e permite redes para pods de entrada em nós do Windows.

Execute o comando a seguir para obter a lista de pods afetados:

kubectl get pods

Exemplo de saída:

my-app-xxx-zz        0/1     ContainerCreating   0          58m   <none>            ip-XXXXXXX.compute.internal   <none>
my-app-xxbz-zz       0/1     ContainerCreating   0          58m   <none>

Execute o comando a seguir para obter informações sobre o pod:

$ kubectl describe pod my-app-xxbz-zz

Exemplo de saída:

Failed to create pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" network for pod "<POD_ANME>": networkPlugin cni failed to set up pod "example_pod" network: failed to parse Kubernetes args: pod does not have label vpc.amazonaws.com/PrivateIPv4Address
Reconciler worker 1 starting processing node ip-XXXXXXX.compute.internal.
Reconciler checking resource vpc.amazonaws.com/PrivateIPv4Address warmpool size 1 desired 3 on node ip-XXXXXXX.compute.internal.
Reconciler creating resource vpc.amazonaws.com/PrivateIPv4Address on node ip-XXXXXXX.compute.internal.
Reconciler failed to create resource vpc.amazonaws.com/PrivateIPv4Address on node ip-XXXXXXX.compute.internal: node has no open IP address slots.

Os nós do Windows oferecem suporte a uma interface de rede por nó. Cada nó do Windows pode executar tantos pods quanto os endereços IP disponíveis por interface de rede, menos um. Para resolver esse problema, aumente a escala verticalmente do número de nós do Windows.

Se os endereços IP não forem o problema, revise o evento e os logs do pod do controlador de admissão da Amazon VPC.

Execute o seguinte comando para confirmar se o pod do controlador de admissão da Amazon VPC foi criado:

$ kubectl get pods -n kube-system  OR kubectl get pods -n kube-system | grep "vpc-admission"

Exemplo de saída:

vpc-admission-webhook-5bfd555984-fkj8z     1/1     Running   0          25m

Execute o comando a seguir para obter informações sobre o pod:

$ kubectl describe pod vpc-admission-webhook-5bfd555984-fkj8z -n kube-system

Exemplo de saída:

  Normal  Scheduled  27m   default-scheduler  Successfully assigned kube-system/vpc-admission-webhook-5bfd555984-fkj8z to ip-xx-xx-xx-xx.ec2.internal
  Normal  Pulling    27m   kubelet            Pulling image "xxxxxxx.dkr.ecr.xxxx.amazonaws.com/eks/vpc-admission-webhook:v0.2.7"
  Normal  Pulled     27m   kubelet            Successfully pulled image "xxxxxxx.dkr.ecr.xxxx.amazonaws.com/eks/vpc-admission-webhook:v0.2.7" in 1.299938222s
  Normal  Created    27m   kubelet            Created container vpc-admission-webhook
  Normal  Started    27m   kubelet            Started container vpc-admission-webhook

Execute o comando a seguir para verificar se há algum problema de configuração nos logs do pod:

$ kubectl logs vpc-admission-webhook-5bfd555984-fkj8z -n kube-system

Exemplo de saída:

I1109 07:32:59.352298       1 main.go:72] Initializing vpc-admission-webhook version v0.2.7.
I1109 07:32:59.352866       1 webhook.go:145] Setting up webhook with OSLabelSelectorOverride: windows.
I1109 07:32:59.352908       1 main.go:105] Webhook Server started.
I1109 07:32:59.352933       1 main.go:96] Listening on :61800 for metrics and healthz
I1109 07:39:25.778144       1 webhook.go:289] Skip mutation for  as the target platform is .

A saída anterior mostra que o contêiner foi iniciado com êxito. Em seguida, o pod adiciona o rótulo vpc.amazonaws.com/PrivateIPv4Address ao pod da aplicação. No entanto, o manifesto do pod da aplicação deve conter um seletor de nós ou afinidade para que o pod seja programado nos nós do Windows.

Outras opções para solucionar o problema incluem verificar o seguinte:

  • Você implantou o pod do controlador de admissão da Amazon VPC no namespace kube-system.
  • Logs ou eventos não estão apontando para um certificado expirado. Se o certificado estiver expirado e os pods do Windows estiverem presos no estado de Criação do contêiner, você deverá excluir e reimplantar os pods.
  • Não há nenhum tempo limite ou problemas relacionados ao DNS.

Se você não criar o controlador de admissão da Amazon VPC, ative o suporte do Windows para seu cluster.

Importante: o Amazon EKS não exige que você ative o controlador de admissão da Amazon VPC para oferecer suporte a grupos de nós do Windows. Se você ativou o controlador de admissão da Amazon VPC, remova o suporte antigo do Windows do seu plano de dados.


Este artigo ajudou?


Precisa de ajuda com faturamento ou suporte técnico?