Update a MOSK cluster to a patch release version

Patch releases aim to significantly shorten the cycle of CVE fixes delivery onto your MOSK deployments to help you avoid cyber threats and data breaches.

Your management bare-metal cluster obtains patch releases automatically the same way as major releases. A new patch MOSK release version becomes available through the Container Cloud web UI after the automatic upgrade of the management cluster.

It is not possible to update between the patch releases that belong to different release series in one go. For example, you can update from MOSK 23.1.1 to 23.1.2, but you cannot immediately update from MOSK 23.1.x to 23.2.x because you need to update to the major MOSK 23.2 release first.

For the update procedure, refer to Mirantis Container Cloud Operations Guide: Update a patch Cluster release of a managed cluster.

Pre-update actions

Determine if cluster nodes need to be rebooted

The application of the patch releases may not require the cluster nodes reboot. Though, your cluster can contain nodes that require reboot after the last update to a major release, and this requirement will remain after update to any of the following patch releases. Therefore, Mirantis strongly recommends that you determine if there are such nodes in your cluster before you update to the next patch release and reboot them if any, as described in Step 4. Reboot the nodes with optional instance migration.

Consider pinning the Open vSwitch and Kubernetes entrypoint images

Applying a patch release may require the restart of the containers that host the elements of the cloud data plane. In case of Open vSwitch-based clusters, this may result in up to 5 minute downtime of workload network connectivity for each compute node.

You can determine whether applying a patch release is going to require the restart of the data plane by consulting the Release artifacts part of the release notes of the current and target MOSK releases. The restart will only happen if there are new versions of the container images related to the data plane.

It is possible to avoid the downtime for the cloud data plane by explicitly pinning the image versions of the following components:

  • Open vSwitch

  • Kubernetes entrypoint

However, pinning these images will result in the cloud data plane not receiving any security or bugfixes during the update.

To pin the images:

  1. Depending on the proxy configuration, the image base URL differs. To obtain the list of currently used images on the cluster, run:

    kubectl -n openstack get ds openvswitch-openvswitch-vswitchd-default -o yaml |grep "image:" | sort -u
    

    Example of system response:

    image: mirantis.azurecr.io/general/openvswitch:2.13-focal-20230211095312
    image: mirantis.azurecr.io/openstack/extra/kubernetes-entrypoint:v1.0.1-48d1e8a-20220919122849
    
  2. Add the openvswitch and kubernetes-entrypoint images used on your cluster to the openstackdeployment object:

    spec:
      services:
        networking:
          openvswitch:
            values:
              images:
                tags:
                  dep_check: <kubernetes-entrypoint-image-URL>
                  openvswitch_db_server: <openvswitch-image-URL>
                  openvswitch_vswitchd: <openvswitch-image-URL>
    

    For example:

    spec:
      services:
        networking:
          openvswitch:
            values:
              images:
                tags:
                  dep_check: mirantis.azurecr.io/openstack/extra/kubernetes-entrypoint:v1.0.1-48d1e8a-20220919122849
                  openvswitch_db_server: mirantis.azurecr.io/general/openvswitch:2.13-focal-20230211095312
                  openvswitch_vswitchd: mirantis.azurecr.io/general/openvswitch:2.13-focal-20230211095312