Pending (FailedScheduling)

O que significa

Pending é a fase em que o pod foi aceito pelo cluster e ainda não roda. Logo depois de criado, todo pod passa por ela. Quando ele fica em Pending e não aparece nenhum nó na coluna NODE, o scheduler tentou encaixá-lo e não conseguiu. Cada tentativa gera um evento FailedScheduling com o placar: de quantos nós, quantos estavam disponíveis e por que os outros foram descartados.

O ponto que mais confunde: o scheduler decide por requests, não por uso. Ele soma os requests dos pods já alocados no nó e vê se o novo cabe no allocatable (documentação do Kubernetes, "Resource Management for Pods and Containers"). Um nó com 5% de CPU em uso e requests somando 100% recusa o pod.

Causas comuns

Diagnóstico em 3 comandos

Saídas reais de um pod de teste que pede 16 CPUs num cluster de dois nós com 10 CPUs cada.

1 · confirme que ele não tem nó

kubectl -n loja get pod relatorios -o wide

NAME         READY   STATUS    RESTARTS   AGE     IP       NODE
relatorios   0/1     Pending   0          7m49s   <none>   <none>

2 · leia o placar do scheduler

kubectl -n loja describe pod relatorios | sed -n '/Events:/,$p'

Events:
  Type     Reason            From               Message
  Warning  FailedScheduling  default-scheduler  0/2 nodes are available: 2 Insufficient cpu.
    no new claims to deallocate, preemption: 0/2 nodes are available:
    2 Preemption is not helpful for scheduling.

"0/2 nodes are available: 2 Insufficient cpu" quer dizer: dois nós no cluster, nenhum serve, os dois por falta de CPU. Quando há motivos diferentes, eles aparecem somados na mesma linha, como "1 Insufficient memory, 2 node(s) had untolerated taint". A parte de preemption diz que nem despejando pods de prioridade menor o pod caberia.

3 · compare com o que os nós têm

kubectl get nodes -o custom-columns=NOME:.metadata.name,CPU:.status.allocatable.cpu,MEMORIA:.status.allocatable.memory

NOME                       CPU   MEMORIA
k3d-ia4code-lab-agent-0    10    8024472Ki
k3d-ia4code-lab-server-0   10    8024472Ki

kubectl describe node k3d-ia4code-lab-server-0 | sed -n '/Allocated resources:/,/ephemeral/p'

Allocated resources:
  Resource           Requests    Limits
  cpu                200m (2%)   0 (0%)
  memory             140Mi (1%)  170Mi (2%)

Nenhum nó tem 16 CPUs de allocatable. Não adianta esperar: o pod nunca vai caber sem mudar o request ou o tamanho da máquina.

A correção

1. Insufficient cpu ou memory: meça o uso real e ajuste o request para ele. Se o serviço realmente precisa daquilo, o pool precisa de máquinas maiores ou de mais nós.
2. Taint sem toleration: veja os taints com kubectl describe node NOME | grep Taints e, se o pod deve mesmo ir para aquele nó, acrescente a toleration.
3. nodeSelector ou affinity: compare o rótulo pedido com kubectl get nodes --show-labels.
4. PVC: kubectl get pvc no namespace; um PVC em Pending tem o próprio evento dizendo o motivo.

resources:
  requests:
    cpu: 500m
    memory: 256Mi
  limits:
    memory: 512Mi

avisoApagar o pod não resolve Pending: o controlador cria outro com o mesmo request, que fica preso do mesmo jeito.

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.