O projeto Kubernetes lançou em 26 de agosto de 2026 a versão 1.37, apelidada de Garhwal, com 67 melhorias: 16 promovidas a estáveis, 23 a beta, 27 novas em alfa e uma descontinuação. O ciclo durou 15 semanas, de 18 de maio a 26 de agosto, e reuniu contribuições de 1.754 pessoas de 212 empresas, segundo a equipe de lançamento. O primeiro patch, 1.37.1, saiu em 15 de setembro, e a série tem fim de suporte previsto para 28 de outubro de 2027, de acordo com a página da versão.

O que fica estável

A API metrics.k8s.io, que fornece o uso de CPU e memória de pods e nós para o HorizontalPodAutoscaler (HPA) e para o kubectl top, chega à versão estável depois de quase nove anos em beta; a v1beta1 segue disponível durante a transição. O KYAML, subconjunto mais estrito do YAML criado para manifestos do Kubernetes, também se torna estável, assim como o comando kubectl get -o kyaml. Manifestos existentes não precisam mudar. Outras promoções incluem certificados de pod e ClusterTrustBundles, o StorageVersionMigration embutido no plano de controle e recursos do Dynamic Resource Allocation (DRA), usados para alocar GPUs e interfaces de rede.

No servidor de API, a inicialização resiliente do watch cache foi concluída. Em vez de despejar listas pesadas sobre o etcd na partida ou na recuperação, o kube-apiserver passa a recusar parte das requisições com HTTP 429. A equipe recomenda que controladores e operadores respeitem o cabeçalho Retry-After e usem backoff exponencial.

Mudanças que afetam custo e clusters de IA

O HPA com escala a zero passa a beta e vem ligado por padrão. Com spec.minReplicas: 0 e métricas externas ou de objeto, cargas ociosas, como consumidores de filas, jobs em lote e serviços com GPU, podem ficar sem pods até a demanda voltar; métricas de CPU e memória não servem para esse fim. O gang scheduling, que só agenda um grupo de pods quando há recursos para todos, também chega ao beta, com preempção que considera a carga inteira, recurso voltado a treinamento de IA e HPC. O QoS de memória com cgroups v2 vira beta e fica habilitado por padrão.

O que sai de cena

A versão acelera a aposentadoria de componentes antigos. O modo ipvs do kube-proxy passa a emitir aviso de descontinuação na inicialização; a previsão é desativá-lo por padrão na 1.40 e removê-lo na 1.43, com nftables como caminho indicado. O kube-dns foi descontinuado em favor do CoreDNS, e não devem ser gerados novos pacotes dele depois da 1.40. Pods estáticos não podem mais referenciar Secrets ou ConfigMaps. Já o suporte a cgroups v1 segue em remoção: desde a 1.35, o kubelet não inicia nesses nós sem uma configuração explícita de exceção.

Como planejar a atualização

Para quem opera clusters, a recomendação prática é verificar o modo do kube-proxy, migrar do kube-dns e mapear nós ainda em cgroups v1 antes de atualizar. A ativação do SELinuxMount por padrão pode impedir que pods com rótulos SELinux diferentes compartilhem o mesmo volume em um nó; o projeto indica seLinuxChangePolicy: Recursive para manter o comportamento anterior. Serviços gerenciados de Kubernetes adotam novas versões em cronogramas próprios, que precisam ser consultados em cada provedor.

Em reportagem de 26 de agosto, o The Register destacou a limpeza de recursos legados como sinal de foco em estabilidade de produção e citou pesquisa da CNCF segundo a qual 82% dos usuários de contêineres rodam Kubernetes em produção. Os binários e o changelog completo estão na página da versão no GitHub.

Fontes

• Kubernetes (blog oficial) — Kubernetes v1.37: Garhwal (26/08/2026)
• Kubernetes — Kubernetes 1.37 (página da série de versões) (consultada em 08/10/2026)
• GitHub — kubernetes/kubernetes — Release v1.37.0 (26/08/2026)
• The Register — Kubernetes cleans house, bins legacy kube-dns, IPVS, and cgroup v1 (26/08/2026)

Imagem destacada: ilustração gerada por computador, sem valor documental.