Release channels

Managed Service for Kubernetes provides updates through release channels.

Managed Service for Kubernetes supports three Kubernetes release channels. Master node and Managed Service for Kubernetes node group versions are independent. You can specify different Kubernetes versions in a single release channel when creating them.

When creating a Managed Service for Kubernetes cluster, specify one of the three release channels. You cannot change the channel after the Managed Service for Kubernetes cluster is created. You can only recreate the cluster and specify a new release channel. The table below describes the release channels and supported Kubernetes versions.

Channel	Kubernetes versions	Auto updates	Channel description
rapid	1.30, 1.31, 1.32, 1.33, 1.34	Auto updates cannot be disabled. You can specify a time period for auto updates.	A channel receives updates with new features and improvements first.
regular	1.30, 1.31, 1.32, 1.33	Auto updates can be disabled.	New features and improvements are added shortly after they appear on rapid.
stable	1.30, 1.31, 1.32	Auto updates can be disabled.	New features and improvements are added shortly after they appear on regular.

UpdatesUpdates

When a release channel receives an update, you get a notification in the management console. You can install updates automatically or manually.

• Auto updates are installed within the specified time period. They do not require any user actions.

  Updates are initiated and should be completed within this time period. In some cases, when updating a Managed Service for Kubernetes node group, an update may continue beyond this period.

  Auto updates include new Managed Service for Kubernetes features, improvements, and fixes, as well as Kubernetes component fixes.

• Manual updates can be initiated by the user at any time.

  They include Kubernetes minor version updates. Note that you can only update on minor version at a time.

  For example, from 1.31 to 1.32.

  The version difference between the cluster and the node groups must not exceed two minor versions. The node group version cannot be higher than the cluster version.

  For example, if the cluster version is 1.33, the node group version can be 1.33, 1.32, or 1.31

Read more about the Kubernetes version’s end of support and how different Managed Service for Kubernetes cluster components are updated.

End of support for a Kubernetes versionEnd of support for a Kubernetes version

When upgrading from a Kubernetes version that is no longer supported:

• The Managed Service for Kubernetes master is not auto updated, you need to do it manually.
• Minor versions (e.g., 1.20 to 1.21) must be updated manually.
• Managed Service for Kubernetes node groups are updated automatically if auto updates are enabled. If auto updates are disabled, the old version of Kubernetes remains on the Managed Service for Kubernetes node groups. In this case, the user has to deal with any issues with their Managed Service for Kubernetes node group on their own, since the old version of Kubernetes is no longer supported.

Updating Kubernetes cluster componentsUpdating Kubernetes cluster components

The update process is different for a Managed Service for Kubernetes master and a node group.

MasterMaster

The amount of time a Managed Service for Kubernetes master is unavailable during an update depends on the master type:

• The basic master is unavailable during the update.
• The highly available master maintains network connectivity during the update.

For more information, see Updating a cluster.

Node groupNode group

You can update a Managed Service for Kubernetes node group with additional resources allocated by creating nodes with a new configuration.

The Managed Service for Kubernetes node group update algorithm is as follows:

1. An updated node is created with the configuration specified for the entire Managed Service for Kubernetes node group.
2. All the pods are evicted from one of the old Managed Service for Kubernetes nodes based on the pre-defined PodDisruptionBudgets policy. Then the node is deleted.
3. The process is repeated until all the Managed Service for Kubernetes nodes in the group are updated.

This ensures that the number of nodes in the group never falls below the number specified when creating a Managed Service for Kubernetes node group.

You can specify the maximum number of VM instances by which you can expand or reduce the size of the Managed Service for Kubernetes group when updating it. For more information, see Updating a node group.

CertificatesCertificates

In accordance with the safety recommendations, Managed Service for Kubernetes cluster and node group certificates are valid for one year. When a certificate expires, a Managed Service for Kubernetes cluster or node group will be disabled. To avoid this, Managed Service for Kubernetes automatically updates their certificates.

• If automatic updates are enabled, certificates are auto updated whenever a Managed Service for Kubernetes cluster or node group updates.
• If automatic updates are disabled, a certificate update will be forced a week before they expire.

For more information about updating certificates, see this Kubernetes guide.

Required updateRequired update

All Managed Service for Kubernetes release channels enforce required updates, such as replacements for outdated Kubernetes versions or critical updates for vulnerability patching. They may be installed both during and outside the update window.

If a cluster has a scheduled required update:

• You will get a notification about a scheduled update. Make sure you have set up your notification methods.
• On the cluster information page, you will see the Mandatory update scheduled section indicating the date.

Features of a required update:

• You cannot opt out of required updates.

• If the random update time mode is enabled in your cluster, Managed Service for Kubernetes will initiate the update on its own schedule.

• If the cluster has no update window or the window is set for a specific time, by default, the required update will be installed after 14 days. You can reschedule the required update to an earlier date.

• If the cluster has an update window, this is when the required update will take place. However, if the cluster is unavailable at the time of the update, it will be applied during one of the next update windows.

• Stopped clusters will be updated during their update windows in the order defined by Managed Service for Kubernetes.

For more information, see Working with required updates.