Mirantis Container Cloud (MCC) becomes part of Mirantis OpenStack for Kubernetes (MOSK)!

Starting with MOSK 25.2, the MOSK documentation set covers all product layers, including MOSK management (formerly Container Cloud). This means everything you need is in one place. Some legacy names may remain in the code and documentation and will be updated in future releases. The separate Container Cloud documentation site will be retired, so please update your bookmarks for continued easy access to the latest content.

Update notes¶

This section describes the specific actions you as a Cloud Operator need to complete to accurately plan and successfully perform your Mirantis OpenStack for Kubernetes (MOSK) cluster update to the version 25.2. Consider this information as a supplement to the generic update procedure published in Operations Guide: Update a MOSK cluster.

Cluster update schema¶

You can update to the 25.2 version from the following cluster versions:

25.1 (released on March 11, 2025)
25.1.1 (released on August 11, 2025)

Note

For the detailed cluster update schema, refer to MOSK cluster update schema.

Major update impact and maintenance windows planning¶

The following table provides details on the impact of a MOSK cluster update to a major release.

Major update impact¶
Updated component	Impact on cloud users	Impact on cloud workloads
OpenStack and Tungsten Fabric	~1% of read operations on cloud API resources may fail ~8% of create and update operations on cloud API resources may fail	Open vSwitch networking - interruption of the North-South connectivity, depending on the type of virtual routers used by a workload: Distributed (DVR) routers - no interruption Non-distributed routers, High Availability (HA) mode - interruption up to 1 minute, usually less than 5 seconds Non-distributed routers, non-HA mode - interruption up to 10 minutes Tungsten Fabric networking - no impact
Ceph	~1% of read operations on object storage API may fail	IO performance degradation for Ceph-backed virtual storage devices. If you update MOSK from the Cluster releases 17.3.x or 17.4.x, plan extra time in the maintenance window for the cluster update due to the upstream Ceph issue 66717 that causes OSD slow start or failures. To shorten the OSD slow start and recovery Select one of the following options: Before the cluster update, set the `noout` flag: ceph osd set noout Once the Ceph OSDs image upgrade is done, unset the flag: ceph osd unset noout Monitor the Ceph OSDs image upgrade. If the symptoms of slow start appear, set the `noout` flag as soon as possible. Once the Ceph OSDs image upgrade is done, unset the flag.
Host OS components	No impact	Instance network connectivity interruption up to 5 minutes
Host OS kernel	No impact	Restart of instances due to the hypervisor reboot 0

0: Host operating system needs to be rebooted for the kernel update to be applied. Configure live-migration of workloads to avoid the impact on the instances running on a host.

Known issues during the update¶

Before updating the cluster, be sure to review the potential issues that may arise during the process and the recommended solutions to address them, as outlined in Cluster update.

Pre-update actions¶

Migrate container runtime from Docker to containerd¶

Migration of container runtime for the underlying Kubernetes cluster from Docker to containerd became mandatory in the scope of MOSK 25.1.x on existing deployments. Otherwise, the management cluster update to MOSK management 2.30.0 is blocked.

Therefore, before updating to MOSK 25.2, switch the container runtime to containerd that allows for better Kubernetes performance and component update without pod restart when applying fixes for CVEs.

Caution

Cluster update is not allowed during migration to prevent machines from running different container runtimes.

Important

Container runtime migration involves machine cordoning and draining.

Required action

Operations Guide: Migrate container runtime from Docker to containerd

Migrate deprecated size fields in BaremetalHostProfiles¶

Verify that deprecated minSizeGiB and maxSizeGiB parameters for the devices specification and the sizeGiB parameter for the partitions specification for devices, softRaidDevices, volumeGroups, and logicalVolumes sections are not used in the BareMetalHostProfile object.

If these parameters are specified, migrate them to the minSize, maxSize, and size parameters accordingly. Instead of floats that defined sizes in GiB for the *GiB parameters, use the <sizeNumber><unit> text notation, for example 512Ki, 128Mi, or 4Gi.

Caution

If the parameters are not migrated, they will be automatically removed from all BaremetalHostProfile objects for both management and MOSK clusters, which may cause those objects to become invalid. For potential issue resolutions, see [54981] Management or MOSK cluster update is stuck due to the invalid BareMetalHostProfile spec.

Prepare for Tungsten Fabric 21.4 upgrade to OpenSDN 24.1¶

MOSK introduces support for OpenSDN 24.1, successor to Tungsten Fabric, and automatically upgrades Tungsten Fabric 21.4 to OpenSDN 24.1 during the cluster update from the MOSK 25.1 series to the 25.2 release.

To ensure smooth upgrade, verify that tfVersion is not explicitly specified in the TFOperator custom resource.

Update the Alertmanager API v1 integrations to v2¶

Note

This step applies if you use the Alertmanager API v1 in your integrations and configurations. Otherwise, skip this step.

The deprecated Alertmanager API v1 is removed in MOSK 25.2 and MOSK management 2.30.0 to unblock Alertmanager upgrade to version 0.28.1, which supports only API v2. For details, see Deprecation Notes.

Therefore, if you use API v1, before updating to MOSK 25.2, update your integrations and configurations to use the API v2 ensuring compatibility with new versions of Alertmanager. Ongoing use of API v1 endpoints will result in errors or broken functionality after this upgrade.

Switch to the new RabbitMQ metrics and dashboards¶

Following the upstream deprecation in Prometheus, removed the deprecated prometheus-rabbitmq-exporter scrape job, RabbitMQ [Deprecated] Grafana dashboard, along with RabbitMQDown and RabbitMQExporterTargetDown alerts. For details, see RabbitMQ monitoring rework.

Therefore, if you use deprecated RabbitMQ metrics in customizations such as alerts and dashboards, switch to the new metrics and dashboards before updating to MOSK 25.2 to prevent issues when the deprecated metrics and dashboard are removed.

Increase the `max_message_size` setting¶

Due to a known issue [54430] AMQP message delivery fails when message size exceeds RabbitMQ limit, increase the max_message_size setting in the OpenStackDeployment custom rsource before updating to MOSK 25.2:

services:
  networking:
    rabbitmq:
      values:
        conf:
          rabbitmq:
            max_message_size: "67108864"

Post-update actions¶

Migrate KaaSCephCluster from a management to MOSK cluster¶

Since MOSK 25.2, the management cluster resources KaaSCephCluster and KaaSCephOperationRequest are deprecated and can be optionally migrated to the following Ceph resources of the corresponding MOSK cluster: MiraCeph, MiraCephHealth, MiraCephSecret, MiraCephMaintenance, and CephOsdRemoveRequest.

Mirantis recommends that you manually migrate KaaSCephCluster and KaaSCephOperationRequest resources from non-production management clusters to the corresponding MiraCeph resources of MOSK clusters to better prepare before automatic migration in one of the following releases. Although keep in mind that this migration is irreversible.

To manually test the migration on non-production clusters, set the following annotation in the metadata section of KaaSCephCluster on the management cluster:

apiVersion: kaas.mirantis.com/v1alpha1
kind: KaaSCephCluster
metadata:
  ...
  annotations:
    manual-get-rid-of-kaascephcluster: "true"

After setting this annotation, KaaSCephCluster will be automatically and safely removed from the management cluster and all Ceph management will be moved to the corresponding Ceph CRs of a MOSK cluster.

Prevent Docker restarts on manager nodes¶

Since MOSK 25.2 and MOSK management 2.30.0, MCR 25.0.12 is installed on manager nodes of MOSK and MOSK management clusters. This MCR version contains a compatibility issue with sending of telemetry statistics, which causes the Docker daemon, Docker container, and MKE-related services to restart every 24 hours.

As a temporary solution, disable sending of telemetry statistics in MKE as described in [7947] Docker panic causes its service restarts every 24 hours.