Skip to content

feat(blog): add platform-initiated upgrades post (draft) - #6058

Open
KAARTHIKEYAN SUBRAMANIAN (kaarthis) wants to merge 1 commit into
Azure:masterfrom
kaarthis:blog/platform-initiated-upgrades
Open

KAARTHIKEYAN SUBRAMANIAN (kaarthis) wants to merge 1 commit into
Azure:masterfrom
kaarthis:blog/platform-initiated-upgrades

Conversation

@kaarthis

Copy link
Copy Markdown
Contributor

Draft post on AKS platform-initiated upgrades starting June 1, 2027, with guidance for multi-cluster (Fleet Manager), LTS, capacity, and workload disruption. Incorporates reviewer feedback from the Word draft.

Draft post on AKS platform-initiated upgrades starting June 1, 2027, with guidance for multi-cluster (Fleet Manager), LTS, capacity, and workload disruption. Incorporates reviewer feedback from the Word draft.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 Changes recommended

The guidance can omit clusters from larger fleet inventories and mislead readers about restoring unsupported clusters to support and choosing valid upgrade paths.

3 open issues
What changed in this PR

Adds a draft AKS blog post explaining platform-initiated upgrades starting June 1, 2027, and how teams can prepare unsupported clusters.

Changes:

  • Explains support deadlines, upgrade eligibility, and potential workload disruption.
  • Provides cluster inventory guidance and upgrade planning options using Fleet Manager, LTS, and capacity controls.
  • Covers workload readiness, lifecycle notifications, and supporting documentation.
File Description
website/​blog/​2026-11-12-platform-initiated-upgrades/​index.md Adds the draft policy overview and practical upgrade preparation guidance.

Review effort: Balanced

Comment on lines +51 to +61
For a precise list, run this Azure Resource Graph query. It returns each cluster's Kubernetes version, support plan (`KubernetesOfficial` for community or `AKSLongTermSupport` for LTS), and upgrade channel:

```bash
# Requires the Azure CLI resource-graph extension: az extension add --name resource-graph
az graph query -q "resources
| where type =~ 'microsoft.containerservice/managedclusters'
| project name, resourceGroup, subscriptionId,
kubernetesVersion = tostring(properties.kubernetesVersion),
supportPlan = tostring(properties.supportPlan),
upgradeChannel = tostring(properties.autoUpgradeProfile.upgradeChannel)
| order by kubernetesVersion asc" --output table

Treat upgrades like a release: development, then test, staging, and production.

[Azure Kubernetes Fleet Manager](https://learn.microsoft.com/azure/kubernetes-fleet/overview) is built for this. Organize your clusters into ordered stages with reusable [update strategies](https://learn.microsoft.com/azure/kubernetes-fleet/update-create-update-strategy). Stages run in order, and the groups inside a stage update in parallel. Pair a strategy with a Fleet [auto-upgrade profile](https://learn.microsoft.com/azure/kubernetes-fleet/update-automation) on the **Stable** channel, and Fleet rolls new Kubernetes versions through your environments as AKS releases them, keeping member clusters in support.

For clusters on unsupported Kubernetes versions that you still need, compare an in-place upgrade with migrating to a new, supported cluster:

- **In-place upgrade.** The cluster moves one minor version at a time, so a cluster that's far behind needs several upgrades.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants