cgroup v2 no Kubernetes: migre os nós sem atribuir à mudança poderes que ela não tem

O Kubernetes detalhou a transição para cgroup v2, cujo suporte é estável desde a versão 1.25.[5] Desde 1.35, failCgroupV1 é verdadeiro por padrão e impede o kubelet de iniciar em nós com cgroup v1.[5] O override ainda existe no 1.36, com remoção prevista no 1.38.[5] É uma dependência de upgrade que precisa ser descoberta antes da janela de manutenção.

O que muda para quem desenvolve

Os requisitos incluem sistema operacional configurado para v2, kernel 5.8 ou posterior, runtime compatível e alinhamento do driver de cgroup entre runtime e kubelet.[5] A descoberta automática do driver, estável desde Kubernetes 1.34, depende da chamada CRI RuntimeConfig disponível em containerd 2.0+ e CRI-O 1.28+.[5] Quando essa chamada está disponível, o valor do runtime prevalece sobre a configuração do kubelet.[5]

A migração também exige atenção a softwares que leem cgroupfs diretamente, incluindo JVMs, Node.js e bibliotecas Go sensíveis aos limites de CPU.[5] Minha leitura é que a aplicação participa da mudança: não basta validar que o nó entrou no cluster se o processo passou a interpretar recursos de outra maneira.

Em v2, singleProcessOOMKill é falso por padrão e o kubelet configura memory.oom.group para que um OOM mate todos os processos do contêiner, não necessariamente do Pod inteiro.[5] Essa distinção importa ao desenhar recuperação e supervisão. Um teste deve observar qual unidade morreu e como o serviço voltou, sem inferir o comportamento apenas pelo nome do recurso.

Como aplicar

Prepare um nó de teste que reproduza a combinação real de sistema, runtime e aplicação. Registre a configuração anterior e a desejada. Proponha três ensaios: CPU sob contenção, memória próxima do limite e recuperação depois de OOM.

Para cada ensaio, compare o pedido no objeto Kubernetes com o estado efetivado e os controles do kernel. cpu.weight representa prioridade derivada do request, cpu.max representa quota e período e memory.max representa o teto de memória.[5] Não trate um aumento de prioridade como aumento do limite.

Meça latência da aplicação, reinícios e contenção. Se o processo escolhe automaticamente quantidade de threads ou tamanho de heap, registre também essa decisão. O objetivo é produzir uma comparação operacional, não apenas comprovar que o diretório de cgroups mudou.

Separe a migração básica de experimentos com novos recursos. Mudar uma variável por vez facilita atribuir uma regressão ao componente certo.

Cuidados e limites

O kubelet continua tratando active_file como memória não recuperável; cargas intensivas em I/O podem sofrer pressão e eviction devido ao page cache mesmo em v2.[5] Portanto, a migração não é uma correção universal de memória.

Memory QoS permanece Alpha no Kubernetes 1.36, e o projeto não recomenda ativar recursos Alpha em produção sem avaliação e testes.[5] Suas reservas e throttling não devem ser confundidos com a simples adoção de cgroup v2.

O artigo não ensina a habilitar v2 em cada distribuição; essa etapa depende da documentação do sistema operacional.[5] Um checklist útil precisa incluir essa dependência e uma estratégia de reversão, em vez de prometer uma troca transparente para todos os nós.

Fonte

[5] Fonte: Kubernetes Blog. Data/hora no feed: 06/10/2026 às 15:00:00.