A successful Kubernetes 1.37 upgrade depends on coordinating the control plane with the software and workloads around it. The change affects more than the API server: nodes, add-ons, clients, and applications need attention too.
Kubernetes minor version means the release number formed by the first two version components, such as 1.37. Use a careful sequence to check readiness, test compatibility, make the change, and confirm each part works afterward.
The work may take different amounts of time in different environments. Node count, disruption limits, add-on changes, and workload checks all shape the production window. Treat the procedure as a staged change, with production promotion dependent on successful rehearsal and health checks.
Key Takeaways
- Check the cluster’s current minor version before planning the route to 1.37.
- Review health, upgrade insights, deprecated APIs, and kubelet settings before changing the control plane.
- Test Kubernetes 1.37 workload changes, especially CSI volume sharing and GPU use.
- Upgrade add-ons, nodes, applications, and clients as separate parts of the change.
- Use a production-like rehearsal to set the production window and validate recovery plans.
EKS Cluster Upgrade Kubernetes 1 37 13 Steps 2026: Is Version 1.37 Available?
Amazon EKS made Kubernetes 1.37 available on October 1, 2026, including in AWS GovCloud (US) Regions. An Amazon EKS cluster upgrade to Kubernetes 1.37 in 2026 should begin by identifying the cluster’s current minor version.
EKS offers version 1.37 in every AWS Region where EKS is available. The EKS release followed the upstream Kubernetes release, which occurred on August 26, 2026. These are separate release events: upstream release timing does not set EKS availability.
The cluster’s starting minor version determines whether you need intermediate upgrades before reaching 1.37.
The 13-step process here applies to clusters that target Kubernetes 1.37. It covers the checks and changes around that target, not a shortcut across multiple minor versions.
Review the target in the cluster’s EKS version details, along with the AWS Region where the cluster runs. A cluster may be in a Region where EKS is available, but the selected cluster still needs its own version and health review.
The upstream project’s Kubernetes 1.37 release announcement lists the August release date and upstream changes. EKS availability is a separate service milestone.
Record the current version before choosing an upgrade path. Confirm the target version and AWS Region in the cluster’s EKS version details before scheduling work.
How long does EKS support Kubernetes 1.37?
The standard-support deadline for EKS Kubernetes 1.37 is December 1, 2027, followed by extended support through December 1, 2028. In 2026, standard support lasts 14 months, then extended support lasts 12 months.
Extended support adds a charge for each cluster hour. EKS enables extended support by default in 2026, so a cluster can remain on its version after standard support ends, with that added cost.
In 2026, versions 1.37, 1.36, 1.35, and 1.34 are in standard support. Versions 1.33, 1.32, and 1.31 are in extended support. EKS can create clusters on versions in either phase.
| Kubernetes version | 2026 support tier | Support-phase duration | Billing or upgrade implication |
|---|---|---|---|
| 1.37 | Standard support | 14 months | Extended support may follow at an added cluster-hour charge |
| 1.36 | Standard support | 14 months | Extended support may follow at an added cluster-hour charge |
| 1.33 | Extended support | 12 months | Extra charge per cluster hour |
| 1.31 | Extended support | 12 months | Extra charge per cluster hour |
EKS announces a minor version’s end of standard support at least 60 days ahead. Affected accounts receive an AWS Health Dashboard notice about 12 months after that version’s EKS release.
If extended support ends before you update, EKS may automatically move the cluster to the oldest version still in extended support. That can change the cluster without your planned timing.
A cluster moving from 1.35 to 1.37 must first move to 1.36. Check the account’s AWS Health Dashboard notices alongside the version schedule when setting an upgrade deadline.
Which checks should you complete before upgrading?
A reliable preflight begins with a healthy cluster and a record of what is running before any version change. Start with evidence, not assumptions about the cluster’s last known state.
Capture the cluster and node versions, health, and workload baseline before changing anything. This record lets your operations team compare behavior after the upgrade.
Step 1: Check the cluster’s current version and health
Record the control-plane version and each node group’s Kubernetes version. Check node readiness, Pod health, and key service indicators. Save the workload baseline, including any known issues already under investigation.
Step 2: Review upgrade insights and deprecated API use
Check cluster health and Kubernetes API usage, then review EKS upgrade insights. Find deprecated APIs in active workloads and deployment files before they can block or disrupt a change.
Use the upgrade-insight results as working findings, not as a substitute for checking the workloads that matter most. AWS describes a version-monitoring approach that reviews upgrade insights and sends notifications to teams.
The AWS upgrade-monitoring example uses scheduled checks and alerts. It presents automatic upgrades as optional for development clusters, with testing and monitoring before production use.
Step 3: Update tools and capture a recovery baseline
Check local tools, including kubectl and the utilities used by your release process. Capture manifests and critical recovery details for applications and persistent volumes. Record settings and dashboard values you will compare after the change.
Kubernetes 1.37 changes some kubelet behavior. A kubelet no longer starts when a deprecated cAdvisor flag is set, except for --housekeeping-interval. Custom AMIs and extra kubelet arguments using removed flags need remediation first.
Kubernetes 1.37 removes the container_cpu_load_average_10s, container_cpu_load_average_10s, and container_tasks_state kubelet metrics. Dashboards scraping the removed metrics need revision before the upgrade.
Also review eventRecordQPS: a value of 0 means no event limit in Kubernetes 1.37. Setting it to 5 keeps the previous limit of five events per second.
- API and workload health
- Deprecated API findings
- Kubelet arguments
- Dashboards or alerts that rely on removed metrics
Kubernetes 1.37 logs the full effective kubelet configuration at startup, so limit node-log access to trusted users. Remove deprecated kubelet arguments from custom node configurations before starting the control-plane update.
What Kubernetes 1.37 changes can affect workloads?
Kubernetes 1.37’s default SELinux mount labeling makes volume-sharing settings a workload compatibility check, not just a node detail. Shared storage deserves a test with the same Pod settings used in production.
Pods sharing a CSI volume with SELinux mount labeling must use matching SELinux levels and change policies. A mismatch can leave a Pod stuck in ContainerCreating.
Step 4: Check SELinux volume-sharing behavior
When a Pod sets seLinuxOptions and its CSI driver sets seLinuxMount: true, kubelet uses a mount context. It does not relabel every file on the volume.
If another Pod on the same node uses that volume with a different SELinux label, seLinuxChangePolicy, or privilege level, the new Pod may remain in ContainerCreating. For shared CSI volumes with seLinuxMount: true, use the same seLinuxOptions.level and seLinuxChangePolicy.
When an unprivileged Pod shares a volume with a privileged Pod, use seLinuxChangePolicy: Recursive. Test this combination on the node and CSI driver planned for production.
Step 5: Review autoscaling and resource-allocation changes
New EKS Auto Mode NodePools on Kubernetes 1.37 default an unspecified consolidationPolicy to Balanced. The built-in general-purpose and system NodePools also use Balanced, and you cannot change that setting.
Dynamic Resource Allocation device taints and tolerations are stable in Kubernetes 1.37. EKS needs a separately installed DRA driver. The NVIDIA DRA driver works with Karpenter static capacity, EKS managed node groups, and self-managed nodes.
EKS Auto Mode and Karpenter dynamic capacity provisioning should use the NVIDIA device plugin instead of the NVIDIA DRA driver. Choose the driver based on how your cluster provisions GPU capacity.
Kubernetes 1.37 lets each Horizontal Pod Autoscaler set separate scale-up and scale-down tolerances. Before this change, the cluster-wide default was 10 percent.
HPAScaleToZero is enabled by default. An HPA using Object or External metrics can set minReplicas: 0, but it needs a separately installed metrics adapter.
Step 6: Check API, GPU, and metrics dependencies
The Metrics API moves to metrics.k8s.io/v1 for Pod and node CPU and memory use. HPA and kubectl top use these metrics, so test any tools that read them directly.
EKS G7 instances need NVIDIA driver 595 with Kubernetes 1.37. EKS-optimized Amazon Linux 2023 NVIDIA AMIs include driver 595 on all supported versions. Bottlerocket NVIDIA AMIs include it on Kubernetes 1.37 and later.
Teams tracking Amazon EKS Distro can note its Kubernetes 1.37.1 release 4, with manifest v1-37-eks-4. Test workloads that share CSI volumes or depend on GPU capacity with their exact production settings.
How do you check version skew and rehearse safely?
A Kubernetes 1.37 API server supports kubectl 1.36 through 1.38, but the worker components have a different compatibility range. Check each component against its own version rule.
Kubelet and kube-proxy can be up to three minor versions older than the API server, but cannot be newer. Components older than 1.25 have a two-minor-version lag limit.
Step 7: Confirm component versions against the skew policy
With a 1.37 API server, kubectl can run at 1.36, 1.37, or 1.38. Kubelet and kube-proxy can run at 1.34 through 1.37. The Kubernetes version skew policy also limits API server and controller component differences.
| Component | Supported version with a 1.37 API server | Allowed newer version | Specific constraint |
|---|---|---|---|
| kubectl | 1.36, 1.37, 1.38 | 1.38 | One minor version older or newer |
| kubelet | 1.34, 1.35, 1.36, 1.37 | None | Three minor versions older; two if below 1.25 |
| kube-proxy | 1.34, 1.35, 1.36, 1.37 | None | Three minor versions older; two if below 1.25 |
| Controller-manager, scheduler, cloud-controller-manager | 1.36, 1.37 | None | One minor version older, not newer |
In a highly available cluster, the newest and oldest kube-apiserver instances must stay within one minor version. Review that limit during rolling changes, when API server instances may not change together.
Step 8: Rehearse in a nonproduction cluster
Use a staging cluster that closely matches production settings. Test add-ons, workload behavior, image reachability, networking, and health checks. Include the same deployment methods and key disruption settings.
Service outages can affect dependent applications even when backups exist. Review tested backups and failover plans as part of rehearsal planning, including what separate-zone backups cover.
- Run prechecks.
- Execute the planned sequence.
- Verify workload and node health.
- Record elapsed time and issues.
A concise EKS upgrade explanation should cover sequential minor-version changes, component compatibility, and staged validation. Use rehearsal results to set the production window rather than assuming that the control-plane task represents the full upgrade.
How do you upgrade the EKS control plane and add-ons?
Before submitting the Kubernetes 1.37 control-plane update, confirm that the configured subnets have up to five available IP addresses. EKS needs those addresses for new cluster network interfaces.
After the update starts, you cannot pause or stop it. Choose the EKS console, eksctl, or an infrastructure-as-code tool to submit the change.
During an EKS control plane upgrade, EKS replaces control-plane infrastructure while keeping the cluster on its target Kubernetes version if the change succeeds. Plan for the update to run without interruption from your team.
Check subnet capacity and cluster readiness before submitting. An unresolved subnet shortage or health problem can block the work or cause it to fail.
EKS runs infrastructure and readiness health checks during the update. If either check fails, EKS reverts the infrastructure deployment and leaves the cluster on its prior Kubernetes version.
Monitor the update status and any errors in the EKS console or through your chosen deployment tool. Keep the team watching the update until it completes or reports a failure.
The console shows the update state, while infrastructure-as-code tools can report their own deployment status. Keep both views available if your team submits the change through automation.
Do not treat an in-progress control-plane update as a cancellable task.
How do you update nodes and verify workloads?
EKS does not automatically upgrade managed or self-managed node groups when you upgrade the control plane. Plan node work separately and coordinate it with add-ons, applications, and clients.
AWS recommends keeping the control plane and nodes on the same Kubernetes version. Managed-node and Fargate-node minor versions must match the control plane before its 2026 upgrade.
Step 10: Update EKS add-ons
Check add-on compatibility with the target version, then update the EKS add-ons. Include VPC CNI, CoreDNS, and kube-proxy. Confirm that each add-on reports healthy status after its update.
Step 11: Roll the worker nodes
Managed node groups and self-managed node groups need their own update. Bring self-managed and hybrid nodes to the control-plane version first where possible, and plan the node rollout around Pod disruption limits.
EKS Auto Mode starts incremental updates to managed nodes after a control-plane upgrade. It respects Pod disruption budgets during that work.
EKS Auto Mode manages compute autoscaling, block storage, and load-balancing capabilities. Those capabilities do not need a separate manual upgrade.
Step 12: Update applications and clients
After the control plane changes, update cluster applications such as cluster-autoscaler. Update clients such as kubectl in the same planned sequence.
Check client access from the systems your team uses for deployment and support. A healthy API server does not prove that every build runner or operator workstation can connect.
Step 13: Verify health and close the change
Compare live results with the pre-upgrade baseline. Watch workload behavior after the change, not just the first successful status report.
- Node readiness and Kubernetes versions
- Add-on health
- Application and Pod health
- Client connectivity
Keep the change open while you check for new scheduling delays, failed probes, or unexpected restarts. Close it only after node, add-on, application, and client checks all pass.
What happens if an upgrade fails or needs rollback?
An EKS in-place upgrade has a 7-day window for rolling back to the previous minor version. That window is limited, so treat rollback as a defined recovery action rather than a general undo button.
To roll back to an extended-support version, first change the cluster upgrade policy to EXTENDED. The policy setting is a required part of that rollback path.
A rollback does not replace a rehearsed recovery plan for application and data problems.
EKS infrastructure rollback and workload recovery address different risks. A control-plane version change may be reversible within the allowed window, but your team still needs a plan for application errors and data recovery.
In an interview, explain both parts: how EKS handles infrastructure rollback and how the team restores application service or data. Confirm the target version’s support tier and the cluster upgrade policy before requesting a rollback.
Conclusion
A Kubernetes 1.37 upgrade is most manageable when each component is checked against the target before production changes begin. Treat the control plane, nodes, add-ons, clients, and workloads as one coordinated change.
Staged validation gives your team a safer basis for making a production decision. A rehearsal using production settings can reveal issues that a control-plane update alone will not show.
Start by recording the current cluster version and scheduling a nonproduction rehearsal.
FAQ
How long should I budget for an EKS 1.37 upgrade?
Use a production-like rehearsal to estimate the full upgrade window. The control-plane task is only one part of the work. Node count, Pod disruption limits, add-on updates, and workload validation all affect the schedule. Record rehearsal time for each stage, including checks and recovery steps. Build the production window around that measured sequence, not just the control-plane update.
Can I upgrade an EKS cluster directly from 1.35 to 1.37?
No, EKS allows one minor-version control-plane upgrade at a time. A cluster on 1.35 must first upgrade to 1.36, then move to 1.37. Treat each version change as its own operation, with compatibility checks and health review. Do not plan a single jump from 1.35 to 1.37, even if your node software appears ready for the target.
Does EKS automatically upgrade managed node groups with the control plane?
No, managed and self-managed node groups need a separate update. AWS recommends matching node and control-plane versions. Plan the worker-node rollout after the control-plane change, and account for Pod disruption budgets and application health. EKS Auto Mode begins incremental managed-node updates after a control-plane upgrade, but ordinary managed node groups do not receive that automatic update.
Can I create a new EKS cluster on an extended-support Kubernetes version in 2026?
Yes, EKS allows cluster creation on versions in standard or extended support. Extended support adds a charge for each cluster hour. That means a new cluster can start on an extended-support version, but the operating cost includes the extra support charge. Check the version’s support phase when estimating the cluster’s ongoing cost and upgrade schedule.
What should I check if a Kubernetes 1.37 Pod stays in ContainerCreating?
Check whether another Pod shares its volume with different SELinux settings, change policy, or privilege level. This can affect a shared CSI volume when SELinux mount labeling applies. Pods sharing that volume should use matching seLinuxOptions.level and seLinuxChangePolicy. Also check whether an unprivileged Pod shares the volume with a privileged Pod, since that combination calls for the Recursive policy.
Does EKS Auto Mode use the NVIDIA DRA driver for dynamic capacity?
No, use the NVIDIA device plugin for EKS Auto Mode and Karpenter dynamic capacity. The NVIDIA DRA driver is supported with Karpenter static capacity, EKS managed node groups, and self-managed nodes. Select the driver based on the capacity method in use. A driver that works for static capacity is not the right choice for Auto Mode dynamic provisioning.
