Most teams can get OpenStack running, but keeping it running without burning out your engineers is the harder problem. Mirantis OpenStack packages upstream OpenStack with the validated builds, deployment tooling, and vendor support that platform teams need for stability. With Mirantis OpenStack for Kubernetes (MOSK), the architecture goes even further. Your entire OpenStack control plane runs as containerized workloads on Kubernetes, enabling rolling upgrades, self-healing, and a single operational model for VMs and containers.
This guide covers how Mirantis OpenStack works, what changes when Kubernetes manages the control plane, and where operational gaps around data protection tend to surface.
What Mirantis OpenStack Is and How It Works
At its core, Mirantis OpenStack is upstream OpenStack with an operational layer built around it. The code underneath is the same open-source project you’d pull from community repositories, but what ships on top of it (validated builds, deployment automation, security patching, and a support contract) is what separates it from a DIY installation.
Core Components of the Mirantis OpenStack Platform
Mirantis OpenStack bundles the foundational OpenStack services that most production clouds depend on: Nova for compute, Neutron for networking, Cinder for block storage, Keystone for identity and authentication, Glance for image management, and Heat for orchestration. These are curated upstream versions that Mirantis has tested together as a single, cohesive release.
What Mirantis layers on top matters just as much as the services themselves. You get deployment tooling that handles initial provisioning, monitoring integrations for observability from day one, and tested reference architectures that eliminate guesswork around component compatibility. Each release undergoes validation, where specific service combinations and patches are verified for stability. That saves platform teams weeks of integration testing that they’d otherwise spend on every upgrade cycle. And when you’re running production workloads, having a solid backup strategy for your virtual machines alongside a validated platform becomes equally important.
The value of Mirantis OpenStack isn’t in proprietary code. It’s in the operational burden it removes: validated builds, coordinated security patches, and a single vendor accountable for the full stack.
How Mirantis Differs From Vanilla OpenStack
Vanilla OpenStack is a loosely coupled collection of projects. Each service has its own release cadence, dependency tree, and upgrade path. If you run it yourself, your team owns packaging, dependency management, cross-service compatibility testing, and every security patch across every component. That operational surface area grows fast.
Mirantis consolidates that responsibility into a single vendor relationship. You get SLAs for response times, security backports applied across all bundled services, and CVE management handled centrally rather than tracked per-project by your engineers. When a critical vulnerability surfaces in Neutron or Keystone, Mirantis delivers a tested patch rather than leaving your team to assess upstream fixes, test compatibility, and deploy manually.
Mirantis OpenStack for Kubernetes (MOSK) Explained
Running OpenStack on top of Kubernetes flips the traditional deployment model on its head. Instead of installing OpenStack services directly onto bare-metal nodes as system-level processes, MOSK packages the entire control plane into containers managed by Kubernetes. That single architectural decision changes how you upgrade, scale, and recover from failures.
How Kubernetes Integration Changes OpenStack Deployment
In a traditional Mirantis OpenStack setup, services like Nova, Neutron, and Keystone run as processes tied to specific servers. Upgrading means coordinating maintenance windows, draining nodes, and hoping nothing breaks mid-process. With MOSK, each OpenStack service runs inside a Kubernetes pod. You can roll upgrades one pod at a time, and if a service crashes, Kubernetes automatically restarts it without human intervention.
The efficiency gains are real: Kubernetes bin-packs workloads across available nodes, so your control plane uses hardware more effectively. Need to scale up? Add pods. Scaling down? Remove them. No re-imaging servers or reconfiguring service endpoints. Your operations team also gets to use tools they likely already know, like kubectl, Helm charts, and GitOps workflows, instead of maintaining a separate set of OpenStack-specific deployment scripts.
Here’s a side-by-side comparison showing how MOSK differs from a traditional Mirantis OpenStack deployment across the dimensions that matter most to operations teams.
Key MOSK Use Cases
Telecom operators are a natural fit. Network functions virtualization (NFV) workloads still rely on OpenStack for running VNFs, but operations teams increasingly want Kubernetes-native lifecycle management underneath. MOSK gives them both without forcing a full re-architecture. Telecom providers running OpenStack at scale already understand the operational weight of managing these environments, and Kubernetes-native tooling helps reduce that burden significantly.
Large enterprises consolidating private cloud platforms also benefit. Platform teams already managing Kubernetes clusters can extend their existing skills to OpenStack operations rather than maintaining two completely different toolchains. Software-defined data centers and organizations migrating legacy VM workloads round out the primary use cases. The common thread is that MOSK fits best where teams already have Kubernetes operational knowledge and want a consistent management plane across VM and container workloads.
Deploying and Operating Mirantis OpenStack for Kubernetes
Getting MOSK deployed is surprisingly straightforward compared to traditional OpenStack installations. The harder question, and the one that catches most teams off guard, is what happens after deployment. Let’s walk through both sides.
What Mirantis OpenStack Deployment Looks Like
Mirantis offers MOSK as a free trial, which immediately lowers the barrier for platform teams evaluating whether the architecture fits their requirements. You don’t need to commit to a budget before you can kick the tires. The initial setup is GUI-driven, with cluster creation workflows that include built-in observability through the StackLight monitoring stack. StackLight is Grafana-based, giving you dashboards for both OpenStack and Kubernetes components from the moment your environment comes online. There’s no need to bolt on monitoring after the fact.
For regulated industries, MOSK ships with FIPS 140-2 and DISA STIG readiness baked in. Financial institutions and public sector organizations can evaluate the platform without wondering whether it’ll meet their compliance baselines. Organizations that prefer not to handle operations internally can also tap into Mirantis’s MCP AdaptiveOps managed services, effectively outsourcing Day-2 responsibilities to the vendor.
Day-2 Operations: What Teams Often Underestimate
Deployment is a single event; operations is everything that follows, and it’s where complexity quietly compounds. A typical MOSK environment spans Nova, Neutron, Cinder, Keystone, Glance, and Heat. Upgrading any single service can trigger compatibility issues with the others. Database schema migrations, API deprecations, and configuration drift all need to be detected and tested before reaching production. Miss one, and you’ll find yourself debugging cascading failures instead of shipping features.
Deployment is the easy part. The real operational challenge lives in Day-2: upgrades, patches, schema migrations, and the data protection gaps most teams address too late.
Here’s a practical upgrade planning checklist that covers the steps that experienced platform teams follow before touching a production MOSK environment:
- Audit current service versions: Document every OpenStack service version, Kubernetes version, and Helm chart revision running in your environment to establish a clear baseline.
- Build a staging environment: Replicate your production topology as closely as possible. Never test upgrades against production directly.
- Run integration tests: Validate API behavior across services post-upgrade, paying special attention to Neutron-Nova interactions and Keystone token handling.
- Document per-service rollback procedures: Each service needs its own rollback plan, including database schema downgrades where applicable.
- Schedule maintenance windows: Coordinate with tenant teams and downstream consumers. Even rolling upgrades can produce brief API latency spikes.
- Verify backups before starting: Confirm that recent, validated backups exist for control plane databases, persistent volumes, and tenant workloads.
Following these steps consistently turns upgrades from high-stress events into routine operations. But notice that last item on the list: backup verification. MOSK provides strong deployment and lifecycle tooling, yet data protection and disaster recovery for the workloads running on top of it remain a separate operational requirement. Most teams realize that this gap exists only after an incident forces the conversation, which is exactly the wrong time to start planning. The next section digs into why OpenStack backup deserves its own strategy and what that strategy should look like.
Backup and Data Protection for Mirantis OpenStack Environments
MOSK handles deployment and lifecycle management well. What it doesn’t handle is protecting the workloads running on top of it. That responsibility falls entirely on your team, and it’s the gap most organizations discover too late.
Why OpenStack Backup Is a Distinct Problem
Here’s a misconception that burns teams repeatedly: OpenStack snapshots are not backups. A Cinder snapshot or Nova instance snapshot lives on the same storage backend as the source data, so if that backend fails, you lose both the original and the snapshot in a single event.
Snapshots are also crash-consistent only, not application-consistent. Take a snapshot while a database is mid-transaction, and you could restore to a corrupted state. That’s not hypothetical but rather how storage-level snapshots work by design.
Without a dedicated backup strategy, you’re also missing cross-cloud recovery, multi-resource workload restore, and tenant self-service capabilities. In regulated sectors like finance and government, script-dependent or manual backup processes create compliance exposure. Auditors increasingly demand evidence-based proof of recoverability, not just documentation claiming that it exists. Organizations subjected to frameworks like DORA face even stricter requirements for operational resilience and demonstrable recovery capabilities.
Native OpenStack snapshots store data on the same backend as the source. A single storage failure destroys both your production data and your “backup” simultaneously.
What to Look for in a Mirantis OpenStack Backup Solution
A capable backup solution for Mirantis OpenStack environments needs agentless integration through native OpenStack APIs, with no sidecar agents consuming compute resources or introducing maintenance overhead. Application-consistent capture is non-negotiable; it ensures that databases and stateful applications are quiesced before backup, producing a restore point you can actually trust.
Workload-group backup, where VMs, volumes, network configurations, and metadata are captured as a single recoverable unit, eliminates the painful process of restoring components individually and manually reconnecting dependencies. Point-in-time recovery should let you restore a specific tenant’s workload to an exact moment without affecting unrelated services. Cross-cloud migration capability rounds out the list, allowing the same backup mechanism to move workloads between Mirantis OpenStack environments for disaster recovery or capacity rebalancing.
Purpose-built solutions like Trilio’s OpenStack Backup and Recovery address these requirements directly, offering agentless, application-consistent protection with self-service restore for tenants and full workload-group coverage across the stack.
Here’s how native OpenStack snapshots compare against Trilio across the capabilities that matter most for production environments.
Automated Red Hat OpenShift Data Protection & Intelligent Recovery
Perform secure application-centric backups of containers, VMs, helm & operators
Use pre-staged snapshots to instantly test, transform, and restore during recovery
Scale with fully automated policy-driven backup-and-restore workflows
Conclusion
Mirantis OpenStack for Kubernetes gives platform teams a solid foundation: validated builds, Kubernetes-native lifecycle management, and a unified operational model for VMs and containers. However, the platform’s strength in deployment and upgrades doesn’t carry over to protecting the workloads it runs. That gap between infrastructure management and data protection is where operational risk builds up, and closing it takes a deliberate, separate strategy.
If you’re evaluating MOSK or already running it, treat backup and disaster recovery as a parallel workstream from day one, not something to sort out after your first incident. Audit your current snapshot approach, test whether you can actually restore a multi-tier application end-to-end, and determine whether your recovery process produces the compliance evidence your auditors will eventually ask for. The earlier you answer those questions, the fewer surprises you’ll face in production. Schedule a demo with Trilio to see how OpenStack Backup and Recovery fits your Mirantis environment.
FAQs
Can Mirantis OpenStack run alongside existing Kubernetes clusters?
MOSK is designed so that its OpenStack control plane runs as containerized workloads on Kubernetes, allowing platform teams to manage both VMs and containers through a single operational toolchain they already use.
Are OpenStack snapshots sufficient for production backup and disaster recovery?
No. Native snapshots are crash-consistent and stored on the same backend as your source data, meaning that a storage failure can wipe out both simultaneously. Production environments need an independent backup solution that provides application consistency and stores data on a separate target.
What compliance certifications does Mirantis OpenStack for Kubernetes support out of the box?
MOSK ships with FIPS 140-2 and DISA STIG readiness built in, making it suitable for financial institutions and public sector organizations that must meet strict regulatory baselines without extensive custom hardening.
How do rolling upgrades work when the OpenStack control plane runs on Kubernetes?
Each OpenStack service runs in its own Kubernetes pod, so upgrades happen one pod at a time rather than requiring full maintenance windows. If a pod fails during the process, Kubernetes automatically restarts it, reducing both downtime and the need for manual intervention.
What is the role of k0rdent in a MOSK deployment?
k0rdent handles the provisioning, updating, and policy management of the underlying Kubernetes clusters that host the OpenStack control plane. It provides a single management layer for cluster lifecycle operations across multiple environments, including support for GPU-accelerated AI workloads.
