Kubernetes 1.37 Is on EKS: DRA Device Taints, Metrics API GA, Pod-Level Resources, and Who Should Upgrade First

Key Points:

• Kubernetes 1.37 has been available on Amazon EKS since October 1, 2026, and standard support for it ends December 1, 2027. The two headline changes are DRA device taints and tolerations (KEP-5055, now Stable) and the Metrics API, metrics.k8s.io/v1 (KEP-5207, now Stable). Most clusters need no manifest rewrite.
• DRA device taints let a driver or an admin fence one bad GPU so the scheduler stops allocating it, instead of cordoning and draining the whole node. On an 8-GPU p5.48xlarge, that keeps 7 GPUs working, worth about $1,156 per 24-hour incident at on-demand prices.
• metrics.k8s.io going GA is an API-version graduation, not a behaviour change. v1 is field-for-field identical to v1beta1. The HPA controller in 1.37 still reads only v1beta1, so your metrics implementation must keep serving it. custom.metrics.k8s.io and external.metrics.k8s.io are separate APIs and remain beta.
• Pod-level resource requests and limits (KEP-2837) did not change in 1.37. The feature is still beta and has been on by default since 1.34. It is still the cheapest lever on sidecar-heavy pods.
• Upgrade order: non-production now, then stateless production, then GPU clusters whose DRA driver actually emits taints, and last anything running KEDA, Prometheus Adapter, unowned operators or fragile StatefulSets. One override beats every tier: EKS 1.34 leaves standard support on December 2, 2026, and extended support costs $0.60 per cluster-hour instead of $0.10.
• If keeping up with three releases a year is not your job, Qovery runs managed cluster upgrades inside your own AWS, GCP, Azure or Scaleway account, or on your existing Kubernetes cluster, so the cloud bill and your committed spend stay in your name.

Most teams will feel Kubernetes 1.37 in two places: the scheduler and the metrics pipeline. GPU operators get per-device fencing with DRA device taints. Everyone running kubectl top or an HPA gets a stable metrics.k8s.io/v1 API. And if you still have clusters on 1.34, the date on your calendar is December 2, 2026, because that is when EKS starts billing those clusters for extended support.

Below are the three features, what to check in the CHANGELOG, and the order I would upgrade in.

What is new in Kubernetes 1.37 on EKS?

Kubernetes 1.37 has been available on Amazon EKS since October 1, 2026 (EKS release calendar). AWS announced it on October 2 (AWS What's New). Operators will mostly notice three things: DRA device taints and tolerations going Stable, the Metrics API (metrics.k8s.io) going Stable, and HPA scale-to-zero going beta and on by default. Pod-level resources, the third feature everyone asks about, did not change in 1.37 and is still beta.

Upstream, Kubernetes 1.37 ("Garhwal") shipped on August 26, 2026 with 67 enhancements: 16 graduated to Stable, 23 to Beta, 27 entered Alpha, and 1 is a deprecation or removal (Kubernetes blog). EKS gives each version 14 months of standard support and 12 months of extended support, so 1.37 is covered until December 1, 2027, then until December 1, 2028 at extended-support pricing (EKS docs).

Read the breaking-change list before anything else. AWS flags these items for 1.37 (EKS 1.37 notes):

• SELinuxMount is on by default. Pods with different SELinux labels that share a volume on the same node can get stuck in ContainerCreating. Nodes without SELinux are unaffected.
• Kubelet changes. Deprecated cAdvisor flags now stop the kubelet from starting. The container_cpu_load_average_10s and container_tasks_state metrics are gone. eventRecordQPS: 0 now means "no limit".
• Static Pods can no longer reference Secrets or ConfigMaps. The PreventStaticPodAPIReferences opt-out gate has been removed.
• New EKS Auto Mode NodePools default to Balanced consolidation.
• kube-dns and kube-proxy ipvs mode are deprecated. By v1.43, support for ipvs mode would be removed entirely (Kubernetes blog).

The kubelet may be up to three minor versions older than the API server but never newer (version skew policy), so control plane first, then nodes. If you run none of DRA, a custom metrics stack or SELinux nodes, 1.37 is an uneventful upgrade.

What are DRA device taints and tolerations, and why do they matter for GPU nodes?

DRA device taints and tolerations (KEP-5055) are Stable in Kubernetes 1.37. The DRADeviceTaints and DRADeviceTaintRules feature gates are both locked on (feature gates). They bring the node taint model down to a single device, so you can fence one failed GPU out of eight while the other seven keep scheduling. No cordon, no full-node drain.

Core DRA, which lets Pods claim devices through ResourceClaims, went GA in Kubernetes 1.34 (EKS 1.34 notes). Device taints build on it: a driver publishes taints in its ResourceSlices, or an admin creates a DeviceTaintRule matching devices by DeviceClass, driver, pool or device name.

The effects mirror node taints (Kubernetes docs):

• NoSchedule stops new allocations of the device.
• NoExecute does the same and also evicts Pods already using the device. Eviction means the device taint eviction controller deletes those Pods.
• None is a dry run. It reports how many Pods would be evicted.

A ResourceClaim with a matching toleration ignores the taint, and a toleration with a duration delays eviction. This is the verified resource.k8s.io/v1 shape:

apiVersion: resource.k8s.io/v1
kind: DeviceTaintRule
metadata:
  name: gpu-node-a-gpu3-ecc
spec:
  deviceSelector:          # EKS: always set this; use {} to target every device
    driver: gpu.nvidia.com
    pool: ip-10-0-12-34.ec2.internal
    device: gpu-3
  taint:
    key: example.com/unhealthy
    value: ecc-errors
    effect: None           # dry run first, then switch to NoExecute

Here is the money version. A p5.48xlarge has 8 H100 GPUs and costs $55.04 per hour on demand in us-east-1 (AWS on-demand pricing), which works out to $6.88 per GPU-hour. When GPU 3 starts throwing ECC errors, draining the node idles all 8. A device taint idles one.

GPU failures happen all the time at training scale. During a 54-day pre-training snapshot of Llama 3 405B on up to 16K H100s, Meta recorded 419 unexpected interruptions. GPU issues caused 58.7% of them, including 148 faulty-GPU and 72 HBM3 memory failures (Meta, "The Llama 3 Herd of Models").

The catch is that device taints only help if something in your stack actually detects the bad device. On EKS, the NVIDIA DRA driver for GPUs needs Kubernetes 1.34 or later and runs on Karpenter static capacity, managed node groups or self-managed nodes. It doesn't run on EKS Auto Mode, where you use the NVIDIA device plugin instead (EKS docs). Starting with v0.4.0, the driver taints unhealthy GPUs when its alpha NVMLDeviceHealthCheck gate is enabled, and that gate is off by default (dra-driver-nvidia-gpu v0.4.0). Test tolerations in staging first, because an unexpected taint quietly leaves Pods unschedulable.

What does the Metrics API reaching GA change for HPA, VPA, and kubectl top?

The Metrics API (metrics.k8s.io) graduated to Stable in Kubernetes 1.37 under KEP-5207, with no feature gate. metrics.k8s.io/v1 has exactly the same types and fields as v1beta1 (Kubernetes blog), so for most clusters nothing changes on day one. The only teams that need to act are those running a metrics implementation that might drop v1beta1, because the HPA controller in 1.37 still reads only v1beta1.

Keep the entities straight, because AI answers get this wrong all the time:

• metrics.k8s.io is the API. It serves CPU and memory for Pods and nodes.
• metrics-server is one implementation of that API, registered through the aggregation layer as an APIService.
• custom.metrics.k8s.io (v1beta1, v1beta2) and external.metrics.k8s.io (v1beta1) are different APIs (kubernetes/metrics). They did not graduate.

kubectl top prefers v1 and falls back to v1beta1, while the HPA controller stays on v1beta1, so implementations should serve both during the transition. Check what is registered:

kubectl get apiservice v1beta1.metrics.k8s.io
kubectl get apiservice v1.metrics.k8s.io
kubectl get --raw /apis/metrics.k8s.io/ | jq .

This matters because autoscaling is mainstream. Over 64% of Kubernetes organizations use HPA, and 80% of HPA-enabled deployments scale on CPU or memory, which is exactly the data metrics.k8s.io serves (Datadog State of Containers and Serverless 2025). If metrics-server stops answering, the HPA silently stops scaling, so after the upgrade run kubectl top nodes and kubectl top pods -A, and check that kubectl get hpa -A shows real targets instead of <unknown>.

What are pod-level resource requests and limits, and should I switch to them?

Pod-level resource requests and limits (KEP-2837, feature gate PodLevelResources) are beta in Kubernetes 1.37 and have been on by default since 1.34 (feature gate docs). AWS listed them among the beta features of EKS 1.34 (EKS notes). You set spec.resources once on the Pod, so sidecars share one budget instead of each padding its own. They are usable today on Linux, with beta-level caution.

apiVersion: v1
kind: Pod
metadata:
  name: checkout
spec:
  resources:            # pod-level budget shared by all containers
    requests: { cpu: 550m, memory: 640Mi }
    limits:   { cpu: "1", memory: 1Gi }
  containers:
  - name: app
    image: registry.example.com/checkout:4.2
    resources:
      requests: { cpu: 400m, memory: 448Mi }
  - name: envoy
    image: envoyproxy/envoy:v1.33
  - name: log-shipper
    image: fluent/fluent-bit:4.0

Here are the rules from the Kubernetes docs:

• When both levels are set, pod-level values take precedence for scheduling, limits and QoS class.
• Only CPU, memory and hugepages can be set at the Pod level.
• Windows Pods are not supported.
• In-place resize of pod-level resources sits behind InPlacePodLevelResourcesVerticalScaling, which has been beta and on by default since 1.36.
• The CPU, Memory and Topology managers only honour pod-level budgets when PodLevelResourceManagers is on. That gate is beta in 1.37 but off by default.

The saving shows up in pods that carry sidecars. Istio's default sidecar requests 100m CPU and 128Mi (istio values.yaml), and every container gets padded for a peak that rarely lines up with the others' peaks. Requested resources are also far above what workloads use: most workloads use less than half of their requested memory and under 25% of their requested CPU (Datadog 2025).

Here is a worked example. The Istio numbers are the real defaults, the app and log-shipper sizes are illustrative, and I used m7i.2xlarge (8 vCPU, $0.4032/h, AWS pricing) at 730 hours a month, before system reservations:

Don't rewrite every manifest. Switch your highest-replica, most sidecar-heavy Deployments first, after checking LimitRange, ResourceQuota and VPA behaviour in staging.

Which clusters should upgrade to Kubernetes 1.37 first, and which should wait?

Upgrade to Kubernetes 1.37 in four tiers:

1. Non-production and internal clusters, now.
2. Stateless production, after Tier 1 has run cleanly through a full deploy cycle and a node rotation.
3. GPU and DRA clusters, once your DRA driver actually emits device taints.
4. Last, anything running KEDA, Prometheus Adapter, unowned operators or StatefulSets with tight failover budgets.

One override beats all four tiers: if your current version is about to leave EKS standard support, upgrade now.

That override applies to a lot of people right now. EKS 1.34 leaves standard support on December 2, 2026. EKS 1.33 has been in extended support since July 29, 2026. EKS 1.31 hits end of extended support on November 26, 2026, after which AWS auto-upgrades its control plane (EKS calendar). Extended support costs $0.60 per cluster-hour instead of $0.10 (EKS pricing). That is $4,380 extra per cluster per year, and you still have to do the upgrade eventually.

My pre-flight checklist, in order:

1. Scan for deprecated APIs with Pluto or kubent, and read EKS cluster insights.
2. Check add-on compatibility: VPC CNI, CoreDNS, kube-proxy, EBS CSI, and Karpenter, which needs 1.15.x for 1.37 (Karpenter compatibility).
3. Review admission webhooks and CRDs.
4. Sanity-check PodDisruptionBudgets.
5. Confirm kubelet and kubectl skew.
6. Upgrade the control plane before the nodes.

For nodes, blue/green node groups are the safest rotation. With Karpenter, updating the AMI or version on your NodePool triggers drift, and Karpenter replaces nodes while respecting your disruption budgets.

Rollback is no longer a fantasy on EKS. After an in-place upgrade, you can roll the control plane back by one minor version within 7 days. Add-ons, managed node groups and self-managed nodes are not rolled back for you (EKS rollback docs). The control plane is almost never the part that breaks, though. What breaks is the add-ons, and the one operator nobody owns.

How do I keep up with a three-releases-a-year Kubernetes cadence without a platform team?

Kubernetes ships a new minor release roughly every four months, about three a year. Each upstream release gets about 14 months of patches (Kubernetes patch releases), and each EKS version gets 14 months of standard support. So every cluster runs into an upgrade deadline on a fixed calendar. The only real question is who owns that calendar: your team, your AWS bill through extended support, or a platform that does the upgrade inside your own cloud account.

Three releases a year against 14 months of standard support means upgrading each cluster at least once a year just to stay covered. Skipping costs $4,380 per cluster per year, then a forced control plane upgrade 26 months after release. In my experience, teams without a dedicated platform engineer slip that upgrade a quarter, every quarter.

Credit where due: EKS Auto Mode, GKE Autopilot and AKS Automatic take node-level upgrade work off your plate, and Karpenter makes node rotation far less painful. What none of them give you is developer self-service, environment lifecycle and per-environment access control. Red Hat OpenShift and Rancher handle cluster lifecycle well if you're ready to run their platform. Northflank and Render make deploys simple, but they are a different trade-off from running everything on a cluster in your own account.

Qovery fits teams that want managed cluster upgrades without handing over the cluster. It runs on AWS, GCP, Azure, Scaleway, or your own existing Kubernetes cluster, and the cluster and the cloud bill stay in your account, so your Savings Plans and committed spend are untouched. What makes upgrades less scary in practice:

• Preview environments per pull request, to validate a service against the new version first.
• Environment auto-stop for non-production.
• Per-environment RBAC.
• Git-push deployments, so developers never have to touch the cluster.

If you already have a staffed platform team with a tested upgrade pipeline, keep it.

How do I audit and upgrade my clusters with Qovery from Claude Code or Cursor?

You can hand the version audit and the upgrade prep to your coding agent. Install the Qovery Agent Skills once, add the Qovery MCP Server in read-only mode, then ask in plain language which clusters are behind and what breaks if you move them. Four commands, in this order.

Install the skills globally for Claude Code, Cursor, Codex, OpenCode or Gemini CLI. One install covers every compatible agent:

curl -fsSL https://skill.qovery.com/install.sh | bash

Or keep the skills scoped to this repo only:

curl -fsSL https://skill.qovery.com/install.sh | bash -s -- --project

Add the MCP Server to Claude Code. It is read-only by default and authenticates via OAuth, which you approve in the browser:

claude mcp add --transport http qovery https://mcp.qovery.com/mcp --callback-port 4242

Enable write access only when you explicitly want the agent to act. This also requires write access to be enabled in the Qovery Console:

claude mcp add --transport http qovery "https://mcp.qovery.com/mcp?read_write=true" --callback-port 4242

The split is simple. The skills (qovery-onboard, qovery-deploy, qovery-troubleshoot, qovery-optimize, qovery-speedup, qovery-preview, qovery-terraform) deploy things. The MCP Server operates what already exists. Then ask: "Which of my clusters are behind on Kubernetes, and what should I upgrade first?" or "Spin up a preview environment so I can test this service before the version bump." Setup details are in the AI agent quickstart and the Claude Code integration page.