Kubernetes 1.37 "Garhwal": Metrics API estável, KYAML e HPA escalando até zero

O Kubernetes v1.37, batizado de “Garhwal”, saiu em 26 de agosto de 2026. Segundo o anúncio oficial, a versão tem 67 melhorias: 16 graduadas para estável, 23 para beta, 27 entrando em alpha e uma deprecação ou remoção. O ciclo durou 15 semanas, de 18 de maio a 26 de agosto. Não é uma versão de grande ruptura, mas fecha várias pendências antigas e deixa avisos claros sobre o que vai sair.

Graduações para estável

A mais simbólica é a da Metrics API. O metrics.k8s.io chegou ao estável depois de quase nove anos em beta. Agora que existe a v1, as próximas versões do Kubernetes vão migrar para ela, e a v1beta1 continua utilizável durante a transição, seguindo a política de deprecação de APIs. Quem tem ferramentas lendo métricas de recursos não precisa correr, mas já pode planejar a troca.

O KYAML também ficou estável, com os testes de conformidade concluídos, e o kubectl get -o kyaml agora é estável. O anúncio faz questão de explicar que o KYAML é um subconjunto do YAML mais seguro e menos ambíguo, feito para o Kubernetes, e não um substituto: todo arquivo KYAML é YAML válido. Para quem já tropeçou em YAML interpretando valores de um jeito inesperado, é uma boa notícia.

Pod certificates e ClusterTrustBundles chegaram juntos ao estável. O fluxo é: você escolhe um nome de signer e implanta um controller que observa objetos PodCertificateRequest, emite e renova certificados para os Pods elegíveis e mantém os ClusterTrustBundle correspondentes. Os workloads entram nisso definindo um volume projetado podCertificate. Na prática, é identidade de workload com certificados de forma nativa, sem depender de ferramentas externas para o básico.

HPA escalando até zero

Para mim, a novidade mais prática é o scale-to-zero do HorizontalPodAutoscaler, que chegou ao beta e está habilitado por padrão. A ideia foi introduzida lá no v1.16 e só agora ficou pronta para uso amplo. Basta definir spec.minReplicas: 0, mas há uma restrição importante: vale apenas para workloads que usam métricas do tipo object ou external. Escalar até zero com base em CPU ou memória não é suportado, porque essas métricas dependem de Pods ativos.

Um exemplo de HPA para um worker que consome uma fila, usando uma métrica externa:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: worker
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: worker
  minReplicas: 0
  maxReplicas: 10
  metrics:
    - type: External
      external:
        metric:
          name: queue_messages_ready
        target:
          type: AverageValue
          averageValue: "30"

Enquanto está em zero, o HPA registra a condição ScaledToZero como True. Quando volta a escalar, ela passa para False com o motivo NotScaledToZero.

Outras graduações para beta

O gang scheduling chegou ao beta, usando a Workload API e o conceito de PodGroup. A estratégia é “tudo ou nada”: um grupo de Pods só é agendado quando o cluster tem recursos para o grupo inteiro, o que é exatamente o que cargas de treinamento distribuído precisam. O beta adiciona preempção ciente de workload e fila de PodGroups.

O controle de admissão baseado em manifestos também foi para beta. Webhooks de admissão e políticas CEL podem ser carregados de arquivos em disco, pelo campo staticManifestsDir no AdmissionConfiguration. Essas políticas valem desde o início do API server, continuam funcionando com o etcd indisponível e podem proteger os próprios recursos de admissão contra alteração.

E o etcd RangeStream, que reduz o uso de memória em listagens grandes, está em beta atrás do feature gate EtcdRangeStream, ligado por padrão. Ele exige etcd 3.7 ou superior; com versões anteriores, o kube-apiserver volta automaticamente para o Range tradicional.

O que está saindo

Três avisos merecem atenção. O kube-dns foi deprecado: o CoreDNS é o DNS padrão desde o v1.13, e a expectativa é que não sejam gerados novos pacotes do kube-dns depois do v1.40. O modo ipvs do kube-proxy agora emite aviso de deprecação na inicialização, deve ficar desabilitado por padrão no v1.40 e ser removido no v1.43. E o suporte a cgroup v1 continua dependendo de um override temporário (failCgroupV1: false no KubeletConfiguration), com remoção planejada para uma versão futura.

Minha leitura

O v1.37 é uma versão de manutenção no melhor sentido. O HPA com scale-to-zero ligado por padrão é o tipo de recurso que antes exigia ferramentas extras e agora vem no próprio cluster, desde que suas métricas sejam externas. A Metrics API estável, depois de quase uma década, e o KYAML mostram um projeto arrumando a casa.

O que eu faria agora: verificar se algum cluster ainda usa kube-dns, ipvs ou nós com cgroup v1. São migrações que não doem hoje, mas vão doer quando o prazo chegar.