Kubernetes v1.36: Evolução do Memory QoS e Proteção de Memória em Camadas

A gestão de recursos de memória em ambientes Kubernetes sempre foi um dos desafios mais críticos para squads de SRE e engenharia. Com a chegada do Kubernetes v1.36, o SIG Node promove um salto qualitativo no Memory QoS, refinando como o cgroup v2 interage com o kernel para proteger workloads estratégicos e evitar cenários indesejados de OOM killer.

O que muda na prática com o v1.36

Até a versão 1.27, o Memory QoS era, muitas vezes, visto como um mecanismo "tudo ou nada". Ao ativar a feature, proteções hard (memory.min) eram aplicadas indiscriminadamente, o que frequentemente resultava em subutilização do nó, pois uma grande parcela da memória era bloqueada permanentemente, impedindo que workloads BestEffort ou o próprio sistema operacional utilizassem o headroom disponível.

No v1.36, a grande mudança é a separação entre throttling (limitação de uso via memory.high) e reservation (proteção de memória via memory.min ou memory.low). A nova política de reserva em camadas (TieredReservation) introduz uma hierarquia lógica:

• Guaranteed Pods: Utilizam memory.min, garantindo uma proteção absoluta. O kernel é instruído a não realizar reclaim sob nenhuma circunstância.
• Burstable Pods: Utilizam memory.low, uma camada de proteção "soft". O kernel prioriza a retenção desses dados sob carga normal, mas permite o reclaim caso seja a única forma de evitar um panic sistêmico.
• BestEffort Pods: Sem proteção, mantendo a flexibilidade total de reclaim pelo kernel.

Essa abordagem é transformadora para empresas brasileiras que operam clusters multi-tenant ou que precisam densificar suas instâncias para reduzir custos de nuvem. Com o tiered protection, você consegue garantir SLA para suas aplicações core enquanto mantém a flexibilidade para o restante do cluster, evitando desperdício de recursos.

Observabilidade e Segurança

Além da lógica de reserva, o v1.36 expõe novas métricas via kubelet para facilitar o monitoramento em tempo real:

• kubelet_memory_qos_node_memory_min_bytes
• kubelet_memory_qos_node_memory_low_bytes

Esses dados são essenciais para capacity planning. Se a soma desses valores se aproximar da capacidade física do worker node, é um sinal claro de gargalo (ou de um erro de dimensionamento nos requests), permitindo atuação proativa antes que o OOM ocorra em produção.

Um ponto de atenção crucial é a verificação de kernel. O Memory QoS depende do memory.high do cgroup v2. Versões de kernel inferiores à 5.9 possuem bugs conhecidos de livelock nessa funcionalidade. O v1.36 agora inclui uma checagem de inicialização que alerta os administradores sobre a versão do kernel, mas vale o aviso: ambientes legados que não possuem kernel 5.9+ não devem ativar essa feature, sob risco de instabilidade grave.

Como implementar

Para adotar a nova política, a configuração via KubeletConfiguration deve ser ajustada para:

CopiarapiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
featureGates:
  MemoryQoS: true
memoryReservationPolicy: TieredReservation
memoryThrottlingFactor: 0.9

Esta mudança reflete a maturidade do ecossistema Kubernetes, movendo-se de modelos genéricos para uma orquestração de recursos cada vez mais próxima do hardware e das necessidades específicas de cada aplicação. Avaliar a adoção dessas políticas em ambiente de staging é o próximo passo recomendado para times que buscam maior previsibilidade e custo-eficiência.

---

Artigo originalmente publicado por (autor não identificado) em Kubernetes Blog.