Skip to content

Upgrades#

Upgrading Mirantis Kubernetes Engine (MKE) clusters requires careful planning, validation, and execution. The upgrade processes featured herein are designed to ensure continuity of operations while transitioning your cluster components, configurations, and underlying architecture to newer versions of the platform. They include pre-upgrade checks, staged node upgrades, and post-upgrade validation to ensure that your cluster is fully functional in its new form. 

For existing MKE 4 clusters, upgrades are performed using the mkectl CLI and are tightly coupled to specific target versions. This ensures compatibility and stability during the upgrade process, with built-in mechanisms such as automated backups to safeguard cluster state. 

Upgrading from MKE 3.9.x to MKE 4 is a more significant transformation. It involves migrating from a hyperkube-based architecture to a k0s-based platform, along with configuration translation, component replacement, and cleanup of legacy MKE 3 elements.

Specific to MKE 4.2.0

  • Clusters must first be upgraded to MKE 3.9.x before they can be upgraded to the latest version of MKE 4. For more information, refer to Upgrade from MKE 3.7, 3.8, or 3.9.
  • MKE 4.2.0 clusters require that all nodes run cgroups v2. As such, upgrades are not suppored for MKE 3 or MKE 4 clusters on which any of the nodes are running cgroups v1, whether all nodes or a subset.

To ensure a smooth upgrade experience, before proceeding it is critical that you review the prerequisites, understand the supported upgrade paths, and prepare backups. You can rest assured, however, that in the event of upgrade failure, the system is designed to roll back to the previous state, thus minimizing disruption and preserving your cluster integrity. 

The documentation herein provides the guidance and step-by-step instruction you need to successfully upgrade your cluster, whether you are transitioning between MKE 4 versions or from MKE 3.x.