Como soluciono problemas de pod do Kubernetes no Amazon EKS?

Resolução

Identifique o erro que causa o problema no seu pod

1. Para obter informações sobre seus pods, execute o seguinte comando kubectl describe:

   kubectl describe pod YOUR_POD_NAME -n YOUR_NAMESPACE

   Observação: substitua YOUR_POD_NAME pelo nome do seu pod e YOUR_NAMESPACE pelo seu namespace.

2. Identifique a mensagem de erro na seção Eventos da saída do comando.

   Exemplo de saída:

   Events:
     Type     Reason            Age                From               Message
     ----     ------            ----               ----               -------
     Warning  FailedScheduling  24s                default-scheduler  no nodes available to schedule pods
     Warning  FailedScheduling  19s (x2 over 22s)  default-scheduler  no nodes available to schedule pods

Com base na mensagem de erro que você recebe, use a seguinte solução de problemas para resolver o problema do seu pod.

Problemas de montagem de volume do EBS

O exemplo de saída a seguir é de um comando kubectl describe pod ebs-pod. A saída mostra um erro de afinidade do nó de volume para a montagem do volume do Amazon Elastic Block Store (Amazon EBS):

Name:         ebs-pod
...
Status:       Pending
...
Events:
  Type     Reason            Age                 From               Message
  ----     ------            ----                ----               -------
  Warning FailedScheduling 88s (x20 over 96m) default-scheduler 0/2 nodes are available 2 node(s) had volume node affinity conflict

O erro anterior ocorre quando você agenda Solicitações de volumes persistentes (Persistent Volume Claims, PVCs) para seu pod em várias Zonas de disponibilidade. Não é possível programar seu pod porque ele não pode se conectar ao volume a partir de outra Zona de disponibilidade. Para resolver esse problema, você deve programar as PVCs em uma Zona de disponibilidade.

Para solucionar esse erro, conclua as etapas a seguir:

1. Para obter informações sobre todos os PVCs em seu namespace, execute o seguinte comando kubectl get pvc:

   kubectl get pvc -n YOUR_NAMESPACE

   Observação: substitua YOUR_NAMESPACE pelo seu namespace.

2. Para obter informações sobre seu Volume persistente (Persistent Volume, PV), execute o seguinte comando kubectl get pv:

   kubectl get pv

3. Para encontrar o PV que corresponde ao seu PVC, execute o seguinte comando kubectl describe pv:

   kubectl describe pv your_PV

   Observação: substitua your_PV pelo nome do seu PV.

4. Confirme se o ID do volume que você recebeu do comando anterior está associado à Zona de disponibilidade correta.

5. Verifique o nó onde a Zona de disponibilidade está localizada.

Se você tiver um conflito de afinidade do nó de volume, realize uma das seguintes ações:

• Use taints e tolerâncias para garantir que os pods que usam a montagem do Amazon EBS sejam programados no nó correto. O nó deve estar na Zona de disponibilidade onde está o volume do EBS. Para obter mais informações, consulte Taints e Tolerâncias no site do Kubernetes.
• Use StatefulSets em vez de uma implantação para criar um único volume do EBS na mesma Zona de disponibilidade para cada pod no StatefulSet. Para saber mais, consulte StatefulSets no site do Kubernetes.

Seu pod ou StatefulSet pode estar travado no estado Pendente. Isso é verdade mesmo quando seu pod ou StatefulSet está na mesma Zona de disponibilidade do volume do EBS. Para resolver esse problema, execute o seguinte comando kubectl logs para verificar os logs dos pods do driver CSI do Amazon EBS:

kubectl logs your-ebs-csi-controller -n your-kube-system -c your-csi-provisioner

Observação: substitua your-ebs-csi-controller pelo seu controlador CSI do Amazon EBS. Além disso, substitua your-kube-system por seu namespace predefinido e your-csi-provisioner por um nome de contêiner que você usa para extrair logs.

Erro de estado ContainerCreating

A mensagem de erro a seguir ocorre quando seu pod fica travado no estado ContainerCreating e o networkPlugin: cni não atribui um endereço IP ao seu pod:

“Failed to create pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container “0fdf25254b1888afeda8bf89bc1dcb093d0661ae2c8c65a4736e473c73714c65” network for pod “test”: networkPlugin cni failed to set up pod “test” network: add cmd: failed to assign an IP address to container.”

Para solucionar o erro de estado ContainerCreating, realize as seguintes ações:

• Verifique se sua sub-rede tem um endereço IP disponível para resolver o problema. Abra o console da Amazon Virtual Private Cloud (Amazon VPC). No painel de navegação, em Nuvem privada virtual, selecione Sub-redes.
• Verifique se o pod do aws-node está no estado Em execução. Além disso, certifique-se de usar a versão compatível mais recente da CNI da Amazon VPC.
• Verifique se o número de pods na instância atingiu o número máximo de pods.
• No nó em que você programou seu pod, procure mensagens de erro nos logs do ipamd e no plug-in no caminho var/log/aws-routed-eni.

Erro de estado CrashLoopBackOff

Você recebe a mensagem de erro “Back-Off restarting failed container”.

A mensagem de erro anterior ocorre porque o contêiner falha repetidamente ao iniciar e, em seguida, entra no estado CrashLoopBackOff e reinicia persistentemente no pod.

Os problemas a seguir podem fazer com que o contêiner falhe repetidamente ao iniciar:

• Memória insuficiente
• Sobrecarga de recursos
• Erros de implantação
• Problemas de dependência externa, como erros de DNS
• Dependências de terceiros
• Falhas no nível do contêiner causadas por conflitos de portas

Para obter os erros nos logs do pod atual, execute o seguinte comando kubectl logs:

kubectl logs YOUR_POD_NAME -n YOUR_NAMESPACE

Observação: substitua YOUR_POD_NAME pelo nome do seu pod e YOUR_NAMESPACE pelo seu namespace.

Para obter os erros nos logs do pod anterior que travou, execute o seguinte comando kubectl logs -- previous:

kubectl logs --previous YOUR_POD_NAME -n YOUR_NAMESPACE

Observação: substitua YOUR_POD_NAME pelo nome do seu pod e YOUR_NAMESPACE pelo seu namespace.

Erros de falha na sonda

Quando um pod falha, você recebe um erro de falha na sonda devido a uma conexão recusada ou ao tempo limite do cliente.

Solucionar problemas de conexão recusada

Se uma sonda falhar devido a uma conexão recusada, você poderá receber uma das seguintes mensagens de erro:

• “Liveness probe failed: Get https://$POD_IP:8080/<healthcheck_path>: dial tcp POD_IP:8080: connect: connection refused.”
• “Readiness probe failed: Get https://$POD_IP:8080/<healthcheck_path>: dial tcp POD_IP:8080: connect: connection refused.”

Para solucionar problemas de conexão recusada, conclua as etapas a seguir:

1. Para obter manualmente o caminho de verificação de integridade definido no manifesto do pod a partir do nó de processamento, execute o seguinte comando:

   [ec2-user@ip-10-5-1-12 ~]$ curl -ikv podIP:8080//your_healthcheck_path

   Observação: substitua podIP pelo endereço IP do seu pod e your_healthcheck_path pelo nome do seu caminho.

2. Verifique o caminho de verificação de integridade definido no manifesto do pod no pod que falhou na sonda de vivacidade ou na sonda de prontidão. Para verificar o caminho da verificação de integridade, execute o seguinte comando:

   local@bastion-host ~ % kubectl exec YOUR_POD_NAME -- curl -ikv "http://localhost:8080/your_healthcheck_path"

   Observação: substitua YOUR_POD_NAME pelo nome do seu pod.

3. Execute a mesma imagem de contêiner no bastion host.

4. Verifique se é possível obter o caminho de verificação de integridade definido nas sondas do manifesto. Em seguida, verifique se há falhas, tempos limite ou erros nos logs do contêiner.

5. Para verificar se há erros nos logs do kubelet do nó de processamento em que seu pod é executado, execute o seguinte comando journalctl:

   [ec2-user@ip-10-5-1-12 ~]$ journalctl -u kubelet //optionally 'grep' with pod name

Solucione problemas de tempo limite do cliente

Se uma sonda falhar devido ao tempo limite do cliente, é possível receber uma das seguintes mensagens de erro:

• “Liveness probe failed: Get “http://podIP:8080/<healthcheck_path> ": context deadline exceeded (Client.Timeout exceeded while awaiting headers).”
• “Readiness probe failed: Get “http://podIP:8080/<healthcheck_path> ": context deadline exceeded (Client.Timeout exceeded while awaiting headers).”

Para solucionar problemas de tempo limite do cliente, verifique se a configuração está correta para as sondas de vivacidade e as sondas de prontidão para seus pods de aplicação.

Se você usa um grupo de segurança para pods e ENABLE_POD_ENI=true, deve desativar o TCP early demux. Essa ação permite que o kubelet se conecte aos pods nas interfaces de rede da ramificação que usam TCP.

Para desativar o TCP early demux, execute o seguinte comando kubectl patch:

kubectl patch daemonset aws-node -n kube-system \-p '{"spec": {"template": {"spec": {"initContainers": [{"env":[{"name":"DISABLE_TCP_EARLY_DEMUX","value":"true"}],"name":"aws-vpc-cni-init"}]}}}}'

Erro ImagePullBackOff

O erro ImagePullBackOff ocorre quando um contêiner em execução em um pod não consegue extrair a imagem necessária de um registro de contêiner.

Os problemas a seguir podem causar esse erro:

• Problemas de conectividade de rede
• Nome ou tag de imagem incorretos
• Credenciais ausentes
• Permissões insuficientes

Para identificar o que causou o problema, conclua as seguintes etapas:

1. Para obter o status do seu pod, execute o seguinte comando:

   kubectl get pods -n YOUR_NAMESPACE

   Observação: substitua YOUR_NAMESPACE pelo seu namespace.

2. Para obter detalhes de falhas sobre seu pod, execute o seguinte comando:

   kubectl describe pod YOUR_POD_NAME -n YOUR_NAMESPACE

   Observação: substitua YOUR_POD_NAME pelo nome do seu pod e YOUR_NAMESPACE pelo seu namespace.

   Exemplo de saída:

   Events:
   Type     Reason     Age                From                Message
   ----     ------     ----               ----                -------
   Normal   Scheduled  18m                default-scheduler   Successfully assigned kube-system/kube-proxy-h4np6 to XXX.XXX.eu-west-1.compute.internal
   Normal   Pulling    16m (x4 over 18m)  kubelet             Pulling image "<account-id>.dkr.ecr.eu-west-1.amazonaws.com/eks/kube-proxy:v1.21.5-eksbuild.2"
   Warning  Failed     16m (x4 over 18m)  kubelet             Failed to pull image "<account-d>.dkr.ecr.eu-west-1.amazonaws.com/eks/kube-proxy:v1.21.5-eksbuild.2": rpc error: code = Unknown desc = Error response from daemon: manifest for <account-id>.dkr.ecr.eu-west-1.amazonaws.com/eks/kube-proxy:v1.21.5-eksbuild.2 not found: manifest unknown: Requested image not found

Para solucionar o erro ImagePullBackOff, consulte Como posso solucionar os erros ErrImagePull e ImagePullBackoff do status do pod no Amazon EKS?