Solucionar problemas do Modo Automático do EKS - Amazon EKS
Agente de monitoramento de nósObter a saída do console de uma instância gerenciada do EC2 usando a CLI do AWS EC2Obter logs de nós usando contêineres de depuração e a CLI do kubectlVisualizar recursos associados ao Modo Automático do EKS no Console da AWSVisualizar erros do IAM na conta da AWSSolucionar problemas de pods com falhas ao agendar o nó do Modo AutomáticoSolucionar problemas de nós que não estão se associando ao clusterCompartilhar volumes entre podsSolucionar problemas de controladores incluídos no Modo Automático

Ajudar a melhorar esta página

Para contribuir com este guia de usuário, escolha o link Editar esta página no GitHub, disponível no painel direito de cada página.

Solucionar problemas do Modo Automático do EKS

Com o Modo Automático do EKS, a AWS assume mais responsabilidade pelas instâncias do EC2 na conta da AWS. O EKS assume a responsabilidade pelo runtime do contêiner nos nós, pelo sistema operacional nos nós e por determinados controladores. Isso inclui um controlador de armazenamento em blocos, um controlador de balanceamento de carga e um controlador de computação.

Você deve usar as APIs da AWS e do Kubernetes para solucionar problemas de nós. É possível:

nota

O Modo Automático do EKS usa instâncias gerenciadas pelo EC2. Você não pode acessar diretamente as instâncias gerenciadas pelo EC2, inclusive por SSH.

Você pode ter os seguintes problemas que têm soluções específicas para os componentes do Modo Automático do EKS:

Você pode usar os seguintes métodos para solucionar problemas de componentes do Modo Automático do EKS:

Agente de monitoramento de nós

O Modo Automático do EKS inclui o agente de monitoramento de nós do Amazon EKS. Você pode usar esse agente para visualizar informações de solução de problemas e depuração sobre os nós. O agente de monitoramento de nós publica os events do Kubernetes e as conditions dos nós. Para ter mais informações, consulte Habilitar o reparo automático de nós e investigar os problemas de integridade de nós.

Obter a saída do console de uma instância gerenciada do EC2 usando a CLI do AWS EC2

Este procedimento ajuda na solução de problemas de tempo de inicialização ou no nível do kernel.

Primeiro, você precisa determinar o ID da instância do EC2 associada à workload. Depois, use a AWS CLI para recuperar a saída do console.

  1. Confirme se você tem o kubectl instalado e se está conectado ao cluster.

  2. (Opcional) Use o nome de uma implantação do Kubernetes para listar os pods associados.

    kubectl get pods -l app=<deployment-name>

  3. Use o nome do pod do Kubernetes para determinar o ID da instância do EC2 do nó associado.

    kubectl get pod <pod-name> -o wide

  4. Use o ID da instância do EC2 para recuperar a saída do console.

    aws ec2 get-console-output --instance-id <instance id> --latest --output text

Obter logs de nós usando contêineres de depuração e a CLI do kubectl

A forma recomendada de recuperar logs de um nó do Modo Automático do EKS é usar o recurso NodeDiagnostic. Para conferir essas etapas, consulte Recuperar logs de nós de um nó gerenciado usando kubectl e S3.

No entanto, você pode transmitir logs ao vivo de uma instância usando o comando kubectl debug node. Esse comando inicia um novo pod no nó que você deseja depurar e que pode ser usado interativamente.

  1. Inicie um contêiner de depuração. O comando a seguir usa i-01234567890123456 para o ID da instância do nó, -it aloca um tty e anexa stdin para uso interativo e usa o perfil sysadmin do arquivo kubeconfig.

    kubectl debug node/i-01234567890123456 -it --profile=sysadmin --image=public.ecr.aws/amazonlinux/amazonlinux:2023

    Veja um exemplo de saída abaixo.

    Creating debugging pod node-debugger-i-01234567890123456-nxb9c with container debugger on node i-01234567890123456.
If you don't see a command prompt, try pressing enter.
bash-5.2#

  2. No shell, agora você pode instalar o util-linux-core, que fornece o comando nsenter. Use nsenter para inserir o namespace de montagem do PID 1 (init) no host e execute o comando journalctl para transmitir logs do kubelet:

    yum install -y util-linux-core
nsenter -t 1 -m journalctl -f -u kubelet

Por segurança, a imagem do contêiner do Amazon Linux não instala muitos binários por padrão. Você pode usar o comando yum whatprovides para identificar o pacote que deve ser instalado para fornecer um determinado binário.

yum whatprovides ps
Last metadata expiration check: 0:03:36 ago on Thu Jan 16 14:49:17 2025.
procps-ng-3.3.17-1.amzn2023.0.2.x86_64 : System and process monitoring utilities
Repo        : @System
Matched from:
Filename    : /usr/bin/ps
Provide    : /bin/ps

procps-ng-3.3.17-1.amzn2023.0.2.x86_64 : System and process monitoring utilities
Repo        : amazonlinux
Matched from:
Filename    : /usr/bin/ps
Provide    : /bin/ps

Visualizar recursos associados ao Modo Automático do EKS no Console da AWS

Você pode usar o Console da AWS para visualizar o status dos recursos associados ao cluster do Modo Automático do EKS.

  • Volumes do EBS

    • Visualize os volumes do Modo Automático do EKS pesquisando pela chave de tag eks:eks-cluster-name

  • Load balancers

    • Visualize os balanceadores de carga do Modo Automático do EKS pesquisando pela chave de tag eks:eks-cluster-name

  • Instâncias do EC2

    • Visualize as instâncias do Modo Automático do EKS pesquisando pela chave de tag eks:eks-cluster-name

Visualizar erros do IAM na conta da AWS

  1. Navegue até o console do CloudTrail

  2. Selecione “Histórico de eventos” no painel de navegação à esquerda

  3. Aplique filtros de código de erro:

    • AccessDenied

    • UnauthorizedOperation

    • InvalidClientTokenId

Procure erros relacionados ao cluster do EKS. Use as mensagens de erro para atualizar as entradas de acesso ao EKS, o perfil do IAM do cluster ou o perfil do IAM do nó. Pode ser necessário anexar uma nova política a esses perfis com permissões para o Modo Automático do EKS.

Solucionar problemas de pods com falhas ao agendar o nó do Modo Automático

Caso os pods estejam ficando no estado Pending e não estejam sendo agendados no nó do modo automático, verifique se o seu manifesto de pod ou de implantação contém um nodeSelector. Se um nodeSelector estiver presente, certifique-se de que ele esteja usando eks.amazonaws.com/compute-type: auto para ser agendado em nós criados pelo Modo Automático do EKS. Para obter mais informações sobre os rótulos dos nós usados pelo Modo Automático do EKS, consulte Controlar se uma workload é implantada nos nós do Modo Automático do EKS.

Solucionar problemas de nós que não estão se associando ao cluster

O Modo Automático do EKS configura automaticamente novas instâncias do EC2 com as informações corretas para se associar ao cluster, incluindo o endpoint do cluster e a autoridade de certificação (CA) do cluster. No entanto, essas instâncias ainda podem falhar ao se associarem ao cluster do EKS como um nó. Execute os seguintes comandos para identificar as instâncias que não se associaram ao cluster:

  1. Execute kubectl get nodeclaim para verificar os NodeClaims que são Ready = False.

    kubectl get nodeclaim

  2. Execute kubectl describe nodeclaim <node_claim> e verifique a seção Status para identificar possíveis problemas que impedem o nó de se associar ao cluster.

    kubectl describe nodeclaim <node_claim>

Mensagens de erro comuns:

Error getting launch template configs

Você pode receber esse erro caso esteja configurando tags personalizadas no NodeClass com as permissões padrão do perfil do IAM do cluster. Consulte Saber mais sobre identidade e acesso no Modo Automático do EKS.

Error creating fleet

Pode ocorrer um problema de autorização ao fazer a chamada RunInstances da API do EC2. Verifique o AWS CloudTrail em busca de erros e consulte Perfil do IAM do cluster do Modo Automático do Amazon EKS para obter as permissões necessárias do IAM.

Detectar problemas de conectividade de nós com o VPC Reachability Analyzer

nota

Há uma cobrança por cada análise executada no VPC Reachability Analyzer. Para obter detalhes dos preços, consulte Preços da Amazon VPC.

Um dos motivos pelos quais uma instância não se associou ao cluster é um problema de conectividade de rede que a impede de acessar o servidor da API. Para diagnosticar esse problema, você pode usar o VPC Reachability Analyzer para realizar uma análise da conectividade entre um nó que não está conseguindo se associar ao cluster e o servidor de API. Você precisará de duas informações:

  • ID da instância de um nó que não consegue se associar ao cluster

  • Endereço IP do endpoint do servidor de API do Kubernetes

Para obter o ID da instância, você precisará criar uma workload no cluster para fazer com que o Modo Automático do EKS inicie uma instância do EC2. Isso também cria um objeto NodeClaim no seu cluster que terá o ID da instância. Execute kubectl get nodeclaim -o yaml para imprimir todos os NodeClaims no cluster. Cada NodeClaim contém o ID da instância como um campo, e novamente no providerID:

kubectl get nodeclaim -o yaml

Veja um exemplo de saída abaixo.

    nodeName: i-01234567890123456
    providerID: aws:///us-west-2a/i-01234567890123456

Você pode determinar o endpoint do servidor de API do Kubernetes executando kubectl get endpoint kubernetes -o yaml. Os endereços estão no campo de endereços:

kubectl get endpoints kubernetes -o yaml

Veja um exemplo de saída abaixo.

apiVersion: v1
kind: Endpoints
metadata:
  name: kubernetes
  namespace: default
subsets:
- addresses:
  - ip: 10.0.143.233
  - ip: 10.0.152.17
  ports:
  - name: https
    port: 443
    protocol: TCP

Com essas duas informações, você pode realizar a análise. Primeiro, navegue até o VPC Reachability Analyzer no AWS Management Console.

  1. Clique em “Criar e analisar caminho”.

  2. Forneça um nome para a análise (por exemplo, “Falha na associação do nó”).

  3. Para o “Tipo de origem”, selecione “Instâncias”.

  4. Insira o ID da instância do nó com falha como a “Origem”.

  5. Para o “Destino do caminho”, selecione “Endereço IP”.

  6. Insira um dos endereços IP do servidor da API como “Endereço de destino”.

  7. Expanda a “Seção de configuração adicional do cabeçalho de pacote”

  8. Insira uma “Porta de destino” de 443.

  9. Selecione “Protocolo” como TCP caso ainda não tenha selecionado.

  10. Clique em “Criar e analisar caminho”.

  11. A análise pode levar alguns minutos para ser concluída. Se os resultados da análise indicarem falha na acessibilidade, eles indicarão onde a falha ocorreu no caminho da rede para que você possa resolver o problema.

Compartilhar volumes entre pods

Os nós do Modo Automático do EKS são configurados com o SELinux no modo de imposição, o que fornece mais isolamento entre os pods que estão sendo executados no mesmo nó. Quando o SELinux está habilitado, a maioria dos pods sem privilégios terá automaticamente seu próprio rótulo de segurança de várias categorias (MCS) aplicado a eles. Esse rótulo MCS é exclusivo por pod e foi projetado para garantir que um processo em um pod não possa manipular um processo em nenhum outro pod ou no host. Mesmo que um pod rotulado seja executado como raiz e tenha acesso ao sistema de arquivos do host, ele não conseguirá manipular arquivos, fazer chamadas de sistema sensíveis no host, acessar o runtime do contêiner ou obter o material da chave secreta do kubelet.

Devido a essa questão, você pode encontrar problemas ao tentar compartilhar dados entre pods. Por exemplo, um PersistentVolumeClaim com um modo de acesso de ReadWriteOnce não permitirá que vários pods acessem o volume simultaneamente.

Para habilitar esse compartilhamento entre pods, você pode usar as seLinuxOptions do pod para configurar o mesmo rótulo MCS nesses pods. Neste exemplo, atribuímos as três categorias c123,c456,c789 ao pod. Isso não entrará em conflito com nenhuma categoria atribuída automaticamente aos pods no nó, pois eles só receberão duas categorias.

securityContext:
  seLinuxOptions:
    level: "s0:c123,c456,c789"

Solucionar problemas de controladores incluídos no Modo Automático

Caso tenha um problema com um controlador, você deve pesquisar: