Como resolver pod Evicted no Kubernetes
Evicted quer dizer que o kubelet tirou o pod do nó para proteger o próprio nó, que ficou sem memória, sem disco ou sem PIDs. O pod fica com fase Failed e motivo Evicted, e o controller (Deployment, StatefulSet) cria outro, às vezes no mesmo nó apertado.
1. Ache os pods despejados
kubectl get pods -A --field-selector=status.phase=Failed | grep Evicted 2. Leia o motivo
Em Message, o describe diz o recurso que faltou, por exemplo "The node was low on resource: memory" ou "ephemeral-storage":
kubectl describe pod <pod> -n <namespace> 3. Veja a pressão no nó
As Conditions do nó mostram MemoryPressure, DiskPressure ou PIDPressure, e os eventos mostram quando o kubelet começou a despejar:
kubectl describe node <nó>
kubectl top nodes Quem sai primeiro
- O kubelet despeja antes os pods que usam mais do que pediram em requests, depois os de prioridade menor e, entre eles, os que mais passaram do request.
- Pods sem requests nem limits (QoS BestEffort) são os primeiros candidatos; pods com requests iguais aos limits (QoS Guaranteed) são os últimos.
Como evitar
- Memória: ponha requests.memory perto do uso real, para o scheduler não lotar o nó com pods que pedem pouco e usam muito.
- Disco: logs gravados no container e volumes emptyDir contam como ephemeral-storage. Defina requests e limits de ephemeral-storage e mande os logs para stdout.
- Imagens grandes e muitas versões antigas também enchem o disco do nó; o kubelet limpa imagens, mas um disco pequeno demais vive no limite.
- Dê PriorityClass mais alta aos workloads que não podem sair primeiro.
Limpar os pods Evicted
Os pods despejados ficam na lista como Failed até o coletor de lixo do cluster apagar. Para limpar um namespace:
kubectl delete pods -n <namespace> --field-selector=status.phase=Failed Sem terminal, no Kubepier
No Kubepier, o status do pod mostra Evicted, os eventos de aviso de pressão no nó sobem para o topo e o consumo de CPU e memória aparece por nó e namespace, de qualquer cluster, no navegador ou no celular.