No dia a dia de uma operação de SRE ou DevOps, o termo "o pod reiniciou" é frequentemente usado de forma genérica, o que pode mascarar diagnósticos críticos. Em ambientes complexos com Kubernetes 1.35+, essa imprecisão compromete a qualidade dos nossos runbooks e a assertividade em incidentes de madrugada.
O problema da terminologia
Engenheiros frequentemente confundem estados distintos do ciclo de vida de uma carga de trabalho. Para evitar diagnósticos errados, precisamos separar o que é um evento dentro do mesmo Pod Object e o que envolve a sua total destruição e recriação.
| Termo | UID muda? | IP muda? | Restart Count |
| Container restart | Não | Não | +1 |
| Pod recreation | Sim | Sim | Reset para 0 |
| In-place resize - CPU | Não | Não | 0 |
| In-place resize - memória | Não | Não | +1 (dependendo do resizePolicy) |
A regra de ouro: Se o Pod UID mudou, houve recreação. Se o UID é o mesmo e o restartCount subiu, ocorreu um reinício de processo dentro do container.
O insight principal: O que o Kubelet realmente monitora
O kubelet observa exclusivamente o pod spec. Alterações em ConfigMaps, Secrets ou CRDs de service mesh (como Istio) não disparam, por si sós, uma ação do kubelet. Se o pod spec permanece inalterado, o container continuará rodando com as configurações antigas, gerando aquele comportamento inconsistente onde a aplicação parece "ignorar" o update no cluster.
Matriz de Decisão
Este fluxo de decisão é fundamental para times de plantão (on-call) que precisam identificar rapidamente a natureza de uma alteração:
| Alteração | Reinicia Container? | Recria Pod? | Automático? |
| Imagem de Container | Sim | Sim | Sim (Deployment controller) |
| Env var | Sim | Não | Rollout manual |
| ConfigMap (volume mount) | Decisão da app | Não | Parcial (inotify) |
| ConfigMap (envFrom) | Sim | Não | Rollout manual |
| CPU resize (K8s 1.35+) | Nunca | Não | Patch manual |
| Node drain / eviction | Sim | Sim | Sim |
Cenário 1: ConfigMap — A diferença crítica entre Env Vars e Volume Mounts
O uso de variáveis de ambiente (envFrom) tem um efeito "congelante". Como a variável é injetada no execve() do processo, ela é imutável até que o processo respawne. Já os volume mounts funcionam via troca atômica de symlinks pelo kubelet.
Se sua aplicação busca recarregar configurações via inotify, lembre-se: kubelet não modifica o arquivo, ele aponta o symlink para um novo diretório. Monitore o diretório e não o arquivo específico.
Considerações de resize (K8s 1.35+)
O redimensionamento in-place é um salto em eficiência, mas requer atenção ao resizePolicy. O padrão para memória é NotRequired, o que significa que se você não definir explicitamente RestartContainer, o Kubernetes ajustará o limite do cgroup, mas sua JVM ou runtime pode continuar operando com o heap antigo e subutilizado.
Conclusão: Disponibilidade vs. Visibilidade
Hot-reloads otimizam a disponibilidade, mas podem mascarar erros de configuração que só apareceriam em um reinício forçado. O segredo de uma operação resiliente é saber quando deixar o processo rodar sob nova configuração e quando exigir um clean restart para garantir a integridade do estado da aplicação.
Artigo originalmente publicado por Shamsher Khan, Project Maintainer em Cloud Native Computing Foundation.
