Kubernetes 1.37 'Garhwal': Alocação Dinâmica de Recursos Vira GA e Muda Como Você Pede GPU

O Kubernetes 1.37, codinome 'Garhwal', foi lançado em 26 de agosto de 2026 com 67 melhorias entre stable, beta e alpha. Uma semana depois, em 3 de setembro, o blog oficial publicou um post dedicado só à Dynamic Resource Allocation (DRA) anunciando a graduação da API para General Availability — a mudança mais relevante do ciclo para quem roda cargas de IA/ML em cluster.

O que é DRA e por que GA importa

Dynamic Resource Allocation resolve um problema que o modelo antigo de requests/limits nunca resolveu bem: pedir hardware especializado — GPU, FPGA, NIC de alta performance — de forma flexível, compartilhada entre pods e com reconfiguração em tempo de execução. Antes do DRA, compartilhar uma GPU entre múltiplos pods exigia device plugins customizados e workarounds frágeis por fabricante. Com a API estável, drivers de terceiros (NVIDIA, Intel, etc.) podem expor exatamente as capacidades que seus dispositivos suportam, e o scheduler do Kubernetes decide alocação com base nisso — nativamente, sem gambiarra.

• GPU fracionada e compartilhada entre pods sem device plugin proprietário obrigatório
• Alocação declarativa via ResourceClaim e ResourceClass, seguindo o mesmo espírito de PersistentVolumeClaim para storage
• Reconfiguração em runtime: um claim pode ser atualizado sem recriar o pod inteiro
• Melhor telemetria de uso de hardware especializado, essencial para custo de clusters de treinamento e inferência de IA

Outras mudanças do 1.37 que afetam operação do dia a dia

Além do DRA, o ciclo trouxe melhorias na inicialização do API server (redução de tempo de boot em clusters grandes), suporte expandido a KYAML (uma variante de YAML mais previsível para manifests) e PVCs baseados em manifesto para fluxos GitOps. A recomendação prática de quem já testou em produção: o 1.37 em si costuma ser tranquilo de adotar, mas o prazo real que importa é o suporte a containerd — versões antigas do runtime ficam incompatíveis com features que dependem de CRI mais recente, e é isso que quebra upgrades silenciosamente.

# Exemplo simplificado de ResourceClaim (DRA GA, k8s 1.37)
apiVersion: resource.k8s.io/v1
kind: ResourceClaim
metadata:
  name: gpu-fracionada
spec:
  devices:
    requests:
      - name: gpu
        deviceClassName: nvidia-shared
        count: 1

Checklist de upgrade

• Confirme a versão do containerd/CRI antes de planejar o upgrade — é o requisito mais comum de quebrar silenciosamente
• Se você já usa device plugins customizados para GPU, mapeie a migração para ResourceClaim/ResourceClass antes de depender de DRA em produção
• Revise Ingress: se ainda não migrou do Ingress-Nginx (aposentado desde o 1.36), a Gateway API é o caminho oficial daqui pra frente
• Rode o upgrade primeiro num cluster de staging com carga representativa — DRA GA não significa zero surpresa em clusters heterogêneos