O que significa
Apagar um pod não o remove na hora. A API marca o objeto com deletionTimestamp e o kubectl passa a mostrar Terminating. O kubelet do nó manda SIGTERM aos containers, espera o grace period, que tem 30 segundos por padrão, e manda SIGKILL a quem não saiu (documentação do Kubernetes, "Pod Lifecycle"). Quando o kubelet confirma o fim e não há mais finalizers, o objeto sai da API.
Preso quer dizer que um desses dois passos não acontece: há finalizer que ninguém remove, ou não há kubelet para confirmar.
Causas comuns
Um controlador pôs um finalizer para limpar algo antes da remoção (volume, registro externo, sessão) e não está rodando, ou falhou. A API não apaga o objeto enquanto houver finalizer.
O kubelet é quem confirma que o container parou. Com o nó inalcançável, ninguém confirma, e o pod fica em Terminating até o nó voltar ou até uma remoção forçada.
O kubelet manda SIGTERM, espera o grace period (30 s por padrão) e só então SIGKILL. Um grace period de horas faz o pod ficar em Terminating por horas, de propósito.
O runtime não consegue desmontar um volume de rede. O container para, mas o pod não termina de sair.
Diagnóstico
Reproduzimos as duas causas principais no mesmo pod de teste: um finalizer de um controlador que não existe e, depois, o nó dele desligado.
1 · o pod segue em Terminating
kubectl -n loja get pod carrinhoNAME READY STATUS RESTARTS AGE
carrinho 1/1 Terminating 0 2m16s2 · há finalizer?
kubectl -n loja get pod carrinho -o jsonpath='{.metadata.deletionTimestamp} {.metadata.finalizers}{"\n"}'2026-09-25T22:44:36Z ["loja.internal/limpar-sessoes"]O finalizer loja.internal/limpar-sessoes espera um controlador que não está rodando. Antes de removê-lo, descubra o que ele deveria limpar: tirar o finalizer pula essa limpeza.
3 · em que nó ele está, e o nó responde?
kubectl -n loja get pod carrinho -o wide
kubectl get nodesA correção
Finalizer: o certo é corrigir o controlador que deveria removê-lo. Se ele não existe mais e a limpeza já foi feita à mão, remova o finalizer:
kubectl -n loja patch pod carrinho --type=json \
-p='[{"op":"remove","path":"/metadata/finalizers"}]'pod/carrinho patchedNo nosso teste, o pod continuou em Terminating mesmo sem finalizer: ele estava num nó desligado. Esse é o segundo caso.
kubectl -n loja get pod carrinhoNAME READY STATUS RESTARTS AGE
carrinho 1/1 Terminating 0 7m52sNó fora do ar: o melhor é recuperar o nó; ao voltar, o kubelet termina o que ficou pendente. Se o nó não volta, a remoção forçada tira o objeto da API sem esperar confirmação:
kubectl -n loja delete pod carrinho --grace-period=0 --forceWarning: Immediate deletion does not wait for confirmation that the running resource has been terminated.
The resource may continue to run on the cluster indefinitely.
pod "carrinho" force deleted from loja namespaceavisoO aviso do kubectl é literal: o container pode continuar rodando no nó. Em StatefulSet isso pode colocar duas instâncias com a mesma identidade escrevendo no mesmo volume. A documentação do Kubernetes pede cuidado redobrado com remoção forçada de pods de StatefulSet.
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.
Causa provável: o pod está no nó k3d-ia4code-lab-agent-0, que está NotReady; sem o kubelet, ninguém confirma o fim do container. Evidência: o pod segue em Terminating mesmo depois de removido o finalizer, e o nó não reporta status. Correção sugerida: recuperar o nó; se ele não volta e o pod não tem estado a proteger, remover à força.