AKS LTS Moves to Kubernetes 1.37: How to Get Ahead of Azure's Forced Upgrade

Key points:

• Kubernetes 1.37 is the newest AKS version you can pin on Long Term Support. It went GA on AKS in October 2026. Community support runs to October 2027 and LTS runs to October 2028, roughly 24 months in total. LTS requires the Premium tier at $0.60 per cluster per hour, against $0.10 for Standard.
• Platform-initiated upgrades start on June 1, 2027. From that date, AKS upgrades any cluster still on an unsupported version once its 60-day grace period ends. There is no opt-out, and these upgrades ignore your maintenance window, skip the deprecated API check, and can override a PodDisruptionBudget.
• The only thing you control is timing. Upgrade yourself, or put the cluster on the stable auto-upgrade channel with an aksManagedAutoUpgradeSchedule window, and you never enter the forced path.
• AKS has no downgrade. A non-LTS cluster moves one minor version at a time. Your rollback plan is a parallel cluster plus a traffic shift, so cheap, scripted cluster creation is worth more than any runbook.
• The control plane rarely breaks. Removed APIs, self-managed add-ons, CNI and CSI versions, admission webhooks, and PDBs that block node drains cause most stalled upgrades.
• Qovery runs inside your own Azure, AWS, GCP or Scaleway account, or on your existing Kubernetes cluster, and handles managed cluster upgrades. Version drift becomes a managed process instead of one engineer's recurring weekend.

Your AKS cluster is getting upgraded either way. The only decision left is whether you pick the window or Azure does. As of November 2026, Microsoft has put a date on it: from June 1, 2027, any cluster left on an unsupported Kubernetes version gets upgraded by the platform, on the platform's schedule, with your PDBs treated as suggestions.

I am not writing this to bash Azure. EKS and GKE both force-upgrade at end of support too, and I'll show you their numbers. But this AKS change is concrete and dated, and it lands on teams that have parked clusters for years. Here is what changed, what breaks, what LTS really costs, and the plan I would run this quarter.

What exactly did Azure announce about AKS LTS and Kubernetes 1.37?

Kubernetes 1.37 reached AKS GA in October 2026. Community support covers about 12 months (to October 2027) and optional Long Term Support adds a second year (to October 2028), for about 24 months in total. LTS requires the paid Premium tier. AKS has also published platform-initiated upgrade months for every version, starting June 2027.

There are three windows to know, all from the AKS supported versions page:

• Community support (about 12 months from GA). AKS supports the latest three GA minors (N, N-1, N-2) with upstream bug fixes and security patches.
• Platform support (N-3, 60-day grace period). Azure supports the infrastructure only: VMs, node scaling, the control plane SLA. There are no Kubernetes bug fixes, no security patches, and you can't create new clusters.
• Long Term Support (one more year). You opt in on the Premium tier and Microsoft backports security fixes for a further 12 months.

One correction to the way this is often described. LTS is no longer limited to a few hand-picked versions. Microsoft's docs now say that "all supported Kubernetes versions are eligible for LTS". So 1.37 matters because it is the newest version you can pin for two years, which makes it the natural anchor if you're choosing one today.

Here are the dates that matter, from the AKS release calendar as of November 2026:

The principle is old. AKS has long auto-upgraded N-3 clusters before they fall to N-4. What's new is the enforcement. Platform-initiated upgrades begin on June 1, 2027, and they bypass the controls you configured.

The cost side, from the Azure Retail Prices API (East US, November 2026) and the AKS pricing tiers doc:

Quick test: can you name every AKS cluster's Kubernetes version and its support end date right now? If not, this change already affects you. If you run 1.34, community support ends this month.

Will Azure really auto-upgrade my AKS cluster if I do nothing?

Yes. From June 1, 2027, AKS upgrades any cluster that is still on an unsupported version 60 days after its end of life. There is no opt-out, and an upgrade that has started can't be cancelled. Microsoft's own wording is that it "doesn't follow your maintenance window, doesn't stop for deprecated API usage, and can override a Pod Disruption Budget".

Here is what platform-initiated upgrades actually override, per the platform-initiated upgrades doc:

• Maintenance window: ignored. Your aksManagedAutoUpgradeSchedule does nothing.
• Auto-upgrade channel: ignored. Clusters on none or patch get upgraded anyway.
• Fleet Manager update runs: bypassed. AKS acts on the member cluster directly.
• Deprecated API check: bypassed. Workloads that call removed APIs simply break.
• PDBs and surge: best effort only. If the drain times out, AKS overrides the PDB. If it can't get surge capacity, it upgrades one node at a time.
• Rollback: none. You can't go back to an unsupported version.

Before that, while the cluster sits unsupported, Microsoft says it gives "no runtime or other guarantees". Support tickets start with "please upgrade first". Azure Resource Health shows the cluster as Degraded. And if your SOC 2 or ISO 27001 scope requires supported software, you now have an open audit finding.

Waiting also makes it worse. A non-LTS cluster can't skip minor versions, so AKS moves it one minor at a time. A cluster four minors behind means four control-plane upgrades and four node pool rotations, each with its own drain. Picture that landing during a code freeze, a launch week, or Black Friday.

Azure isn't unusually aggressive here. Amazon EKS auto-upgrades the control plane at the end of extended support, with no specific timing given. GKE auto-upgrades clusters past end of support. Scaleway Kapsule upgrades within 30 days of end of support. Every managed Kubernetes provider now forces the upgrade eventually.

On every cloud, the real risk is organisational. Cluster upgrades usually sit with the one or two engineers who know the cluster. That makes the upgrade a single point of failure.

How do I find out which AKS clusters are at risk and what will break?

Inventory first. One Azure Resource Graph query lists every AKS cluster's version and support plan across all your subscriptions. AKS's deprecated API detection and a kubent or Pluto scan then tell you what breaks. That's an afternoon of work.

az graph query -q "resources | where type =~ 'microsoft.containerservice/managedclusters' | project clusterName = name, resourceGroup, subscriptionId, kubernetesVersion = properties.kubernetesVersion, tier = properties.sku.tier, supportPlan = properties.supportPlan | order by kubernetesVersion asc" --output table

# Per cluster: which upgrade hops are available
az aks get-upgrades --resource-group <rg> --name <cluster> --output table

# Per region: what AKS currently supports
az aks get-versions --location <region> --output table

If you only have one subscription, az aks list -o table does the same job. A supportPlan of AKSLongTermSupport means the cluster is enrolled in LTS.

Know the limits of AKS's built-in safety net. Deprecated API detection blocks a minor upgrade only if a removed API was called in the last 12 hours, and it ignores read-only verbs. A CronJob that runs monthly or a Helm chart sitting in Git is invisible to it. That's what kubent and Pluto are for.

The good news on upstream APIs: the Kubernetes deprecation guide lists no built-in API removals after v1.32. If you're already on 1.32 or later, the path to 1.37 doesn't remove any core APIs. If you're further behind, grep your charts for these:

• flowcontrol.apiserver.k8s.io/v1beta3, removed in 1.32 (and v1beta2 in 1.29). Use v1.
• storage.k8s.io/v1beta1 CSIStorageCapacity, removed in 1.27.
• autoscaling/v2beta2, removed in 1.26. Use autoscaling/v2.
• policy/v1beta1 PodDisruptionBudget and PodSecurityPolicy, batch/v1beta1 CronJob, removed in 1.25.

On AKS, 1.37 itself brings two Azure-specific changes. Node pools without an explicit LocalDNS profile can get LocalDNS enabled during the upgrade, so custom DNS must answer on both TCP and UDP port 53. And ama-metrics now uses namespace-scoped secret access for ServiceMonitor and PodMonitor with basicAuth.

A PDB with minAvailable equal to the replica count can never be satisfied. It stays invisible until drain time, and it's the classic reason a node pool upgrade hangs for hours. Then treat the Kubernetes version like any other dependency: a named owner and a support end date, tracked next to your library CVEs.

What does a safe AKS upgrade path to Kubernetes 1.37 look like step by step?

A safe path takes six steps. Set your own schedule, rehearse on a clone, tune surge to 33%, upgrade the control plane before the node pools, keep a parallel cluster as your rollback, and write down your version policy. None of it is clever.

Step 1: Own the schedule. Put the cluster on the stable channel (latest patch of N-1) and add an aksManagedAutoUpgradeSchedule window of at least four hours. That keeps you inside support, so the forced path never applies. The other channels are none, patch (stays on the current minor, so it doesn't save you), rapid, and the legacy node-image.

az aks update --resource-group <rg> --name <cluster> --auto-upgrade-channel stable
az aks maintenanceconfiguration add --resource-group <rg> --cluster-name <cluster> \
  --name aksManagedAutoUpgradeSchedule --schedule-type Weekly --day-of-week Sunday \
  --interval-weeks 1 --duration 4 --utc-offset +00:00 --start-time 01:00

Step 2: Rehearse on a short-lived clone of production. This is what ephemeral environments are for. Spin up the same workloads on a 1.37 cluster and run your smoke tests. "Can we upgrade?" stops being a meeting and becomes a test result.

Step 3: Tune surge. The AKS default is a surge of one node, which makes a 60-node pool crawl. Microsoft recommends 33% for production. You pay for a few extra VMs for an hour and save an afternoon of drains. Check your quota and subnet IPs first.

az aks nodepool update --resource-group <rg> --cluster-name <cluster> --name <pool> \
  --max-surge 33% --drain-timeout 45

Step 4: Control plane first, then node pools. Run az aks upgrade --control-plane-only (not allowed while cluster auto-upgrade is on), validate, then upgrade the pools one at a time. Since 1.28 the control plane can run up to three minors ahead of the nodes, so you have room to stage. For your riskiest stateful workloads, use blue/green node pools instead of an in-place rotation.

Step 5: Plan rollback as a second cluster. AKS doesn't support downgrades. Rolling back means standing up a parallel cluster on the old version and shifting traffic. That only works if cluster creation is scripted and cheap, with Terraform/OpenTofu, Bicep, Cluster API, or a platform that does it for you. To be fair, EKS now allows a rollback within 7 days of an in-place upgrade, but AKS doesn't.

Step 6: Pick an anchor policy and write it down. Both strategies below work. Drifting between them is what produces unsupported clusters.

Is AKS Long Term Support worth the extra cost, or should I stay on the current version?

LTS buys you calendar time. It doesn't make the upgrade any safer. At $0.50 per cluster per hour more than Standard, about $4,380 per cluster per year, it pays off for regulated, stateful or vendor-pinned clusters that truly can't move every quarter. Anywhere else, it lets two years of upstream change pile up into one exit.

The case for LTS is real. You get fewer disruptive windows, backported security fixes on a version upstream has stopped patching, and predictable planning for compliance-heavy workloads.

The case against it is just as real. Your Helm charts, operators, CNCF projects and cloud SDKs keep moving on the upstream cadence no matter what Azure still patches. The exit from LTS is bigger, and AKS add-ons have their own lifecycles. For example, the managed Open Service Mesh add-on loses support on September 30, 2027, whatever your Kubernetes version.

Here's the arithmetic: (Premium rate minus Standard rate) x 8,760 hours x clusters.

• 5 clusters: $0.50 x 8,760 x 5 = $21,900 per year.
• 20 clusters: $0.50 x 8,760 x 20 = $87,600 per year.

Compare that with the engineering days a quarterly upgrade cadence really costs you. If upgrades are automated and rehearsed, that's a few days a quarter. If they're manual heroics, LTS can look cheap, but that's a symptom of the manual process, and LTS doesn't fix it.

If you run more than one cloud, the vendor policies don't line up:

Prices come from the EKS pricing page and GKE pricing page, as of November 2026. One pattern stands out: all three hyperscalers charge about $0.60 an hour for the second year.

My default recommendation is to track N-1 everywhere you can and reserve LTS for the specific clusters that provably can't move. Then write the policy down, with an owner and a review date. Every unsupported cluster I've seen had the same root cause: nobody owned the version policy.

How can a platform team stop Kubernetes upgrades from being a recurring fire drill?

Treat cluster lifecycle as a managed process with a named owner, not a quarterly act of heroism. Three things get you there: upgrades automated on a schedule you set, environments cheap enough to rehearse every upgrade, and application delivery decoupled from any specific cluster.

• Decouple delivery from cluster identity. If teams deploy through a platform layer instead of kubectl against a named cluster, you can swap the cluster underneath them without a company-wide migration.
• Make a throwaway clone of production cheap. Preview environments per pull request turn every upgrade into a rehearsed change.
• Automate detection. Run Pluto in CI, alert on support end dates, and keep one view of every cluster's version and remaining support across every cloud. On Azure, Fleet Manager can stage upgrades across clusters, as long as they stay in support.

This is where Qovery fits. Qovery deploys and operates your applications inside your own Azure, AWS, GCP or Scaleway account (BYOC), or on your existing Kubernetes cluster. The cloud bill, your Azure commitments and your Savings Plans stay in your name. Qovery handles managed cluster upgrades, so the upgrade becomes a platform job instead of one person's weekend.

Developers get git-push deployments, preview environments per pull request, auto-stop for non-production environments, per-environment RBAC, and databases backed by managed cloud services. Your team gets Kubernetes without operating it by hand, and you don't need a dedicated DevOps hire to ship.

The alternatives are good, and I mean that. Each one solves cluster lifecycle well. What separates them is the headcount they need:

If you want a deeper comparison, I covered Rancher alternatives and AKS vs EKS day-2 work separately.

I've run production Kubernetes and talked with more than 200 CTOs, and the pattern never changes. The upgrade itself is rarely the hard part. Nobody owns it. Qovery doesn't mean you stop caring about Kubernetes versions. It means the upgrade no longer depends on one person being free that weekend.

How do I audit and rehearse an AKS 1.37 upgrade from Claude Code or Cursor?

You can hand the inventory and rehearsal loop to a coding agent. Install the Qovery Agent Skills once and add the Qovery MCP Server (read-only by default), then ask in plain language. Every write action is proposed to you for approval before anything touches a cluster.

Install globally for every compatible agent (Claude Code, Cursor, Codex, OpenCode, Gemini CLI):

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

Or scope it to the current project:

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

Add the MCP Server to operate what already exists (OAuth, read-only by default):

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

Enable write access only when you explicitly want it. This also requires turning on write access in the Qovery Console:

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

The skills that ship are qovery-onboard, qovery-deploy, qovery-troubleshoot, qovery-optimize, qovery-speedup, qovery-preview and qovery-terraform. The skills deploy; the MCP Server operates what already exists. Then ask something like: "Spin up a preview environment on my Azure account so I can test the 1.37 upgrade before I touch production."

Write actions are always proposed first, and that matters when the target is a production cluster. Setup details are in the AI agent quickstart and the Claude Code integration page.