Upgrades and Maintenance
Managing the lifecycle of your AKS cluster is a critical part of operating Kubernetes in production. This includes managing both the version of Kubernetes, and the Operating System running on your nodes.
Azure provides several tools and features to help you keep your cluster secure, up to date, and running smoothly with minimal disruption.
Kubernetes Version Upgrades
AKS supports in-place upgrades of the Kubernetes control plane and node pools. You can:
- Upgrade manually using the Azure CLI, Portal or Infrastructure as Code.
- This can include automated pipelines used to manage upgrades
- Use auto-upgrade channels to stay current with minimal effort
Keeping your cluster on a supported version ensures access to the latest features, bug fixes, and security patches. Microsoft provides 12 months of support for each GA version of Kubernetes. If you are on a version that is n-3 or older it means you are out of support and should plan to upgrade as soon as possible.
If you deploy a cluster in premium tier, you can also take advantage of the extended support lifecycle, which provides an additional 12 months of support for each version. This is particularly useful for regulated industries or mission-critical applications that require longer upgrade cycles.
Node Image Updates
Azure regularly publishes updated node images that include OS patches and runtime updates. You can:
- Trigger updates manually
- Enable automatic node image upgrades
This helps maintain security compliance and performance without needing to rebuild your node pools.
Auto-Upgrade Channels
For hands-off cluster management, AKS offers an auto-upgrade process that will apply updates for you automatically. These upgrades are split into two types:
- Kubernetes updates - manages the version of Kubernetes on your control plane and nodes
- Node updates - manages patching the operating system and software deployed to your nodes
Each of these types have different channels that allow you to select what level of updates are applied.
Kubernetes Update Channels
| Channel | Description | Example Behaviour | Notes |
|---|---|---|---|
| none | Disables auto-upgrades and keeps the cluster at its current version | Cluster stays at 1.31.7 even if newer versions like 1.31.9, 1.32.6, or 1.33.3 are available | Default setting if left unchanged |
| patch | Upgrades to the latest supported patch version within the same minor version | Cluster at 1.31.7 upgrades to 1.31.9 when available | Minor version remains unchanged |
| stable | Upgrades to the latest patch on minor version N-1 | Cluster at 1.31.7 upgrades to 1.32.6 if 1.33.3 is the latest minor version | Balances stability and currency |
| rapid | Upgrades to the latest patch on the latest minor version | Cluster at 1.31.7 upgrades to 1.32.6, then to 1.33.3 | Fastest path to latest supported version |
These channels help balance stability and agility based on your workload needs.
Node Updates Channels
| Channel | Description |
|---|---|
| None | Nodes do not receive automatic security updates. You are fully responsible for patching and maintenance. |
| Unmanaged | OS updates are applied automatically via the OS’s built-in patching tools. Newly created nodes may be unpatched initially. |
| SecurityPatch | AKS-tested security patches are applied using safe deployment practices. Nodes may be re-imaged or patched live depending on the update. This option incurs extra cost for hosting VHDs. |
| NodeImage | Weekly updates apply a new AKS-tested node image with security and bug fixes. Updates follow maintenance windows and surge settings. No extra VHD cost. |
Maintenance Windows
To reduce disruption, AKS allows you to define maintenance windows — specific time periods when auto-upgrades are run. This gives you control over when changes occur, helping avoid impact during critical business hours.
Avoid Breaking API Changes
When upgrading your AKS cluster, it is important to be aware of any breaking changes that may affect your workloads. The default configuration of AKS enables a feature to prevent Kubernetes upgrades if breaking API changes are detected. This feature is used when triggering upgrades through the portal, CLI or through auto-upgrade channels.
You can view the list of breaking changes affecting your clusters through the Azure Portal in the “Diagnose and Solve Problems” blade for your AKS cluster. This will show you any breaking changes that have been detected, and allow you to take action to resolve them before upgrading.
