Upgrading Kubernetes is like changing the tires on a bus while it's doing 80 on the highway. The passengers don't care that the tires are old. They care that the bus doesn't stop.
This week, AWS announced that Amazon EKS and EKS Distro support Kubernetes 1.37. New clusters can use it today, and existing clusters can upgrade through the console, eksctl, or your infrastructure-as-code tool of choice.
So here's the question every platform team asks within five minutes of an announcement like this: "Do we have to do this now?"
Short answer: probably not today. But the calendar has opinions, and a few of them are closer than you'd think. Let's cook this one properly.
What We Are Cooking Today
- Understand what 1.37 actually changes on EKS (and what it doesn't)
- Check your support-window deadlines so a surprise bill doesn't ruin your quarter
- Upgrade a cluster in the right order: control plane, add-ons, then nodes
- Verify the result and know your fallback plan
What's New in EKS 1.37 (The Short Version)
Think of a Kubernetes release as a restaurant menu update. Most dishes stay the same. A few get promoted from "chef's experiment" to "house special." Here's what AWS highlighted for 1.37, plus what the upstream release notes add:
- Metrics API goes GA as
metrics.k8s.io/v1. It's the thing behindkubectl topand the Horizontal Pod Autoscaler. It spent nearly nine years in beta, which is a long time to be "almost ready." Upstream says no functional changes are expected; it's formal recognition of what everyone was already running. - HPA scale-to-zero reaches beta and is on by default. Workloads using object or external metrics can sit at zero pods when idle. (CPU and memory metrics don't count for this, since a pod at zero can't report CPU.)
- Dynamic Resource Allocation (DRA) device taints and tolerations go GA. Mostly relevant if you run GPUs or other special hardware.
- KYAML is stable. A stricter, more predictable YAML dialect. Existing manifests don't need to change.
Fact vs. opinion: everything above comes from the AWS announcement and the Kubernetes 1.37 release notes. My opinion: for most teams, 1.37 is a "boring in a good way" release. The real work isn't the new features. It's the deadlines.
Your EKS Support Calendar
This is where upgrades stop being optional. EKS gives each version 14 months of standard support, then 12 months of extended support, and clusters in extended support cost more per hour. When extended support launched, the price was $0.60 per cluster-hour versus $0.10 in standard support. Check current EKS pricing before you budget, since prices can change.
| Version | Standard support ends | Extended support ends |
|---|---|---|
| 1.37 | Dec 1, 2027 | Dec 1, 2028 |
| 1.34 | Dec 2, 2026 | Dec 2, 2027 |
| 1.33 | Ended Jul 29, 2026 | Jul 29, 2027 |
| 1.31 | Ended Nov 26, 2025 | Nov 26, 2026 |
Dates from endoflife.date as of October 4, 2026. Always confirm against the official EKS version lifecycle page before you plan around them.
Read that table twice. If anything is on 1.31, extended support ends in about seven weeks, and EKS does not let a control plane sit on an unsupported version. If you're on 1.33, you're already in the pricier extended window. And 1.34 loses standard support on December 2. The calendar is the real reason to upgrade, not 1.37's feature list.
Ingredients
- An EKS cluster you're allowed to break (start with staging, not production)
awsCLI v2,kubectl, and optionallyeksctl- IAM permissions for
eks:UpdateClusterVersion,eks:UpdateAddon, andeks:UpdateNodegroupVersion - Your add-on list (VPC CNI, kube-proxy, CoreDNS, EBS CSI driver, metrics-server, and friends)
- A rollback story, even if the story is "we restore from GitOps"
- Coffee. Strong coffee.
Kitchen Prep
The golden rule: you can only upgrade one minor version at a time, and you cannot downgrade a control plane. That second part is why we prep like surgeons.
Here's the order of operations:
Set a few variables so you're not typing cluster names at 11 p.m.:
export CLUSTER=staging-eks
export AWS_REGION=<your-region>
export TARGET=1.37Recipe Steps
Step 1: Ask EKS what it thinks will break
EKS cluster insights scan for things that could block or hurt an upgrade, like deprecated API usage. It's free advice from the people who run the control plane. Take it.
aws eks list-insights \
--cluster-name $CLUSTER \
--region $AWS_REGION \
--filter categories=UPGRADE_READINESSExpected: a list of insights, ideally all with a passing status. Pitfall: skipping this because "we upgraded last time and nothing happened." Past you wasn't running these workloads.
Step 2: Check who's still calling deprecated APIs
kubectl get --raw /metrics | grep apiserver_requested_deprecated_apisAnything showing up here is a manifest, Helm chart, or controller that will eventually bite you. Fix those in Git, not with a late-night kubectl edit.
Step 3: Find add-on versions that match 1.37
for addon in vpc-cni kube-proxy coredns aws-ebs-csi-driver; do
echo "== $addon =="
aws eks describe-addon-versions \
--kubernetes-version $TARGET \
--addon-name $addon \
--query 'addons[].addonVersions[].addonVersion' \
--region $AWS_REGION
doneWrite the versions down. Self-managed add-ons like metrics-server aren't in this list, so check their release notes for 1.37 and Metrics API v1 support before you assume anything.
Step 4: Upgrade the control plane
aws eks update-cluster-version \
--name $CLUSTER \
--kubernetes-version $TARGET \
--region $AWS_REGION
aws eks wait cluster-active --name $CLUSTER --region $AWS_REGIONIf you use Terraform, the equivalent is bumping cluster_version to "1.37" and reading the plan very, very carefully. The control plane keeps serving traffic during the upgrade, but this is still the step you can't undo.
Step 5: Update the add-ons
aws eks update-addon \
--cluster-name $CLUSTER \
--addon-name kube-proxy \
--addon-version <version-from-step-3> \
--resolve-conflicts NONE \
--region $AWS_REGION--resolve-conflicts NONE is deliberate. If someone hand-tuned the add-on config, the update fails loudly instead of quietly overwriting it. Loud failures are friendly failures.
Step 6: Roll the nodes
For managed node groups:
aws eks update-nodegroup-version \
--cluster-name $CLUSTER \
--nodegroup-name <your-nodegroup> \
--region $AWS_REGIONIf you run Karpenter, node AMI drift handles the rolling for you, which is lovely until your disruption budgets turn out to be more optimistic than your workloads. We walked through that in our Karpenter guide. Check your PodDisruptionBudgets before you start, not after pods go Pending.
Step 7: Verify like you mean it
kubectl get nodes -o wide
kubectl get pods -A | grep -v Running | grep -v Completed
kubectl top nodes
kubectl get apiservices | grep metricsIf kubectl top works and the metrics APIService shows Available, the Metrics API story is healthy. Then watch dashboards for a full business cycle, not five minutes.
Chef Tips
- Upgrade staging first, and make staging resemble production. A staging cluster with three pods and no PDBs proves almost nothing. This worked perfectly in staging, which is often production's favorite joke.
- Do it early in the week. Friday upgrades are a hobby for people who enjoy weekends at the keyboard.
- Don't chase the newest version for its own sake. Staying one or two versions behind latest is a perfectly respectable production strategy, as long as you stay inside the support window. That's my opinion, and your risk appetite may differ.
- Treat the support calendar as a backlog item. Put the dates in your team calendar today.
Kitchen Disasters
| Symptom | Likely cause | Fix |
|---|---|---|
kubectl top returns errors after the upgrade | metrics-server isn't serving the API you expect | Check kubectl get apiservices | grep metrics and upgrade metrics-server per its release notes |
| Pods stuck Pending during node roll | Not enough spare capacity, or strict PDBs | Add temporary capacity, review PDBs, and roll fewer nodes at a time |
| Add-on update fails with a conflict | Someone customized the add-on config | Review the diff and move the customization into add-on configuration values |
| Surprise charges on the AWS bill | A cluster slid into extended support | Check versions with aws eks describe-cluster and plan the upgrade |
| Control plane update shows as failed | Often an insight you ignored, or a networking prerequisite | Run aws eks describe-update and read the error before retrying |
Serving Suggestions
- Move cluster versions into code (Terraform or your GitOps repo) so upgrades are pull requests, not heroics.
- Add a CI check that fails when a cluster is within 90 days of leaving standard support. Pick your own threshold.
- Run the EKS insights call on a schedule, not just before upgrades.
- Audit for the removals coming in later Kubernetes releases. We cover that in the next recipe this week.
Cleanup
If you spun up a test cluster for rehearsal, delete it so it stops costing money:
eksctl delete cluster --name $CLUSTER --region $AWS_REGIONRollback reality check: EKS doesn't downgrade control planes. Your real rollback is the plan you made earlier: a tested staging run, infrastructure in code, and workloads that can be redeployed from Git onto a fresh cluster if things go truly sideways. Hope isn't a rollback strategy.
Frequently Asked Questions
Do I have to upgrade to EKS 1.37 right now?
No. Your deadline is set by your current version's support dates, not by 1.37's release. If you're on 1.31, 1.33, or 1.34, those dates are far more urgent.
Can I skip versions, say 1.34 straight to 1.37?
No. Control planes upgrade one minor version at a time, so 1.34 to 1.37 means three sequential upgrades.
Will the Metrics API change break my HPA?
Upstream says no functional changes are expected. The practical risk is an out-of-date metrics-server, so check its release notes and verify kubectl top after upgrading.
What does HPA scale-to-zero need?
Object or external metrics. It doesn't work with CPU or memory metrics alone, since a pod at zero can't report CPU. Test it in a non-critical workload first; it's beta.
Final Thoughts
EKS 1.37 is a calm release with one big message: the Metrics API finally grew up. The urgent news this week isn't the new version. It's the dates in the table above. Open your cluster list, check the versions, and put the deadlines on a calendar before somebody else's invoice does it for you.
No comments:
Post a Comment