O que chegou no Kubernetes 1.37
O Kubernetes v1.37, batizado de “Garhwal” em referência a uma região do Himalaia indiano, foi lançado em agosto de 2026 e está agora em fase de adoção ativa. O release traz 67 melhorias no total: 16 graduaram para Stable (GA), 23 para Beta e 27 entraram em Alpha. Para times de operação e plataforma, os destaques mexem diretamente no dia a dia de quem gerencia clusters em produção.
Redimensionamento in-place de pods
Uma das funcionalidades mais aguardadas finalmente avança: a possibilidade de alterar limites de CPU e memória de um pod em execução, sem precisar recriá-lo. Essa capacidade, conhecida como in-place pod resize, elimina a necessidade de restart para ajustes de recursos. O benefício é especialmente grande em workloads que mantêm estado em memória ou que têm tempo de inicialização longo.
Na prática, equipes que operam clusters com aplicações Java, bancos de dados ou modelos de machine learning ganham uma ferramenta para fazer ajustes finos sem interrupção de serviço. É o tipo de melhoria que não aparece em benchmarks, mas reduz toil operacional todos os dias.
HPA com scale-to-zero em Beta
O HorizontalPodAutoscaler agora pode reduzir workloads a zero réplicas quando ociosos, restaurando-os quando a demanda volta. O recurso, habilitado por padrão nesta versão, funciona com métricas de objetos e métricas externas (não com CPU/memória, que dependem de pods ativos).
O impacto no custo é direto. Consumidores de filas, jobs batch e workloads de GPU que ficam inativos por períodos podem ser zerados automaticamente, liberando recursos do cluster. Quando a métrica retorna, o HPA escala de volta. Uma condição ScaledToZero no status do HPA distingue o scale automático de uma desativação manual.
DRA em GA para GPUs e aceleradores
A API de Dynamic Resource Allocation (DRA) graduou para GA, formalizando o mecanismo pelo qual pods solicitam acesso a recursos como GPUs, FPGAs e outros aceleradores de hardware. Para organizações que rodam inferência de modelos ou treinamento distribuído em Kubernetes, o DRA elimina gambiarras com device plugins e oferece uma interface padronizada para alocação de recursos especializados.
Gang scheduling para cargas de IA
O release avança o suporte a gang scheduling, mecanismo que garante que todos os pods de um grupo iniciem simultaneamente. Esse padrão é crítico para workloads de machine learning distribuído (como treinamento com AllReduce), onde um pod esperando os demais significa desperdício de GPUs caras ociosas. A combinação de DRA em GA com gang scheduling posiciona o Kubernetes como plataforma padrão para orquestrar workloads de IA, não apenas aplicações web tradicionais.
Outras melhorias relevantes para operação
- Resilient watchcache initialization (Stable): o API server agora inicializa o cache de forma mais robusta, evitando picos de tráfego contra o etcd durante startup ou recovery. Em clusters grandes, isso reduz o risco de outages no control plane. Clientes (incluindo controllers customizados) devem tratar respostas HTTP 429 com backoff exponencial.
- Manifest-based admission control (Beta): webhooks e políticas CEL podem ser carregados de arquivos em disco, garantindo enforcement desde o boot do API server e independente da disponibilidade do etcd.
- Pod checkpoint e restore (Alpha): novas RPCs no CRI permitem salvar e restaurar o estado de pods no nível do kubelet, avançando cenários de migração e recuperação de desastres.
- Migração para nftables: o tráfego de rede do kube-proxy progride na transição de IPVS/iptables para nftables, alinhando o Kubernetes com a direção do ecossistema Linux.
O que observar daqui
O Kubernetes 1.37 não traz uma revolução arquitetural, mas consolida funcionalidades que times de plataforma pediam há anos. O resize in-place de pods e o scale-to-zero do HPA são melhorias de operação que se pagam em estabilidade e redução de custo no dia a dia.
Para organizações que estão levando IA para produção em clusters Kubernetes, a combinação de DRA em GA com gang scheduling é o sinal mais claro de que a plataforma está amadurecendo para esse tipo de workload. Times que planejam rodar inferência ou treinamento em clusters compartilhados devem avaliar o upgrade para o 1.37 assim que o ciclo de testes permitir.