Patch releases¶
Since Container Cloud 2.23.2, the release train comprises several patch releases that Mirantis delivers on top of a major release mainly to incorporate security updates as soon as they become available without waiting for the next major release. By significantly reducing the time to provide fixes for Common Vulnerabilities and Exposures (CVE), patch releases protect your clusters from cyber threats and potential data breaches.
Major and patch versions update path
The primary distinction between major and patch product versions lies in the fact that major release versions introduce new functionalities, whereas patch release versions predominantly offer minor product enhancements, mostly CVE resolutions for your clusters.
Depending on your deployment needs, you can either update only between major Cluster releases or apply patch updates between major releases. Choosing the latter option ensures you receive security fixes as soon as they become available. Though, be prepared to update your cluster frequently, approximately once every three weeks. Otherwise, you can update only between major Cluster releases as each subsequent major Cluster release includes patch Cluster release updates of the previous major Cluster release.
Content delivery in major and patch releases¶
As compared to a major Cluster release update, a patch release update does not involve any public API or LCM changes, major version bumps of MKE or other major components, workloads evacuation. A patch cluster update only may require restart of containers running the Container Cloud controllers, MKE, Ceph, and StackLight services to update base images with related libraries and apply CVE fixes to images. The data plane is not affected.
The following table lists differences between content delivery in major releases as compared to patch releases:
Content |
Major release |
Patch release |
|---|---|---|
Major version upgrade of the major product components including but not limited to Ceph and StackLight 0 |
||
Patch version bumps of MKE and Kubernetes 1 |
||
Container runtime changes including Mirantis Container Runtime and containerd updates |
||
Changes in public API |
||
Changes in the Container Cloud lifecycle management |
||
Host machine changes including host operating system updates and upgrades, kernel updates, and so on |
||
CVE fixes for images |
||
Fixes for known product issues |
Update paths for major vs patch releases¶
Management clusters obtain patch releases automatically the same way as major releases. Managed clusters use the same update delivery method as for the major Cluster release updates. New patch Cluster releases become available through the Container Cloud web UI after automatic upgrade of a management cluster to the latest patch Cluster release.
You may decide to use only major Cluster releases without updating to patch Cluster releases. In this case, you will perform updates from an N to N+1 major release.
Major Cluster releases include all patch updates of the previous major Cluster release. However, Mirantis recommends applying security fixes using patch releases as soon as they become available to avoid security threats and potentially achieve legal compliance.
If you delay the Container Cloud upgrade and schedule it at a later time as described in Schedule Mirantis Container Cloud updates, make sure to schedule a longer maintenance window as the upgrade queue can include several patch releases along with the major release upgrade.
For the update procedure, refer to Operations Guide: Update a patch Cluster release of a managed cluster.
Patch update schemes before and since 2.26.5¶
Starting from Container Cloud 2.26.5 (Cluster releases 16.1.5 and 17.1.5), Mirantis introduces a new update scheme for managed clusters allowing for the update path flexibility.
Since Container Cloud 2.26.5 |
Before Container Cloud 2.26.5 |
|---|---|
The user can update a managed cluster to any patch version in the series even if a newer patch version has been released already. Note In Container Cloud patch releases 2.27.1 and 2.27.2, only the 16.2.x patch Cluster releases will be delivered with an automatic update of management clusters and the possibility to update non-MOSK managed clusters. In parallel, 2.27.1 and 2.27.2 will include new 16.1.x and 17.1.x patches for MOSK 24.1.x. And the first 17.2.x patch Cluster release for MOSK 24.2.x will be delivered in 2.27.3. For details, see MOSK documentation: Update path for 24.1 and 24.2 series. |
The user cannot update a managed cluster to the intermediate patch version in the series if a newer patch version has been released. For example, when the patch Cluster release 17.0.4 becomes available, you can update from 17.0.1 to 17.0.4 at once, but not from 17.0.1 to 17.0.2. |
The user can always update to the newer major version from the latest patch version of the previous series. Additionally, there will be another possibility of major update during the course of the patch series from the patch version released immediately before the target major version. |
If the cluster starts receiving patch releases, the user must apply the latest patch version in the series to be able to update to the following major release. For example, to obtain the major Cluster release 17.1.0 while using the patch Cluster release 17.0.2, you must update your cluster to the latest patch Cluster release 17.0.4 first. |
Latest supported patch releases¶
The following table lists the latest Container Cloud 2.29.x patch releases and their supported Cluster releases that are being delivered on top of the Container Cloud major release 2.29.0. Click the required patch release link to learn more about its deliverables.
Patch release |
Container Cloud |
|||
|---|---|---|---|---|
Release history |
Release date |
Apr 22, 2025 |
Mar 26, 2025 |
Mar 11, 2025 |
Patch Cluster releases (managed) |
17.3.x
MOSK 24.3.x
|
|||
16.4.x |
16.4.1
|
|||
16.3.x |
Legend
Symbol |
Definition |
|---|---|
Cluster release is not included in the Container Cloud release yet. |
|
Cluster release is deprecated, and you must update it to the latest supported Cluster release. The deprecated Cluster release will become unsupported in one of the following Container Cloud releases. Greenfield deployments based on a deprecated Cluster release are not supported. Use the latest supported Cluster release instead. |