Is your cluster actually ready for Kubernetes 1.37, or are you about to discover a removed API the hard way, at 2 a.m., with a dashboard that suddenly won’t load? That question sits at the center of every serious upgrade conversation in 2026. Kubernetes moves fast, deprecations pile up quietly, and the gap between “it works in staging” and “production is down” is often a single forgotten manifest. (Kubernetes Releases on GitHub)
This guide walks through a practical, battle-tested approach to the 1.37 upgrade and migration. It focuses on what actually breaks, the order of operations that keeps outages away, and the habits that separate smooth upgrades from painful ones. A quick honesty note up front: because release details shift, always confirm the exact removal list and release date against the official release notes before you schedule anything. Treat this as your operating playbook, not a substitute for the changelog.
Why the 1.37 Upgrade Deserves Real Planning
Kubernetes follows a steady release rhythm. Minor versions arrive roughly every four months, and each one is supported for about 14 months, meaning you’re typically juggling three minor versions at once. That cadence is a feature, not a bug, but it also means deprecated APIs get removed on a schedule you don’t control. An API marked deprecated two or three releases ago may simply vanish in 1.37.
The real risk in any minor upgrade isn’t the control plane itself. It’s the long tail of workloads, Helm charts, operators, and internal tooling that quietly rely on APIs nobody has touched in a year. The clusters that upgrade cleanly are the ones that treat migration as a project with a checklist, not a Friday afternoon task.
If you’ve ever handled a large infrastructure jump, the discipline is familiar. The same methodical mindset behind an EKS cluster upgrade to Kubernetes 1.37 in 13 steps applies here: inventory first, test second, roll forward in controlled waves.
Before You Touch Anything: The Pre-Upgrade Audit
Check the version skew policy
Kubernetes enforces a version skew policy. Your kubelet and kube-proxy should not be more than a couple of minor versions behind the control plane, and the control plane itself should be upgraded one minor version at a time. You cannot jump from 1.34 straight to 1.37. Plan for sequential hops.
Inventory every API in use
This is the step people skip, and it’s the one that saves them. Two tools do most of the heavy lifting:
- kubent (kube-no-trouble) scans live objects for deprecated and removed APIs.
- pluto from Fairwinds checks both live resources and static manifests, including Helm releases.
Run both. Then check your Helm charts, GitOps repositories, and CI pipelines. The APIs hiding in a chart’s templates are exactly the ones that slip past a live-cluster scan.
Read the deprecation guide, not the release blog alone
The Deprecated API Migration Guide in the official documentation is the authoritative source for what’s being removed and what replaces it. The release blog gives you the headline; the migration guide gives you the actual work. Cross-reference both against the release notes on the kubernetes/kubernetes GitHub repository. (Kubernetes Documentation)
Building a Safe Upgrade Sequence
The order of operations matters as much as the version numbers. Here’s a sequence that keeps risk contained:
- Freeze and back up. Take etcd snapshots. Confirm you can restore them. A backup you’ve never tested is a wish, not a backup.
- Upgrade the control plane first, one minor version at a time, following the official kubeadm upgrade procedure if you’re self-managed.
- Drain and upgrade worker nodes in batches. Never cordon the whole fleet at once.
- Upgrade kubelet and kube-proxy on each node as part of the node upgrade, respecting skew limits.
- Verify workloads before moving to the next batch. Watch for CrashLoopBackOff, failed readiness probes, and scheduling failures.
- Update add-ons last but deliberately: CNI, CSI drivers, ingress controllers, and metrics pipelines all have their own compatibility matrices.
A practical compatibility checklist
| Component | What to verify | Common failure |
|---|---|---|
| Control plane | Skew from nodes, etcd version | Jumping multiple minors |
| kubelet / kube-proxy | Within skew of API server | Skipped node upgrade |
| CNI plugin | Supports 1.37 networking changes | Pods stuck in ContainerCreating |
| Ingress controller | API version of Ingress resources | Routes silently disappear |
| Helm charts | Templates use current APIs | Deploy fails on apply |
| Operators / CRDs | CRD schema and webhook compatibility | Admission webhook rejects everything |
That last row is the sneaky one. A validating webhook that references a removed API can block every deployment in the cluster, and the error message rarely points at the webhook itself.
The Migration Work That Actually Takes Time
Rewriting manifests for removed APIs
Most removals follow a predictable pattern: an old API version gets replaced by a stable one, and the old one is eventually retired. The fix is usually a one-line change in a manifest, but finding every occurrence across hundreds of files is the real effort. Use `kubectl convert` or your GitOps tooling to surface stragglers, and grep your repositories for the deprecated group and version strings.
Testing in a mirror cluster
Spin up a staging cluster on 1.37 that mirrors production’s workload mix. Deploy everything. Run your smoke tests. This is where you catch the operator that hasn’t been updated since 2023 and the internal tool that hardcodes an API path. The cost of a staging cluster is trivial next to the cost of a production rollback.
Watching for behavior changes, not removals alone
Not every breaking change is an API removal. Default behaviors shift, feature gates flip, and metrics get renamed. If your dashboards or alerting depend on specific metrics, verify they still exist. Silent monitoring gaps are worse than loud failures because nobody notices until an incident.
The same lesson shows up across the tech world: surface-level changes hide deeper workflow shifts. A good parallel is how teams are discovering that AI is creating more work, not less, according to studies of tools like Uber’s ChatGPT rollout — the tool changes, and the surrounding processes have to be rebuilt around it. Upgrades work the same way.
Common Mistakes That Sink Upgrades
Skipping minor versions. The skew policy exists for a reason. Sequential upgrades take longer but fail less.
Upgrading everything at once. Control plane, nodes, and add-ons in a single window is how you lose the ability to tell what broke.
Ignoring the etcd snapshot. Take it, test the restore, then upgrade.
Forgetting the human layer. Notify on-call, schedule the window, and have a rollback plan written down before you start. Rollback for a control plane upgrade usually means restoring etcd and reinstalling the previous version, which is disruptive. Know that going in.
Treating add-ons as an afterthought. CNI and CSI upgrades often need to happen in a specific order relative to the cluster upgrade. Check their documentation.
How Long Should the Whole Thing Take?
Realistically, a mid-sized production cluster takes one to three weeks of preparation and a few hours of actual upgrade execution per minor version. The prep dominates because that’s where the migration work lives. Small clusters with few custom workloads can move faster, but the audit step is non-negotiable regardless of size.
If you’re also refreshing the hardware underneath your control plane or worker fleet, plan that separately. Mixing a GPU upgrade and graphics card installation project with a Kubernetes minor upgrade in the same window is a recipe for confusing symptoms. One change at a time.
Post-Upgrade Validation
Once the dust settles, run a structured validation pass:
- Confirm all nodes report Ready and the expected kubelet version.
- Check that every namespace has its expected pod count and no unexpected restarts.
- Exercise critical paths: authentication, ingress routing, persistent volume mounts, and autoscaling.
- Review API server audit logs for requests hitting removed endpoints.
- Re-run kubent and pluto to confirm a clean bill of health.
Document what you found. The next upgrade will thank you, and so will whoever inherits the cluster.
Conclusion
The Kubernetes 1.37 upgrade is less about the version number and more about the discipline around it. Audit your APIs, respect the skew policy, upgrade in waves, and test in a mirror environment before production ever sees the new control plane. Confirm every removal against the official release notes and deprecation guide, because those documents — not blog posts, not memory — are the source of truth. Done right, the upgrade becomes a routine maintenance window instead of a crisis. Done carelessly, it becomes the incident everyone remembers. The difference is almost entirely preparation.
Frequently Asked Questions
Can I skip minor versions when upgrading to 1.37?
No. Kubernetes enforces a version skew policy, and the control plane should be upgraded one minor version at a time. You cannot jump from an older release directly to 1.37. Plan sequential hops and budget time for each.
What tools find deprecated APIs before an upgrade?
kubent (kube-no-trouble) and pluto from Fairwinds are the two most widely used. Run them against live clusters and static manifests, including Helm charts, because chart templates often hide deprecated API versions that a live scan misses.
How long is each Kubernetes minor version supported?
Each minor version is typically supported for about 14 months, with roughly three minor versions supported at any given time. That window is why staying current matters: falling behind means losing patch support and facing a bigger, riskier upgrade later.
What happens if I miss a removed API in a manifest?
The apply fails, or worse, an admission webhook or controller that depends on that API stops functioning and blocks unrelated deployments. Always scan manifests and charts before the upgrade, not after something breaks in production.
Do I need to upgrade add-ons like CNI and CSI separately?
Yes. CNI plugins, CSI drivers, ingress controllers, and metrics pipelines each have their own compatibility matrices and should be upgraded deliberately, usually after the control plane and nodes. Check each project’s documentation for the correct order.
How do I roll back a failed control plane upgrade?
Rollback typically means restoring the etcd snapshot taken before the upgrade and reinstalling the previous Kubernetes version. This is disruptive, which is exactly why testing in a staging cluster and taking a verified etcd backup are mandatory steps, not optional ones.
If you’re running a managed service, the provider handles the control plane and etcd, but you still own nodes, add-ons, and manifests. Don’t assume the provider’s upgrade path removes the need to audit APIs — the removals land on your workloads regardless. Confirm the provider’s supported version window and node pool upgrade mechanics before you schedule anything.
After the first cluster, codify it
The first 1.37 upgrade is a project. The second should be a checklist. Turn your audit commands into a CI job that fails the build when a deprecated API group appears in a manifest. Add a compatibility gate to your Helm chart linting. Keep the staging cluster around long enough to serve as a canary for this minor version and the next one. That’s how teams move from firefighting upgrades to scheduling them.
The bottom line
Kubernetes 1.37 is an ordinary release in an extraordinary discipline problem. The removals are documented, the tools exist, and the sequence is known. What separates a calm maintenance window from a long night is whether you did the audit and the staging test before the window opened. Start with the inventory, respect the skew policy, and let the official migration guide — not a blog post, not a memory of how it worked last time — decide what changes.
