**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: + Use um recurso `NodeDiagnostic` do Kubernetes para recuperar os logs dos nós usando o [Agente de monitoramento de nós](#auto-node-monitoring-agent). Para conferir as etapas, consulte [Recuperar logs de nós de um nó gerenciado usando kubectl e S3](auto-get-logs.md). + Use um recurso `NodeDiagnostic` do Kubernetes para capturar o tráfego de rede em um nó. Para conferir as etapas, consulte [Controlar o tráfego de rede de um nó gerenciado usando kubectl e S3](auto-get-tcpdump.md). + Use o comando `get-console-output` da CLI do AWS EC2 para recuperar a saída do console dos nós. Para conferir as etapas, consulte [Obter a saída do console de uma instância gerenciada do EC2 usando a CLI do AWS EC2](#auto-node-console). + Use os *contêineres de depuração* do Kubernetes para recuperar os logs dos nós. Para conferir as etapas, consulte [Obter logs de nós usando *contêineres de depuração* e a CLI do `kubectl`](#auto-node-debug-logs). **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: + Pods presos no estado `Pending`, que não estão sendo agendados nos nós do Modo Automático. Para conferir as soluções, consulte [Solucionar problemas de pods com falhas ao agendar o nó do Modo Automático](#auto-troubleshoot-schedule). + Instâncias gerenciadas do EC2 que não se juntam ao cluster como nós do Kubernetes. Para conferir as soluções, consulte [Solucionar problemas de nós que não estão se associando ao cluster](#auto-troubleshoot-join). + Erros e problemas com `NodePools`, `PersistentVolumes` e `Services` que usam os controladores incluídos no Modo Automático do EKS. Para conferir as soluções, consulte [Solucionar problemas de controladores incluídos no Modo Automático](#auto-troubleshoot-controllers). + A segurança aprimorada de pods impede o compartilhamento de volumes entre pods. Para conferir as soluções, consulte [Compartilhar volumes entre pods](#auto-troubleshoot-share-pod-volumes). Você pode usar os seguintes métodos para solucionar problemas de componentes do Modo Automático do EKS: + [Obter a saída do console de uma instância gerenciada do EC2 usando a CLI do AWS EC2](#auto-node-console) + [Obter logs de nós usando *contêineres de depuração* e a CLI do `kubectl`](#auto-node-debug-logs) + [Visualizar recursos associados ao Modo Automático do EKS no Console da AWS](#auto-node-ec2-web) + [Visualizar erros do IAM na conta da AWS](#auto-node-iam) + [Detectar problemas de conectividade de nós com o `VPC Reachability Analyzer`](#auto-node-reachability) ## 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 obter mais informações, consulte [Detectar problemas de integridade dos nós e habilitar o reparo automático dos nós](node-health.md). ## 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. 1. (Opcional) Use o nome de uma implantação do Kubernetes para listar os pods associados. ``` kubectl get pods -l app= ``` 1. Use o nome do pod do Kubernetes para determinar o ID da instância do EC2 do nó associado. ``` kubectl get pod -o wide ``` 1. Use o ID da instância do EC2 para recuperar a saída do console. ``` aws ec2 get-console-output --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](auto-get-logs.md). 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 abaixo um exemplo de saída. ``` 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# ``` 1. 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](https://console.aws.amazon.com/ec2/home#Volumes) + Visualize os volumes do Modo Automático do EKS pesquisando pela chave de tag `eks:eks-cluster-name` + [Load balancers](https://console.aws.amazon.com/ec2/home#LoadBalancers) + Visualize os balanceadores de carga do Modo Automático do EKS pesquisando pela chave de tag `eks:eks-cluster-name` + [Instâncias do EC2](https://console.aws.amazon.com/ec2/home#Instances) + 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 1. Selecione "Histórico de eventos" no painel de navegação à esquerda 1. 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](associate-workload.md). ## 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 ``` 1. Execute `kubectl describe nodeclaim ` e verifique a seção **Status** para identificar possíveis problemas que impedem o nó de se associar ao cluster. ``` kubectl describe nodeclaim ``` **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](auto-learn-iam.md). `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](auto-cluster-iam-role.md) 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](https://aws.amazon.com/vpc/pricing/). 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](https://docs.aws.amazon.com/vpc/latest/reachability/what-is-reachability-analyzer.html) 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 abaixo um exemplo de saída. ``` 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 abaixo um exemplo de saída. ``` 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 Console de gerenciamento da AWS. 1. Clique em "Criar e analisar caminho" 1. Forneça um nome para a análise (por exemplo, "Falha na associação do nó") 1. Para o "Tipo de origem", selecione "Instâncias" 1. Insira o ID da instância do nó com falha como a "Origem" 1. Para o "Destino do caminho", selecione "Endereço IP" 1. Insira um dos endereços IP do servidor da API como "Endereço de destino" 1. Expanda a "Seção de configuração adicional do cabeçalho de pacote" 1. Insira uma "Porta de destino" de 443 1. Selecione "Protocolo" como TCP caso ainda não tenha selecionado 1. Clique em “Criar e analisar caminho”. 1. 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" ``` ## Exibir eventos do Karpenter nos logs do ambiente de gerenciamento Para clusters do EKS com logs do ambiente de gerenciamento habilitados, é possível obter informações sobre as ações e o processo de tomada de decisão do Karpenter consultando os logs. Isso pode ser particularmente útil para solucionar problemas do Modo Automático do EKS relacionados ao provisionamento, ajuste de escala e encerramento de nós. Para visualizar eventos relacionados ao Karpenter, use a seguinte consulta do CloudWatch Logs Insights: ``` fields @timestamp, @message | filter @logStream like /kube-apiserver-audit/ | filter @message like 'DisruptionBlocked' or @message like 'DisruptionLaunching' or @message like 'DisruptionTerminating' or @message like 'DisruptionWaitingReadiness' or @message like 'Unconsolidatable' or @message like 'FailedScheduling' or @message like 'NoCompatibleInstanceTypes' or @message like 'NodeRepairBlocked' or @message like 'Disrupted' or @message like 'Evicted' or @message like 'FailedDraining' or @message like 'TerminationGracePeriodExpiring' or @message like 'TerminationFailed' or @message like 'FailedConsistencyCheck' or @message like 'InsufficientCapacityError' or @message like 'UnregisteredTaintMissing' or @message like 'NodeClassNotReady' | sort @timestamp desc ``` Essa consulta filtra [eventos relacionados ao Karpenter](https://github.com/kubernetes-sigs/karpenter/blob/main/pkg/events/reason.go) específicos nos logs de auditoria do kube-apiserver. Os eventos incluem vários estados de interrupção, falhas de agendamento, problemas de capacidade e problemas relacionados ao nó. Ao analisar esses logs, é possível compreender melhor: + Por que Karpenter está tomando certas ações. + Qualquer problema que impeça o provisionamento, o ajuste de escala ou o encerramento adequados dos nós. + Possíveis problemas de capacidade ou compatibilidade com tipos de instância. + Eventos do ciclo de vida do nó, como interrupções, remoções ou encerramentos. Para usar essa consulta: 1. Navegue até o console do CloudWatch 1. No painel de navegação à esquerda, selecione "Logs Insights" 1. Escolha o grupo de logs para os logs do ambiente de gerenciamento do seu cluster do EKS 1. Cole a consulta no editor de consultas 1. Ajuste o intervalo de tempo conforme necessário 1. Execute a consulta Os resultados mostrarão um cronograma de eventos relacionados ao Karpenter, ajudando você a solucionar problemas e a entender o comportamento do Modo Automático do EKS em seu cluster. Para revisar as ações do Karpenter em um nó específico, é possível adicionar o filtro de linha abaixo especificando o ID da instância à consulta mencionada acima: ``` |filter @message like /[.replaceable]`i-12345678910123456`/ ``` **nota** Para usar essa consulta, os logs do ambiente de gerenciamento devem estar habilitados em seu cluster do EKS. Se você ainda não fez isso, consulte [Enviar logs do ambiente de gerenciamento para o CloudWatch Logs](control-plane-logs.md). ## Solucionar problemas de controladores incluídos no Modo Automático Caso tenha um problema com um controlador, você deve pesquisar: + Se os recursos associados a esse controlador estão devidamente formatados e válidos. + Se os recursos de RBAC do AWS IAM e do Kubernetes estão configurados corretamente para o cluster. Para obter mais informações, consulte [Saber mais sobre identidade e acesso no Modo Automático do EKS](auto-learn-iam.md). ## Recursos relacionados Use estes artigos do AWS re:Post para obter etapas avançadas de solução de problemas: + [How to troubleshoot common scaling issues in EKS Auto-Mode?](https://repost.aws/articles/ARLpQOknr5Rb-w5iAT9sUBpQ) + [How do I troubleshoot custom nodepool and nodeclass provisioning issues in Amazon EKS Auto Mode?](https://repost.aws/articles/ARPcmFS1POTgqPCBdcZFp6BQ) + [How do I troubleshoot EKS Auto Mode built-in node pools with Unknown Status?](https://repost.aws/en/articles/ARLhrdl45TRASGkvViwtBG0Q)