EKS e EKS Distro já suportam Kubernetes 1.37

Desde 2 de outubro, é possível criar ou atualizar clusters EKS para a versão 1.37, que leva a Metrics API e os device taints do DRA para disponibilidade geral e estreia o scale-to-zero do HPA em beta.

A AWS confirmou em 2 de outubro de 2026 que o Amazon EKS e o Amazon EKS Distro passaram a suportar o Kubernetes 1.37. Quem opera cluster na AWS já pode criar clusters novos direto nessa versão ou atualizar os existentes pelo console do EKS, pela CLI do eksctl ou por uma ferramenta de infraestrutura como código. O suporte vale em todas as regiões onde o EKS está disponível, incluindo as regiões AWS GovCloud (US).

Para quem administra o ciclo de vida de clusters, a atualização por eksctl segue o fluxo de sempre, bastando apontar a versão alvo:

Nota da redação: o código desta seção não foi executado em ambiente real. Valide antes de usar em produção.

eksctl upgrade cluster --name meu-cluster --version 1.37 --approve

Antes de rodar o upgrade em produção, vale checar o EKS Cluster Insights no console: a ferramenta ajuda a identificar problemas que podem impactar a atualização do cluster.

Metrics API sai do beta eterno

A metrics.k8s.io/v1 foi promovida a disponibilidade geral no 1.37. Essa API é o que alimenta o kubectl top e o Horizontal Pod Autoscaler (HPA) com uso de CPU e memória de Pods e nós. Ela existia como beta há anos no ecossistema Kubernetes, então a mudança prática para quem já usa o metrics-server no EKS é mais sobre estabilidade de contrato de API do que sobre funcionalidade nova: ferramentas e integrações que dependiam do caminho beta podem migrar para a versão estável sem medo de quebra em um próximo release.

Para SRE e time de plataforma que mantém dashboards ou automações consumindo essa API diretamente (fora do HPA), é o momento de revisar se algum script ainda referencia o caminho beta e trocar pela v1 assim que o metrics-server do cluster acompanhar a mudança.

DRA ganha taints e tolerations em GA

O Dynamic Resource Allocation (DRA), mecanismo para alocar recursos de hardware especializado como GPU de forma dinâmica, recebeu em GA o suporte a taints e tolerations em dispositivos. Na prática, isso significa que drivers de DRA e administradores de cluster podem marcar (taint) um dispositivo, como uma GPU com falha de hardware ou reservada para um workload específico, e o scheduler do Kubernetes vai evitar agendar Pods nesse dispositivo a menos que o Pod declare uma toleration explícita.

Para quem roda workload de machine learning ou HPC em node group com GPU no EKS, esse recurso resolve um problema real: isolar GPUs degradadas ou reservadas sem precisar tirar o nó inteiro de circulação. O padrão segue o mesmo modelo de taint/toleration já usado em nós desde as versões mais antigas do Kubernetes, só que agora aplicado a dispositivos individuais dentro do nó.

HPA com scale-to-zero, em beta e já ligado por padrão

O recurso mais visível para quem lida com custo de workload é o scale-to-zero do Horizontal Pod Autoscaler, que avança para beta e vem habilitado por padrão no 1.37. Com ele, um HPA configurado com minReplicas: 0 e que usa métricas de objeto (object metrics) ou métricas externas (external metrics) pode reduzir um Deployment a zero Pods quando não há demanda, e voltar a escalar quando o tráfego retorna.

Um exemplo típico de manifesto que passa a funcionar de ponta a ponta:

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

Isso é relevante para quem roda worker de fila, job batch ou qualquer serviço com tráfego em rajada no EKS: com o scale-to-zero nativo do HPA em beta, times que já usam métricas externas (SQS, CloudWatch, Prometheus) por meio de um Metrics Adapter ganham esse comportamento sem adicionar outro componente ao cluster, ainda que o recurso continue em beta e caiba testar bem antes de depender dele em produção.

O que muda na operação do dia a dia

Em resumo: a versão 1.37 não traz ruptura de API para a maioria dos clusters, mas consolida três recursos que já vinham amadurecendo no upstream do Kubernetes. Nenhuma das três mudanças é exclusiva do EKS; a AWS está apenas distribuindo o que o projeto Kubernetes já liberou.

As builds do EKS Distro para a 1.37 estão publicadas no ECR Public Gallery e no GitHub, para quem roda Kubernetes fora do EKS gerenciado mas quer o mesmo conjunto de patches e versões que a AWS testa. A política de ciclo de vida de versões do EKS, que determina até quando cada versão recebe suporte padrão e suporte estendido, está documentada à parte e vale consultar antes de planejar a janela de upgrade.

Fica em aberto, por ora, quando o scale-to-zero do HPA deve sair do beta e virar GA, e se a AWS vai expor alguma métrica própria do CloudWatch Container Insights específica para acompanhar esse comportamento de zero-to-N. Nenhuma das duas informações consta no anúncio da AWS.

Fonte 1: AWS What's New (https://aws.amazon.com/about-aws/whats-new/2026/10/amazon-eks-distro-kubernetes-version-1-37/)

Amazon EKS and Amazon EKS Distro now support Kubernetes version 1.37 - AWS

Skip to main content

Amazon EKS and Amazon EKS Distro now support Kubernetes version 1.37

Posted on: Oct 2, 2026

Kubernetes version 1.37 introduced several new features and bug fixes, and AWS is excited to announce that you can now use Amazon Elastic Kubernetes Service (EKS) and Amazon EKS Distro to run Kubernetes version 1.37. Starting today, you can create new EKS clusters using version 1.37 and upgrade existing clusters to version 1.37 using the EKS console, the eksctl command line interface, or through an infrastructure-as-code tool.

Kubernetes version 1.37 introduces several key improvements, promoting the Metrics API to general availability as metrics.k8s.io/v1 . This API provides Pod and node CPU and memory usage for the Horizontal Pod Autoscaler and kubectl top . Dynamic Resource Allocation (DRA) device taints and tolerations also graduate to general availability, letting DRA drivers and administrators taint devices such as GPUs so the scheduler avoids them unless tolerated.

Horizontal Pod Autoscaler scale-to-zero graduates to beta and is enabled by default, allowing autoscalers with minReplicas: 0 that use object or external metrics to scale workloads to zero Pods when idle and back up when demand returns. To learn more about Kubernetes version 1.37, see our documentation and the Kubernetes project release notes.

EKS now supports Kubernetes version 1.37 in all the AWS Regions where EKS is available, including the AWS GovCloud (US) Regions.

You can learn more about the Kubernetes versions available on EKS and instructions to update your cluster to version 1.37 by visiting EKS documentation. You can use EKS cluster insights to check if there are any issues that can impact your Kubernetes cluster upgrades. EKS Distro builds of Kubernetes version 1.37 are available through ECR Public Gallery and GitHub. Learn more about the EKS version lifecycle policies in the documentation .

Fonte: AWS What's New