A evolução do ecossistema de containers frequentemente traz mudanças sob o capô que, embora sutis, impactam diretamente a estabilidade e a performance de aplicações críticas. Recentemente, foi anunciada uma melhoria significativa na fórmula de conversão de cpu.shares (cgroup v1) para cpu.weight (cgroup v2).
Para empresas brasileiras que estão modernizando seus clusters Kubernetes e migrando para distribuições de Linux mais recentes (como Ubuntu 22.04+ ou RHEL 9), entender essa mudança é vital para evitar gargalos inesperados em situações de disputa de recursos.
O Contexto Técnico
Originalmente, o Kubernetes foi desenhado com foco no cgroup v1, onde as cpu.shares eram definidas de forma simples, mapeando os CPU requests do container em milicpu.
Por exemplo: um container com request de 1 CPU (1024m) recebia um valor de cpu.shares = 1024.
Com a ascensão do cgroup v2, o conceito mudou. Enquanto o range do cgroup v1 ia de 2 a 262.144, o cgroup v2 utiliza o cpu.weight, com um range muito mais estreito: de 1 a 10.000.
A transição inicial, definida pelo KEP-2254, adotou uma fórmula de conversão linear: cpu.weight = (1 + ((cpu.shares - 2) * 9999) / 262142).
Embora matematicamente simples, essa abordagem linear introduziu distorções estratégicas na priorização de workloads.
Os problemas da abordagem anterior
A fórmula linear gerava dois gargalos principais para times de infraestrutura:
1. Perda de prioridade contra processos do sistema
No cgroup v1, o valor padrão de 1024 garantia que um container com 1 CPU de request tivesse a mesma prioridade que processos do sistema operacional fora do Kubernetes. No cgroup v2, o padrão de mercado é um peso de 100. No entanto, a fórmula antiga convertia 1 CPU (1024m) para apenas cerca de 39.
Na prática, isso significava que, ao migrar para cgroup v2, seus workloads de Kubernetes perdiam 60% da sua força de prioridade contra daemons do sistema, o que pode ser desastroso em cenários de resource starvation.
2. Falta de granularidade para sub-cgroups
Para requests pequenos (ex: 100m), a fórmula resultava em um cpu.weight de apenas 4. Isso impede que engenheiros utilizem recursos avançados como a criação de sub-cgroups dentro de containers para distribuir prioridades entre diferentes processos internos.
A Nova Fórmula de Conversão
A solução adotada abandona a linearidade em favor de uma curva quadrática, projetada para garantir que o valor padrão de 1024 mapeie exatamente para 100, ajustando a prioridade com o sistema.
Esta função foi desenhada para garantir que:
- O valor mínimo (2) mapeie para 1.
- O valor padrão (1024) mapeie exatamente para 100.
- O valor máximo (262144) mapeie para 10.000.
Impactos e Adoção na Camada de OCI
É fundamental notar que essa mudança ocorre na camada do runtime de containers (OCI), e não diretamente no binário do Kubernetes. Portanto, a disponibilidade depende da atualização do seu runtime:
- runc: Disponível a partir da versão 1.3.2.
- crun: Disponível a partir da versão 1.23.
O que sua empresa deve observar:
Para gestores de TI e times de DevOps no Brasil, o alerta é sobre o monitoramento. Se você utiliza ferramentas customizadas para prever custos ou dashboards de observabilidade que validam o peso de CPU esperado, essas ferramentas precisarão ser ajustadas para a nova lógica.
A Nuvem Online recomenda que qualquer atualização de runtime em clusters produtivos seja precedida por testes em ambientes de staging, observando o comportamento de workloads com requests baixos e a coexistência com daemons de monitoramento do nó.
