Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
An Azure Kubernetes Service (AKS) cluster needs to be periodically updated to ensure security and compatibility with the latest features. There are two components of an AKS cluster that are necessary to maintain:
- Cluster Kubernetes version: Part of the AKS cluster lifecycle involves performing upgrades to the latest Kubernetes version. It’s important that you upgrade to apply the latest security releases and to get access to the latest Kubernetes features, as well as to stay within the AKS support window.
- Node image version: AKS regularly provides new node images with the latest OS and runtime updates. It's beneficial to upgrade your nodes' images regularly to ensure support for the latest AKS features and to apply essential security patches and hot fixes.
For Linux nodes, node image security patches and hotfixes may be performed without your initiation as unattended updates. These updates are automatically applied, but AKS doesn't automatically reboot your Linux nodes to complete the update process. You're required to use a tool like kured or node image upgrade to reboot the nodes and complete the cycle.
The following table summarizes the details of updating each component:
| Component name | Frequency of upgrade | Planned Maintenance supported | Supported operation methods | Supported operation methods (Multi-Cluster) | Documentation link |
|---|---|---|---|---|---|
| Cluster Kubernetes version upgrade (minor) | Roughly every three months | Yes | Automatic, Manual | Automatic, Manual | Upgrade an AKS cluster, Multi-cluster upgrade |
| Cluster Kubernetes version upgrade (patch) | Approximately weekly. To determine the latest applicable version in your region, see the AKS release tracker | Yes | Automatic, Manual | Manual | Upgrade an AKS cluster, Multi-cluster upgrade |
| Node image version upgrade | Linux: weekly Windows: monthly |
Yes | Automatic, Manual | Automatic, Manual | AKS node image upgrade, Multi-cluster upgrade |
| Security patches and hot fixes for node images | As-necessary | Unsupported | AKS node security patches |
Multi-cluster upgrade
When you have multiple clusters, an important practice that you should include as part of your upgrade process is remembering to follow commonly used deployment and testing patterns. Testing an upgrade in a development or test environment before deployment in production is an important step to ensure application functionality and compatibility with the target environment. It can help you identify and fix any errors, bugs, or issues that might affect the performance, security, or usability of the application or underlying infrastructure.
Azure Kubernetes Fleet Manager has built-in support for multi-cluster upgrades which implements the best practice above to minimize application disruptions caused by cluster upgrades. Besides allowing you to customize the order of upgrades of multiple clusters, it also allows you to use consistent node OS image versions across clusters in different regions.
Automatic upgrades
Automatic upgrades can be performed through auto upgrade channels or via GitHub Actions.
Automatic multi-cluster upgrades can be performed through Azure Kubernetes Fleet Manager to adopt the best practice of testing and verifying an upgrade in a development or test environment before production.
Planned maintenance
Planned maintenance allows you to schedule weekly maintenance windows that will update your control plane and your kube-system pods, helping to minimize workload impact.
Troubleshooting
To find details and solutions to specific issues, view the following troubleshooting guides:
Next steps
For more information what cluster operations may trigger specific upgrade events, upgrade best practices, and other considerations, see the AKS operator's guide on patching.