Major components and principles¶
This section provides an operational map of the Mirantis OpenStack for Kubernetes (MOSK) architecture for operators running production clouds. It defines the major building blocks and their implementations, enabling users to quickly identify the necessary handles for configuration changes, updates, and maintenance. By linking common symptoms to specific subsystems, this section established a practical mental model for troubleshooting, allowing for faster isolation of root causes during service disruptions.
At a high level, a MOSK environment consists of one management cluster and one or more MOSK clusters. The management cluster runs the control systems that provision infrastructure and coordinate lifecycle operations. MOSK clusters host the actual cloud control plane (containerized OpenStack) and provide services to cloud users.
Regardless of its role, any cluster in a MOSK deployment follows a consistent layered structure:
Bare metal nodes provide the physical compute and networking foundation.
A host operating system (Ubuntu Linux) runs on each node.
The Kubernetes underlay is implemented with Mirantis Kubernetes Engine (MKE).
The Kubernetes underlay relies on a container runtime, implemented with Mirantis Container Runtime (MCR).
On top of Kubernetes, MOSK runs Kubernetes controllers and operators. These operators manage the Kubernetes applications that implement the role of the cluster and provide lifecycle management for its subsystems.
MOSK management cluster¶
The MOSK management cluster is the central orchestration point of the environment. This cluster is responsible for provisioning and managing the underlying infrastructure, providing shared services for operators, and orchestrating changes across the entire stack.
The management cluster provides the following core capabilities:
Bare metal provisioning and host operating system management for nodes across the environment. These include discovery, provisioning, operating system installation, operating system configuration, and so on.
Kubernetes underlay lifecycle management for itself and for the MOSK clusters. It orchestrates the deployment, configuration, and updates of Mirantis Kubernetes Engine (MKE) and required Kubernetes extensions and operators.
Central identity and access management (IAM) for operators, and optionally cloud users.
An artifact caching proxy to accelerate and control the delivery of artifacts from Mirantis CDN or local mirrors.
Centralized logging, monitoring, and alerting (StackLight), and optional forwarding of selected telemetry to Mirantis for managed clouds.
A graphical user interface for operators, known as MOSK Management Console.
Full-stack updates delivery, orchestrating end-to-end update workflows across all layers, for both the management cluster and the MOSK clusters it controls.
Licensing control for the MOSK environment.
Components of a management cluster¶
The list of the key management cluster subsystems include:
Bare metal management, built on top of Metal³ (MetalKube), supplemented by Mirantis-specific extensions.
Kubernetes lifecycle management, historically referred to as MCC (Mirantis Container Cloud) or KaaS (legacy namings that may still appear in the code base, documentation, and APIs).
Identity and Access Management (IAM), implemented with Keycloak.
Artifact caching proxy, implemented with Squid.
Logging, monitoring, and alerting, implemented with Mirantis StackLight that comprises OpenSearch, Prometheus, Alertmanager, and Grafana.
Management GUI, known as MOSK management console.
MOSK clusters¶
MOSK clusters represent the workload plane of the environment, where the cloud provides functional services. These clusters run containerized OpenStack on top of a Kubernetes underlay and expose OpenStack APIs for tenant workloads and cloud users. They also incorporate networking, storage, and observability subsystems necessary to deliver cloud services.
Containerized OpenStack cluster¶
In MOSK, the OpenStack control plane lifecycle is Kubernetes-native, orchestrated by the open-source Kubernetes controller, OpenStack Controller (Rockoon).
Operators define the desired OpenStack configuration using Kubernetes Custom Resources (CRs), which Rockoon reconciles into the operational state of the OpenStack services running as containers. This approach ensures that configuration changes are explicit and declarative, and aligns OpenStack lifecycle operations with standard Kubernetes patterns.
A containerized OpenStack deployment in a MOSK cluster includes OpenStack services and supporting components required for a functional cloud control plane, such as RabbitMQ (message bus), MariaDB with Galera replication (persistent database layer), and PowerDNS.
A MOSK cluster commonly includes containerized core OpenStack services such as Keystone, Nova, Glance, Cinder, Neutron, and Designate, with flexibitility to enable additional cloud services.
While the OpenStack control plane runs as containers on Kubernetes, MOSK also runs the compute virtualization stack in containers. Libvirt and QEMU run as Kubernetes-managed workloads on compute nodes and use Linux Kernel-based Virtual Machine (KVM) in the host operating system for hardware-assisted virtualization.
Networking: SDN backends¶
To implement cloud networking, a MOSK cluster incorporates a Software-Defined Networking (SDN) backend. MOSK supports multiple backend options, allowing operators to select the implementation that best fits their operational model and requirements:
OpenStack Neutron with Open vSwitch (OVS)
OpenStack Neutron with Open Virtual Network (OVN)
OpenSDN (formerly Tungsten Fabric) for advanced networking use cases, managed by a dedicated lifecycle subsystem. This subsystem is implemented as a Kubernetes Controller that exposes its API through Kubernetes CRs
Storage¶
To provide persistent storage for workloads, a MOSK cluster can integrate multiple solutions:
Containerized Ceph, managed by Pelagia, a Mirantis open-source Kubernetes Controller that provides high-level operator APIs and automation on top of Rook.
Third-party enterprise storage integration as an alternative to Ceph, for example, Pure Storage, HPE, and Dell.
Observability: StackLight¶
Each MOSK cluster includes logging, monitoring, and alerting implemented with Mirantis StackLight. This subsystem collects operational signals across all layers of the stack - from host operating system and node-level metrics, to Kubernetes metrics, and to the controllers and applications running on the cluster - and integrates with the central StackLight running in the management cluster.
Major principles for MOSK cloud operations¶
Everything is a Kubernetes container¶
In MOSK, most platform and cloud components run as containers managed by Kubernetes, including the OpenStack services and their supporting components, as well as many lifecycle and management services. For operators, this translates to a Kubernetes-native operational model: health is inspected through Pod status, events, and logs, while changes are applied by updating Kubernetes-managed workloads. Because the Kubernetes underlay relies on the container runtime (MCR), issues at the runtime or scheduling can have platform-wide impact even if the host operating system and hardware remain healthy.
Management is declarative¶
A MOSK environment is operated primarily through Kubernetes Custom Resources (CRs). Cloud operators create or update CRs, and the corresponding controllers reconcile those desired states into actual states. Depending on the subsystem, these controllers are running in the management cluster and/or in the MOSK clusters.
This is the core organizational principle of MOSK lifecycle management: to modify the environment, an operator updates the relevant CR and monitors the reconciliation process.
Updates and upgrades¶
The management cluster serves as the central orchestration point for updates. It automatically downloads release metadata and can self-update automatically according to configured settings. Once the management cluster is updated, operators explicitly initiate updates for managed MOSK clusters, maintaining granular control over the timing and order of changes.
Updating a MOSK cluster does not automatically upgrade the OpenStack version. OpenStack upgrades are explicit operator actions. A single MOSK cluster version typically supports at least two OpenStack releases.
Note
Each major subsystem has release-specific update rules. Consult the subsystem documentation when planning changes.
Cluster release¶
A Cluster release defines a desired, validated state for a Kubernetes-based cluster. Rather than managing independent components, MOSK groups the key infrastructure components into a single versioned release that can be applied and validated as a coherent unit.
A Cluster release defines a specific set of component versions across the main infrastructure layers:
Host operating system (Ubuntu)
Kubernetes underlay (Mirantis Kubernetes Engine, MKE)
Container runtime (Mirantis Container Runtime, MCR)
Kubernetes Controllers/Operators (Lifecycle management logic)
Cluster releases exist because MOSK clusters contain tightly interacting components. Updating one layer without regard for the others is a common source of incompatibilities. By shipping and operating against a tested set of versions, MOSK reduces integration risk and provides operators with a predictable update target.
Cluster releases are role-specific, with distinct versions tailored for the management cluster and managed MOSK clusters. This reflects the fact that the management cluster runs a different set of lifecycle and shared services than a MOSK cluster running containerized OpenStack.