Como faço para alterar o status de um nó de NotReady ou de Unknown para Ready?

Resumo

Não é possível programar pods em um nó com status NotReady ou Unknown. Só é possível programá‑los quando o status do nó for Ready.

A solução a seguir trata dos nós com o status em NotReady ou Unknown.

Se o status do nó for MemoryPressure, DiskPressure ou PIDPressure, administre seus recursos até que mais pods possam ser programados nele.

Se o status do nó forNetworkUnavailable, configure a rede corretamente no nó. Para saber mais, consulte Status do Nó no site do Kubernetes.

Observação: para descobrir como administrar os limites dos recursos e as remoções de pods, consulte Remoção da pressão do nó no site do Kubernetes.

Resolução

Verifique os pods aws-node e kube-proxy para descobrir por que os nós estão no status NotReady

Não é possível programar pods em um nó com status NotReady.

Como medida de melhoria da postura de segurança, o grupo de nós gerenciados pode remover a política de Container Network Interface (CNI) do nome do recurso da Amazon (ARN) da função do nó. A ausência da política muda o status dos nós para NotReady. Para resolver esse problema, siga as orientações de como configurar perfis do IAM para contas de serviço (IRSA) para o DaemonSet doaws-node.

1. Execute o comando a seguir para verificar o status dos pods aws-node e kube-proxy:

   $ kubectl get pods -n kube-system -o wide

   A saída será parecida com essa:

   $ kubectl get pods -n kube-system -o wideNAME                             READY   STATUS    RESTARTS   AGE        IP              NODE
   aws-node-qvqr2                    1/1     Running   0          4h31m      192.168.54.115  ip-192-168-54-115.ec2.internal
   kube-proxy-292b4                  1/1     Running   0          4h31m      192.168.54.115  ip-192-168-54-115.ec2.internal

2. Analise a saída. Se o status do nó estiver normal, os pods aws-node e kube-proxy estarão com status de Running.
   Se nenhum dos pods aws-node ou kube-proxy aparecer na lista, vá para a etapa 3. Os pods aws-node e kube-proxy são gerenciados por um DaemonSet. Isso quer dizer que cada nó no cluster deve ter no mínimo um pod aws-node e um pod kube-proxy em execução. Para saber mais, consulte DaemonSet no site do Kubernetes.

   Se o status de um desses dois pods for diferente de Running, execute o comando a seguir:

   $ kubectl describe pod yourPodName -n kube-system

   Para receber mais informações sobre os pods aws-node e kube-proxy a partir dos logs, execute o comando a seguir:

   $ kubectl logs yourPodName -n kube-system

   Os logs e os eventos da saída de describe podem mostrar por que os pods não estão no status Running. Para que o status de um nó volte a Ready, tanto o pod aws-node quanto o kube-proxy devem constar como Running naquele nó.

3. Se os pods aws-node e kube-proxy não aparecerem na saída do comando, execute os comandos a seguir:

   $ kubectl describe daemonset aws-node -n kube-system
   $ kubectl describe daemonset kube-proxy -n kube-system

4. Procure na saída um ou mais motivos para os pods não iniciarem:

   Observação: também é possível pesquisar os logs do plano de controle do Amazon EKS para descobrir por que os pods não estão sendo programados.

5. Verifique se as versões do aws-node e do kube-proxy são compatíveis com a versão do cluster, tendo as diretrizes da AWS como referência. Execute os comandos a seguir para ver as versões dos pods:

   $ kubectl describe daemonset aws-node --namespace kube-system | grep Image | cut -d "/" -f 2$ kubectl get daemonset kube-proxy --namespace kube-system -o=jsonpath='{$.spec.template.spec.containers[:1].image}'

   Observação: para atualizar a versão do aws-node, consulte Trabalhando com o complemento Amazon VPC CNI plugin for Kubernetes do Amazon EKS. Para atualizar a versão do kube-proxy, siga a etapa 4 descrita em Atualizar a versão do Kubernetes de um cluster do Amazon EKS.

Em alguns casos, o status do nó aparece como Unknown. Isso quer dizer que o kubelet do nó não consegue comunicar o status verdadeiro ao ambiente de gerenciamento.

Para resolver o problema do nó com status Unknown, conclua as etapas das seções a seguir.

Verificar a configuração de rede entre os nós e o ambiente de gerenciamento

1. Garanta que não haja nenhuma regra nas listas de controle de acesso (ACL) das sub‑redes bloqueando o tráfego entre o ambiente de gerenciamento do Amazon EKS e os nós de processamento.

2. Verifique se os grupos de segurança do ambiente de gerenciamento e dos nós estão seguindo as regras básicas de tráfego interno e externo.

3. (Opcional) Se os nós foram configurados para usar proxy, verifique se o proxy permite que os endpoints do servidor de APIs recebam tráfego.

4. Para verificar se o nó tem acesso ao servidor de APIs, execute o seguinte comando netcat a partir do nó de processamento:

   $ nc -vz 9FCF4EA77D81408ED82517B9B7E60D52.yl4.eu-north-1.eks.amazonaws.com 443Connection to 9FCF4EA77D81408ED82517B9B7E60D52.yl4.eu-north-1.eks.amazonaws.com 443 port [tcp/https] succeeded!

   Observação: substitua 9FCF4EA77D81408ED82517B9B7E60D52.yl4.eu-north-1.eks.amazonaws.com pelo endpoint do servidor de APIs.

5. Verifique se as configurações das tabelas de rotas permitem a comunicação com o endpoint do servidor de APIs. Você pode testar usando um gateway da Internet ou um gateway NAT. Caso o cluster utilize uma rede PrivateOnly, verifique se os endpoints da VPC estão configurados corretamente.

Verificar o status do kubelet

1. Use o SSH para se conectar ao nó de processamento afetado.

2. Para verificar os logs do kubelet, execute o comando a seguir:

   $ journalctl -u kubelet > kubelet.log

   Observação: o arquivo kubelet.log traz informações sobre as operações do kubelet que podem ajudar a encontrar a raiz do problema do status.

3. Se os logs não fornecerem informações sobre a origem do problema, execute o comando a seguir. Ele verifica qual é o status do kubelet no nó de processamento:

   $ sudo systemctl status kubelet  kubelet.service - Kubernetes Kubelet
      Loaded: loaded (/etc/systemd/system/kubelet.service; enabled; vendor preset: disabled)
     Drop-In: /etc/systemd/system/kubelet.service.d
              └─10-eksclt.al2.conf
      Active: inactive (dead) since Wed 2023-12-04 08:57:33 UTC; 40s ago

   Se o status do kubelet não for Running, execute o comando a seguir para reiniciar o kubelet:

   $ sudo systemctl restart kubelet

Verificar se é possível acessar o endpoint da API do Amazon EC2

1. Use o SSH para se conectar a um dos nós de processamento.
2. Para verificar se o endpoint da API da Amazon Elastic Compute Cloud (Amazon EC2) da sua região pode ser acessado, execute o comando a seguir:

   $ nc -vz ec2.<region>.amazonaws.com 443Connection to ec2.us-east-1.amazonaws.com 443 port [tcp/https] succeeded!

   Observação: substitua us-east-1 pela região da AWS onde está o nó de processamento.

Verificar o perfil de instância do nó de processamento e o ConfigMap

1. Verifique se o perfil de instância do nó de processamento tem as políticas recomendadas.
2. Verifique se a função de instância do nó de processamento está no ConfigMap aws-auth. Para verificar o ConfigMap, execute o comando a seguir:

   $ kubectl get cm aws-auth -n kube-system -o yaml

   O ConfigMap deve ter uma entrada com o perfil do IAM (AWS Identity and Access Management) da instância do nó de processamento. Por exemplo:

   apiVersion: v1kind: ConfigMap
   metadata:
     name: aws-auth
     namespace: kube-system
   data:
     mapRoles: |
       - rolearn: <ARN of instance role (not instance profile)>
         username: system:node:{{EC2PrivateDNSName}}
         groups:
           - system:bootstrappers
           - system:nodes