This article is based on reporting originally published by Container Journal in January 2020. Attribution is preserved where applicable.
The Growing Tension Between OpenStack and Kubernetes Communities
As Kubernetes has grown into the dominant container orchestration platform, open source contributors and enterprise IT organizations alike have been forced to make difficult choices about where to invest their time and infrastructure dollars. Two of the most prominent frameworks in cloud infrastructure — OpenStack and Kubernetes — have a relationship that is neither straightforwardly complementary nor directly competitive. It is, in a word, complicated.
Contributors to open source projects must decide where to prioritize their efforts, while IT organizations must determine to what degree they still need a framework like OpenStack to deploy and operate Kubernetes at scale.
How Kubernetes Has Typically Been Deployed
Historically, most Kubernetes deployments have run on top of virtual machine platforms — either open source hypervisors or commercial platforms such as VMware vSphere. Several practical factors drove this pattern:
- Workload isolation: Running Kubernetes clusters inside VMs provides a well-understood security and isolation boundary when multiple teams share the same physical infrastructure.
- Tooling familiarity: Many IT organizations lacked the skills to manage Kubernetes natively. Extending existing VM-centric tools to treat Kubernetes as another workload was operationally simpler.
- Risk management: Building on a proven virtualization layer reduced the perceived operational risk of adopting a new orchestration paradigm.
As a result, OpenStack — with its mature networking, storage, and compute APIs — became a natural substrate for Kubernetes clusters in many private cloud environments.
The Case for Moving Beyond OpenStack
The central question for 2020 and beyond was whether this approach would hold as organizations grew more comfortable with native Kubernetes tooling and lighter-weight alternatives emerged.
Rob Hirschfeld, CEO of RackN — a provider of an infrastructure automation platform built on open source Digital Rebar software — noted that lighter-weight alternatives to OpenStack and VMware for deploying Kubernetes clusters already existed at this time. The implication was clear: organizations willing to accept a learning curve could bypass the complexity of a full OpenStack deployment entirely.
Meanwhile, managed service providers such as Mirantis had begun rolling out highly distributed Kubernetes-based services that made no use of OpenStack whatsoever — signaling that the market was evolving past the assumption that OpenStack was a prerequisite for enterprise Kubernetes.
The OpenStack Foundation’s Perspective
Jonathan Bryce, executive director of the OpenStack Foundation (OSF), argued that OpenStack and Kubernetes would continue to evolve in a complementary fashion rather than as rivals. Organizations that had already invested heavily in OpenStack were unlikely to abandon that investment quickly — a reasonable assessment given the operational and organizational inertia involved in large infrastructure transitions.
Bryce also noted that the OpenStack community as a whole did not tend to be “super religious” about platforms like Kubernetes — acknowledging the pragmatic, ecosystem-aware stance the community had adopted.
OpenStack Projects Bridging the Gap
To remain relevant in a Kubernetes-dominated world, the OpenStack community had been developing tools designed to work alongside, rather than in opposition to, Kubernetes:
- Airship: A collection of open source tools for automating cloud infrastructure provisioning using a declarative, document-driven framework. Airship was designed to manage the full lifecycle of a cloud platform — including the underlying OpenStack services — in a Kubernetes-native way.
- Kata Containers: An open source container runtime that runs containers inside lightweight virtual machines. Kata Containers provided a middle ground between traditional KVM-based VMs and standard containers, offering stronger isolation than runC while remaining compatible with the Kubernetes CRI (Container Runtime Interface). This made it relevant to environments with strict security or multi-tenancy requirements.
Both projects reflected a broader strategy: rather than competing with Kubernetes directly, parts of the OpenStack ecosystem were repositioning to serve as infrastructure layers and security-focused complements to Kubernetes workloads.
Parallels with VMware’s Challenges
The OpenStack community was not alone in navigating these pressures. VMware faced a structurally similar challenge: its core value proposition was built around virtual machines, but the industry was shifting toward container-centric architectures where the VM was no longer the primary unit of deployment.
Both communities were grappling with the same fundamental question: in a world where Kubernetes is the de facto application platform, what role does the underlying virtualization layer play?
What the Future Deployment Landscape Looks Like
Rather than converging on a single deployment model, the likely outcome was a highly diverse ecosystem of Kubernetes deployments. Several patterns were expected to coexist:
- Kubernetes on traditional VMs (OpenStack or VMware): Legacy infrastructure investments and workload isolation requirements would keep this pattern alive for many years, particularly in regulated industries.
- Kubernetes on lightweight VMs: Projects like Kata Containers and firecracker-based microVMs offered stronger isolation than standard containers without the overhead of a full hypervisor stack.
- Kubernetes on bare metal: Greenfield cloud-native applications and performance-sensitive workloads would increasingly run on Kubernetes clusters deployed directly on physical servers, using tools like Digital Rebar, Metal3, or Cluster API providers.
- Managed Kubernetes services: Public cloud providers and managed service providers would continue to absorb complexity, allowing organizations to consume Kubernetes without managing the infrastructure layer at all.
Key Takeaways for Infrastructure and DevOps Teams
For DevOps and platform engineering teams evaluating their infrastructure strategy, the OpenStack-Kubernetes dynamic surfaces several practical considerations:
- If your organization has a mature OpenStack deployment, Kubernetes-on-OpenStack remains a viable path — particularly if workload isolation and multi-tenancy are hard requirements.
- If you are building a new private cloud from scratch, evaluate whether the full complexity of OpenStack is warranted, or whether a lighter-weight Kubernetes-centric stack (with tools like Cluster API, Rancher, or OpenShift) meets your needs.
- Projects like Kata Containers are worth tracking if you need container-level speed with VM-level isolation — especially in shared or regulated environments.
- Airship is relevant if you need declarative, GitOps-style lifecycle management of the full infrastructure stack beneath your Kubernetes clusters.
- Avoid assuming that managed Kubernetes services eliminate all infrastructure concerns — networking, storage, and security posture still require careful design regardless of the layer managing the control plane.
Conclusion
The relationship between OpenStack and Kubernetes is neither a clean handoff nor a zero-sum competition. It is an ongoing negotiation shaped by organizational inertia, workload requirements, tooling maturity, and community investment. The diversity of deployment patterns that was already visible in 2020 has only grown since. For most teams, the right answer depends less on ideology and more on a clear-eyed assessment of what they actually need from their infrastructure — and what operational cost they are willing to pay to get it.