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.

Cluster update known issues

This section lists the cluster update known issues with workarounds for the Mirantis OpenStack for Kubernetes release 22.4.

[26534] The ‘ironic-conductor’ Pod fails after the management cluster upgrade

Fixed in MOSK 22.5

After the Container Cloud management cluster upgrade from 2.19.0 to 2.20.0, the ironic-conductor Pod gets stuck in the CrashLoopBackOff state. The issue occurs due to the race condition between the ironic-conductor and ironic-conductor-http containers of the ironic-conductor Pod that try to use ca-bundle.pem simultaneously but from different users.

As a workaround, run the following command:

kubectl -n openstack exec -t <failedPodName> -c ironic-conductor-http -- chown 42424:42424 /certs/ca-bundle.pem

[24435] MetalLB speaker fails to announce the LB IP for the Ingress service

Fixed in MOSK 22.5

After updating the MOSK cluster, MetalLB speaker may fail to announce the Load Balancer (LB) IP address for the OpenStack Ingress service. As a result, the OpenStack Ingress service is not accessible using its LB IP address.

The issue may occur if the MetalLB speaker nodeSelector selects not all the nodes selected by nodeSelector of the OpenStack Ingress service.

The issue may arise and disappear when a new MetalLB speaker is being selected by the MetalLB Controller to announce the LB IP address.

The issue occurs since MOSK 22.2 after externalTrafficPolicy was set to local for the OpenStack Ingress service.

Workaround:

Select from the following options:

  • Set externalTrafficPolicy to cluster for the OpenStack Ingress service.

    This option is preferable in the following cases:

    • If not all cluster nodes have connection to the external network

    • If the connection to the external network cannot be established

    • If network configuration changes are not desired

  • If network configuration is allowed and if you require the externalTrafficPolicy: local option:

    1. Wire the external network to all cluster nodes where the OpenStack Ingress service Pods are running.

    2. Configure IP addresses in the external network on the nodes and change the default routes on the nodes.

    3. Change nodeSelector of MetalLB speaker to match nodeSelector of the OpenStack Ingress service.