Workflow and configuration of management cluster upgrade

This section describes specifics of automatic upgrade workflow of a management cluster as well as provides configuration procedures that you may apply before and after automatic upgrade.

For the upgrade procedure of an air-gapped cluster, see Update a cluster in an air-gapped environment.

Automatic upgrade workflow

A management cluster upgrade to a newer version is performed automatically once a new MOSK version is released. For more details about the MOSK management release upgrade mechanism, see Release Controller.

The Operator can delay the automatic update procedure for a limited amount of time or schedule update to run at desired hours or weekdays. For details, see Schedule MOSK management updates.

MOSK remains operational during the management cluster update. MOSK clusters are not affected during this update. For the list of components that are updated, see the Release artifacts section for the management cluster of the corresponding major release in Release Notes.

When Mirantis announces support of the newest versions of Mirantis Container Runtime (MCR) and Mirantis Kubernetes Engine (MKE), MOSK automatically upgrades these components as well. For the maintenance window best practices before upgrade of these components, see MKE Documentation.

The release update train includes patch release updates being delivered between major releases. Patch release updates also involve automatic upgrade of a management cluster.

Post-upgrade steps

Once the management cluster is automatically upgraded to the latest version, proceed with the following steps:

Update the original bootstrap tarball for successful cluster management, such as collecting logs and so on:

Select from the following options:
- For clusters deployed using Container Cloud 2.11.0 (Cluster releases 7.1.0 and 6.18.0) or later:
```
./container-cloud bootstrap download --management-kubeconfig <pathToMgmtKubeconfig> \
--target-dir <pathToBootstrapDirectory>
```
- For clusters deployed using the Container Cloud release earlier than 2.11.0 (7.0.0, 6.16.0, or earlier), or if you deleted the kaas-bootstrap folder, download and run the bootstrap script:
```
wget https://binary.mirantis.com/releases/get_container_cloud.sh

chmod 0755 get_container_cloud.sh

./get_container_cloud.sh
```
Strongly recommended. Back up MKE as described in Mirantis Kubernetes Engine documentation: Back up MKE.

Since the procedure above modifies the cluster configuration, a fresh backup is required to restore the cluster in case further reconfigurations fail.
Important

Because the MKE restoration process is complicated, we strongly recommend contacting Mirantis support for assistance.

If you still decide to restore MKE from a backup on your own, you must scale down helm-controller on the cluster being restored if the MKE version of the affected cluster after the restore will differ from the MKE version in the ClusterRelease object that is set in MOSK Cluster objects in the management cluster:
- If you are restoring MKE on a management cluster: before starting the restore, scale down helm-controller on each affected MOSK cluster. This prevents unintended Ceph and OpenStack downgrades on MOSK clusters after the management cluster is restored.
- If you are restoring MKE on a MOSK cluster: immediately after the restore completes, scale down helm-controller. Because the restore rolls the cluster back to an older release, this prevents it from triggering a premature upgrade of Helm releases.