Kubernetes v1.35: Novo patamar de eficiência com o reinício de Pods in-place

O lançamento do Kubernetes 1.35 introduz uma funcionalidade poderosa que atende a uma demanda antiga da comunidade: a capacidade de disparar um restart completo de um Pod in-place. Este recurso, chamado Restart All Containers (em estágio alpha na v1.35), oferece uma maneira eficiente de resetar o estado de um Pod em comparação à abordagem tradicional — e faminta por recursos — de deletar e recriar todo o objeto.

Esta funcionalidade é especialmente valiosa para workloads de AI/ML, permitindo que desenvolvedores foquem na lógica central de treinamento enquanto delegam mecanismos complexos de recuperação de falhas para sidecars e configurações declarativas do Kubernetes. Com o RestartAllContainers e outros aprimoramentos planejados, o ecossistema reforça sua posição como a base mais flexível e robusta para processamento de dados em larga escala.

O novo recurso pode ser ativado via feature gate RestartAllContainersOnContainerExits. Ele estende a funcionalidade de Container Restart Rules, que evoluiu para beta nesta mesma versão.

O problema: quando o restart de um único container não basta e o custo de recriação é alto

O Kubernetes suporta há tempos políticas de restart no nível do Pod (restartPolicy) e, recentemente, no nível individual de containers. Embora eficazes para falhas isoladas, muitas aplicações modernas possuem dependências complexas entre containers. Considere os cenários:

1. Um init container prepara o ambiente montando um volume ou gerando um arquivo de configuração. Se o container principal corromper esse ambiente, reiniciá-lo isoladamente não resolve; todo o processo de inicialização deve ser reexecutado.
2. Um watcher sidecar monitora o health do sistema. Se detectar um erro recuperável que exige um "limbo zero", ele precisa resetar o container da aplicação principal a partir de um estado limpo.
3. Um sidecar que gerencia um recurso remoto falha. Mesmo que ele reinicie sozinho, o container principal pode ficar travado tentando usar uma conexão obsoleta ou quebrada.

Anteriormente, a única solução era deletar o Pod para que um controller (como um Job ou ReplicaSet) criasse um novo. Para empresas brasileiras operando clusters densos, esse processo é lento e caro: envolve o scheduler, alocação de recursos no nó e reinicialização de networking e storage.

Essa ineficiência é ampliada em workloads de AI/ML em escala (mais de 1.000 nós). Em jobs síncronos, uma falha em um único nó pode exigir que todos os Pods da frota sejam recriados para resetar o estado. O overhead de deletar, criar e agendar milhares de Pods simultaneamente cria um gargalo massivo. Estima-se que esse desperdício de recursos possa custar até US$ 100.000 por mês em infraestruturas de grande porte.

Ao manter os Pods em seus nós designados, o reinício in-place permite otimizações como o caching no nível do nó atrelado à identidade do Pod, algo impossível quando os Pods são movidos para outros hosts sem necessidade.

Apresentando a ação RestartAllContainers

Para resolver isso, o Kubernetes v1.35 adiciona a ação RestartAllContainers às regras de reinício. Quando um container encerra sua execução de forma que corresponda a uma regra com essa ação, o kubelet inicia um restart rápido e localizado do Pod.

Este restart é altamente eficiente pois preserva os recursos mais críticos:

• O UID do Pod, endereço IP e network namespace.
• O sandbox do Pod e quaisquer dispositivos (devices) anexados.
• Todos os volumes, incluindo emptyDir e mounts de PVCs.

Após encerrar todos os containers em execução, a sequência de inicialização é reexecutada do zero. Isso significa que todos os init containers rodam novamente na ordem correta, garantindo um ambiente íntegro. Com exceção de containers efêmeros, todos os outros — incluindo os que tiveram sucesso ou falha anteriormente — serão reiniciados, independentemente de suas políticas individuais.

Casos de Uso Estratégicos

1. Eficiência para Jobs de ML e Batch

Em clusters de treinamento de modelos, o reagendamento de um worker pod é uma operação custosa. Com a estratégia híbrida permitida pelo RestartAllContainers, você pode recriar apenas os Pods em nós realmente instáveis e disparar o reinício apenas interno nos Pods saudáveis. Benchmarks indicam que isso reduz o tempo de recuperação de minutos para poucos segundos.

Um container watcher pode agora monitorar o processo principal e, ao encontrar um erro específico, sair com um exit code designado para resetar o Pod localmente, sem acionar o Controller do Job. Esse fluxo agora é nativo.

Copiarapiversion: v1
kind: Pod
metadata:
  name: ml-worker-pod
spec:
  restartPolicy: Never
  initContainers:
  # Este init container será reexecutado em cada reinício in-place
  - name: setup-environment
    image: my-repo/setup-worker:1.0
  - name: watcher-sidecar
    image: my-repo/watcher:1.0
    restartPolicy: Always
    restartPolicyRules:
    - action: RestartAllContainers
      exitCodes:
        operator: In
        values: [88] # Código específico que dispara o restart total
  containers:
  - name: main-application
    image: my-repo/training-app:1.0

2. Reexecução de Init Containers para Estado Limpo

Se um init container busca credenciais ou configura um volume compartilhado que acaba sendo corrompido pela aplicação principal, o RestartAllContainers garante que a configuração limpa seja refeita antes do novo ciclo da aplicação.

3. Processamento de Alta Rotatividade

Cenários como backends de sessões de jogos ou filas de processamento rápido, onde cada tarefa exige um ambiente zerado, se beneficiam enormemente. Evita-se o ciclo completo de criação e agendamento de Pods, reduzindo a latência operacional.

Como Implementar e Observar

Para testar, ative o feature gate RestartAllContainersOnContainerExits no API Server e no kubelet. A regra de restartPolicyRules pode ser aplicada a qualquer container.

Atenção operacional: Certifique-se de que seus containers sejam reentrantes (capazes de processar o reinício sem efeitos colaterais negativos). Note que o kubelet não executa hooks de preStop nesta ação; portanto, a aplicação deve ser desenhada para lidar com terminações abruptas.

A observabilidade é garantida por uma nova condição de Pod: AllContainersRestarting. Ela fica True durante o processo e retorna a False quando o Pod está pronto para reiniciar seu ciclo de vida. Além disso, o contador de reinícios no status do container será incrementado.

---

Artigo originalmente publicado por Yuan Wang, Giuseppe Tinti, Tomio, Sergey Kanzhelev em Kubernetes Blog.