Update notes

This section describes the specific actions you as a cloud operator need to complete before or after your Container Cloud cluster update to the Cluster releases 17.3.7, 16.3.7, or 16.4.2.

Consider the information below as a supplement to the generic update procedures published in MOSK Operations Guide: Automatic upgrade of a management cluster and Update to a patch version.

Pre-update actions

Ensure that local-volume-provisioner is healthy

Due to the known issue 50561, after machine disablement and consequent re-enablement, persistent volumes provisioned by local-volume-provisioner that are not currently in use by any pod may cause the local-volume-provisioner pod on such machine to switch to the CrashLoopBackOff state.

To ensure that local-volume-provisioner does not block cluster update and is healthy, either verify the cluster status in the Container Cloud web UI or run the following command:

kubectl -n kube-system get pods

Example of system response extract with healthy local-volume-provisioner:

local-volume-provisioner-dg98z 1/1 Running 0 66d

Example of system response extract with unhealthy local-volume-provisioner:

local-volume-provisioner-h5lrc   0/1   CrashLoopBackOff   33 (2m3s ago)   90m

If local-volume-provisioner is unhealthy, proceed with the workaround provided in the 50561 issue description.

Post-update actions

Mandatory migration of container runtime from Docker to containerd

Migration of container runtime from Docker to containerd, which is implemented for existing management and managed clusters, becomes mandatory in the scope of Container Cloud 2.29.x. Otherwise, the management cluster update to Container Cloud 2.30.0 will be blocked.

The use of containerd allows for better Kubernetes performance and component update without pod restart when applying fixes for CVEs. For the migration procedure, refer to MOSK Operations Guide: Migrate container runtime from Docker to containerd.

Important

Container runtime migration involves machine cordoning and draining.