timetobail

Azure Kubernetes Service (AKS) · Forced move · Tracked since October 17, 2026 · Sources checked Oct 17

Time to bail on AKS clusters on unsupported Kubernetes versions?

Time to Bail · Boarding pass

FromAKS clusters on unsupported Kubernetes versions
ToYour pick

Act. You can stay.

From June 1, 2027, AKS upgrades clusters left on unsupported versions, outside your maintenance window.[1]

Act means: change a setting or plan before the date. You can stay.

Gate closes
Platform-initiated upgrades start
Time left
226days
Status
Act

AKS starts upgrading unsupported clusters June 1, 2027

From June 1, 2027, AKS upgrades clusters that still run an unsupported Kubernetes version. It ignores your maintenance window and the deprecated API check. There is no opt-out.

Email me 7 days before Jun 1

One email with the first steps. Nothing else.

Or add the date to your calendar: Apple or Outlook (.ics) · Google Calendar

How it is winding down

  1. May 31Upgrade at your own pace untilNext
  2. Jun 1Platform-initiated upgrades start

What to do before June 1

Tick steps as you go. Your progress stays in this browser.

  1. Find clusters out of support

    Check the Kubernetes version of each cluster against the AKS release calendar.

  2. Remove deprecated APIs

    In the Azure portal, open Diagnose and solve problems, then Kubernetes API deprecations. Fix what it finds.

  3. Upgrade on your own schedule

    Upgrade with az aks upgrade before May 31, 2027. Then set the stable auto-upgrade channel.

Email me 7 days before Jun 1

One email with the first steps. Nothing else.

Or add the date to your calendar: Apple or Outlook (.ics) · Google Calendar

Facts we checked

Facts and their sources
Platform-initiated upgrades startJune 1, 2027[1]
Which clustersClusters on an unsupported Kubernetes version after the platform support grace period[1]
Upgrade at your own pace untilMay 31, 2027[2]
What it ignoresYour maintenance window and the deprecated API check; it can override a Pod Disruption Budget that blocks a node drain[1]
Expected versions after itKubernetes 1.36 or later; clusters enrolled in LTS: 1.33 LTS or later[2]
How it movesOne minor version at a time until the cluster reaches a supported version[1]
Exact dayNot fixed: during or after the listed month, rate-limited by region, subscription and version[2]
Later versionsEach end of life then gets a 60-day grace period before these upgrades[2]
Can you opt out?No[1]
Long-term supportNever automatic; you must enable it[1]
Clusters on unsupported versionsUpgraded by AKS from June 1, 2027[1]

After June 1, 2027 you will see

AKS upgrades the cluster itself, one minor version at a time. It does not wait for your maintenance window. It does not stop if you still use removed APIs. Workloads may be disrupted.

Fix

  1. List the versions in your region: az aks get-versions --location <region> --output table
  2. Upgrade the cluster: az aks upgrade --resource-group <resource-group> --name <cluster-name> --kubernetes-version <target-version>
  3. Update manifests, clients and add-ons that use APIs the new version removed.

Source: [1] Supported Kubernetes versions in Azure Kubernetes Service (AKS) (Microsoft) · [2] Platform-initiated upgrades in Azure Kubernetes Service (AKS) (Microsoft)

Sources

Check it yourself. Every fact above links here.

  1. Supported Kubernetes versions in Azure Kubernetes Service (AKS) Microsoft · primary · checked Oct 17
  2. Platform-initiated upgrades in Azure Kubernetes Service (AKS) Microsoft · primary · checked Oct 17
Read the published editorial report

What changed

Time to bail on AKS clusters on unsupported Kubernetes versions? Act. You can stay. From June 1, 2027, AKS upgrades clusters left on unsupported versions, outside your maintenance window.

On our scale this is Act: change a setting or plan before the date. You can stay.

From June 1, 2027, AKS upgrades clusters that still run an unsupported Kubernetes version. It ignores your maintenance window and the deprecated API check. There is no opt-out.

Here are the facts we checked:

  • Platform-initiated upgrades start: June 1, 2027 (Microsoft)
  • Which clusters: Clusters on an unsupported Kubernetes version after the platform support grace period (Microsoft)
  • Upgrade at your own pace until: May 31, 2027 (Microsoft)
  • What it ignores: Your maintenance window and the deprecated API check; it can override a Pod Disruption Budget that blocks a node drain (Microsoft)
  • Expected versions after it: Kubernetes 1.36 or later; clusters enrolled in LTS: 1.33 LTS or later (Microsoft)
  • How it moves: One minor version at a time until the cluster reaches a supported version (Microsoft)
  • Exact day: Not fixed: during or after the listed month, rate-limited by region, subscription and version (Microsoft)
  • Later versions: Each end of life then gets a 60-day grace period before these upgrades (Microsoft)
  • Can you opt out?: No (Microsoft)
  • Long-term support: Never automatic; you must enable it (Microsoft)
  • Clusters on unsupported versions: Upgraded by AKS from June 1, 2027 (Microsoft)

You can stay on Azure Kubernetes Service (AKS). You have to change a setting or plan before the date.

Leaving is a choice here, not a must.

Microsoft is the main source for this page. Azure Kubernetes Service (AKS) has not said more than what is listed here. If a fact is not on this page, we do not know it yet.

Who is affected

Clusters on unsupported versions: Upgraded by AKS from June 1, 2027.

The date to remember is June 1, 2027. Make the change before then.

What to do before June 1

  1. Find clusters out of support. Check the Kubernetes version of each cluster against the AKS release calendar.
  2. Remove deprecated APIs. In the Azure portal, open Diagnose and solve problems, then Kubernetes API deprecations. Fix what it finds.
  3. Upgrade on your own schedule. Upgrade with az aks upgrade before May 31, 2027. Then set the stable auto-upgrade channel.

A few tips:

  • Make the change yourself before the date. Do not wait for the last reminder email.
  • Write down your current plan or settings first, so you can compare after the change.
  • After the change, open your settings again and check that it worked.

How to tell your users

If the change affects your members or team, send one short email. Say what changes for them and when. Put the most important line first.

If there is a date, send a short reminder a few days before it. Keep a copy of the list you sent it to.

Options people mention

Listed for convenience. Not ranked. Not paid. These names come up in threads and reviews; that does not show where people moved.

Before you pay, check the price page of each tool yourself. Prices change, and we only list what our sources say.

Questions people ask

No questions collected yet.

Sources

Thanks.

Did this answer your question?

Run SaaS spend at work? Get these changes before the invoice

Arrivals · for builders

Building where they land?

People on AKS clusters on unsupported Kubernetes versions can stay if they make the change. Some would rather leave. Get the playbook for this change, and list your product here.

Listing is free. An editor checks it. Not ranked. Not paid.