Reinícios de Pods no Kubernetes: Quando Ocorrem e Quando Não

O Kubernetes 1.35 não só esclarece a distinção entre reinício e recriação de pods, com o UID como único indicador confiável, como entrega três novos mecanismos que transformam como operadores gerenciam ciclos de vida de contêineres: atualização de recursos no local (GA), reinício completo de todos os contêineres dentro do mesmo pod (Alpha) e políticas granulares de reinício por contêiner (Beta). Essas funcionalidades reduzem drasticamente a necessidade de recriações, que antes eram o único caminho para ajustar memória, corrigir falhas em múltiplos contêineres ou aplicar políticas de recuperação mais finas. O novo campo .metadata.generation também traz rastreabilidade real para operações de atualização, algo crítico em pipelines de CI/CD com verificação pós-deploy.

Antes da 1.35, qualquer alteração em requests/limits exigia recriação do pod, com perda de IP, rede e volumes efêmeros. Hoje, é possível escalar verticalmente sem interrupção. Já o recurso 'Restart All Containers' resolve um ponto cego antigo: reiniciar apenas um contêiner em um pod multi-contêiner pode deixar outros em estado inconsistente, mas recriar tudo era caro. Agora há uma terceira via, reinício atômico, com UID preservado e sem rescheduling.

Para equipes de plataforma, essa mudança reduz falsos positivos em alertas de 'pod reiniciando': agora é possível distinguir entre um contêiner em CrashLoopBackOff (UID constante, contagem incrementada) e um deployment sendo reconfigurado (UID novo, contagem zerada). Isso impacta diretamente dashboards de SLO, métricas de disponibilidade e diagnósticos de observabilidade. Para DevOps, significa menos dependência de workarounds como init containers para recuperação ou scripts externos para reinício coordenado, tudo agora está nativo na API do Pod v1.35.