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 MCC). This means everything you need is in one place. The separate MCC 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.

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 Container Cloud 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

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 Container Cloud 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.