Node NotReady

O que significa

O kubelet de cada nó avisa o plano de controle que está vivo. Se o aviso para, o controlador de nós espera o node-monitor-grace-period, que é de 50 s por padrão (referência do kube-controller-manager), e muda a condição Ready para Unknown. É quando o get nodes passa a mostrar NotReady. Ready False, em vez de Unknown, quer dizer outra coisa: o kubelet responde e diz que o nó não está saudável.

Junto, o nó recebe os taints node.kubernetes.io/unreachable (para Unknown) ou node.kubernetes.io/not-ready (para False). O Kubernetes acrescenta a todo pod uma tolerância de 300 segundos a esses dois taints, salvo se você definir outra. Por isso os pods continuam ligados ao nó por 5 minutos antes de serem marcados para remoção (documentação, "Taints and Tolerations").

A linha do tempo, medida

Desligamos o nó de teste e anotamos o relógio:

• 22:44:21 UTC: nó desligado.
• 22:45:09: condições em Unknown e nó NotReady, 48 s depois.
• 22:50:10: eventos TaintManagerEviction marcando os pods do nó para remoção, 301 s depois do NotReady.

Some os dois prazos e um nó que cai leva uns 6 minutos para ter os pods substituídos por controladores. Em serviço com uma réplica só, é esse o tempo de indisponibilidade.

Causas comuns

Diagnóstico em 3 comandos

1 · qual nó

kubectl get nodes

NAME                       STATUS     ROLES           AGE    VERSION
k3d-ia4code-lab-agent-0    NotReady   <none>          7m2s   v1.35.5+k3s1
k3d-ia4code-lab-server-0   Ready      control-plane   7m7s   v1.35.5+k3s1

2 · Unknown ou False, e desde quando

kubectl describe node k3d-ia4code-lab-agent-0 | sed -n '/Conditions:/,/Addresses:/p'

Conditions:
  Type             Status    LastTransitionTime                Reason              Message
  MemoryPressure   Unknown   Fri, 25 Sep 2026 19:45:09 -0300   NodeStatusUnknown   Kubelet stopped posting node status.
  DiskPressure     Unknown   Fri, 25 Sep 2026 19:45:09 -0300   NodeStatusUnknown   Kubelet stopped posting node status.
  PIDPressure      Unknown   Fri, 25 Sep 2026 19:45:09 -0300   NodeStatusUnknown   Kubelet stopped posting node status.
  Ready            Unknown   Fri, 25 Sep 2026 19:45:09 -0300   NodeStatusUnknown   Kubelet stopped posting node status.

kubectl describe node k3d-ia4code-lab-agent-0 | grep -A1 Taints

Taints:             node.kubernetes.io/unreachable:NoExecute
                    node.kubernetes.io/unreachable:NoSchedule

3 · o que aconteceu com os pods, 5 minutos depois

kubectl -n loja get events --field-selector reason=TaintManagerEviction

LAST SEEN   TYPE     REASON                 OBJECT         MESSAGE
23s         Normal   TaintManagerEviction   pod/busca      Marking for deletion Pod loja/busca
23s         Normal   TaintManagerEviction   pod/catalogo   Marking for deletion Pod loja/catalogo
23s         Normal   TaintManagerEviction   pod/vitrine    Marking for deletion Pod loja/vitrine

A correção

1. Veja a máquina: está ligada? No AKS e no EKS, o console mostra o estado da VM ou da instância.
2. Se estiver ligada, veja o kubelet: systemctl status kubelet e journalctl -u kubelet no nó. Certificado expirado, disco cheio e falta de memória no próprio nó são os achados mais comuns.
3. Se o nó não volta, tire-o de circulação: kubectl cordon, depois kubectl drain --ignore-daemonsets --delete-emptydir-data, e deixe o grupo de nós criar outro.

Para serviços que não aguentam 6 minutos fora, a correção é de desenho: mais de uma réplica, espalhadas por nós com topologySpreadConstraints e protegidas por PodDisruptionBudget. Reduzir a tolerância de 300 s é possível por pod, mas troca menos tempo parado por mais pods reiniciados à toa em oscilações curtas de rede.

spec:
  replicas: 2
  template:
    spec:
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: kubernetes.io/hostname
          whenUnsatisfiable: ScheduleAnyway
          labelSelector:
            matchLabels:
              app: checkout

Como aparece no Kubepier

O Kubepier mostra os eventos do pod com os avisos primeiro, com filtro por tipo, namespace e motivo. O diagnóstico por IA explica o erro a partir dos eventos e do log, em português, com a sua chave de API (Anthropic ou OpenAI). Abaixo, uma ilustração com dados fictícios.