For telecom service providers and enterprises modernising their data centres, containerised workloads have become a priority. Yet few organisations can or should abandon virtual machines overnight. Legacy applications, isolation requirements, and existing tooling all demand continued VM support. This tension has driven the rise of a hybrid model: managing VMs with OpenStack and containers with Kubernetes — often on the same underlying infrastructure.
According to an OpenStack user survey conducted in 2018, 61% of OpenStack deployments were also running Kubernetes alongside it. Whether or not that figure has shifted since, the directional trend is clear from industry activity alone.
Industry Signals: Why Kubernetes and OpenStack Are Converging
Several high-profile initiatives illustrate how seriously the industry has taken this combination:
- AT&T and Mirantis entered a multi-year agreement to develop a 5G core infrastructure backed by both Kubernetes and OpenStack.
- Platform9 launched a managed offering bundling OpenStack and Kubernetes into a single solution stack for service providers and developers, including support for Kubernetes on VMware.
- Nokia’s CloudBand platform incorporated both Kubernetes and OpenStack for workload orchestration in telco environments.
- The OpenStack Foundation’s Airship project was announced specifically to bring OpenStack and Kubernetes together into a unified lifecycle management framework for data centres.
The Shift from VNFs to CNFs
The core of a modern telecom network — and increasingly the virtualised core of enterprise data centres — has undergone a significant architectural shift. Network functions moved from dedicated physical hardware to Virtual Network Functions (VNFs) running in virtual machines. The next step in this evolution is Cloud-Native Network Functions (CNFs), which run in containers and embrace CI/CD-driven development and deployment patterns.
This progression was described in a Telecom User Group session at KubeCon Barcelona 2019. The session, delivered by Dan Kohn (then Executive Director of CNCF) and Cheryl Hung (then Director of Ecosystem at CNCF), illustrated how OpenStack manages VM-based VNFs while Kubernetes orchestrates CNFs — with both layers operating on top of bare metal or cloud infrastructure. ONAP, a containerised Management and Network Orchestration (MANO) framework, was shown as an optional layer managed by Kubernetes.
The expectation, as discussed at that session, is that CNFs will become an increasingly dominant workload type. Kubernetes will be used to orchestrate both CNFs and, over time, VNFs — with VM isolation provided by projects such as KubeVirt, Virtlet, or OpenStack running on top of Kubernetes.
Three Approaches for Integrating Kubernetes and OpenStack
There is no single canonical way to combine Kubernetes and OpenStack. The right approach depends on your operational maturity, performance requirements, and how far along your cloud-native journey you are. Three main integration patterns have emerged:
Approach 1: Side-by-Side Co-existence
In this model, Kubernetes and OpenStack run independently on the same infrastructure. OpenStack manages VMs; Kubernetes manages containers. Neither system is aware of the other’s workloads.
Advantages: Relatively straightforward to implement; good raw performance for each workload type.
Disadvantages: No unified control plane. Resource planning, policy enforcement, and troubleshooting must be handled separately for each system. Diagnosing cross-workload performance problems is difficult, and applying consistent network or security policies across both environments is operationally expensive.
Approach 2: Kubernetes Clusters Running Inside OpenStack VMs
In this model, Kubernetes clusters are deployed within VMs that OpenStack manages. OpenStack acts as the infrastructure layer; Kubernetes operates inside it.
Advantages: Full multi-tenancy and security isolation from OpenStack can be applied to Kubernetes workloads. The existing OpenStack control plane and its networking and storage features remain available. This is a practical path for organisations with significant OpenStack investments.
Disadvantages: The additional virtualisation layer introduces performance overhead. Operational complexity increases because you must manage both the VMs hosting Kubernetes and the Kubernetes clusters themselves. Lifecycle management of the nested infrastructure requires additional automation tooling.
Approach 3: Kubernetes as the Unified Orchestration Layer
In this more forward-looking model, Kubernetes becomes the primary orchestration layer for both containers and VMs. OpenStack’s role may diminish or be restructured underneath Kubernetes. Projects like KubeVirt allow VMs to be scheduled and managed as Kubernetes workloads, alongside containers.
Advantages: A single control plane for all workloads. Full access to hardware accelerators and SmartNICs. Integrated VNF and CNF solutions become possible from a single orchestration layer.
Disadvantages: This approach demands advanced networking capabilities — service function chaining (SFC), provider networks, network segmentation — that OpenStack has developed over years and that Kubernetes-native networking is still maturing toward. Operational readiness and ecosystem support are prerequisites that many organisations have not yet reached.
Is This Kubernetes vs. OpenStack?
The framing of Kubernetes versus OpenStack is misleading. At events like VMworld 2019, Kubernetes featured heavily — across many sessions covering integration into nearly every aspect of IT infrastructure. This visibility has led some to conclude that Kubernetes will replace OpenStack.
That conclusion misreads the situation. OpenStack and Kubernetes solve overlapping but distinct problems. OpenStack has deep integrations with enterprise storage systems, physical networking hardware, and multi-tenant security models that Kubernetes does not replicate. Kubernetes provides declarative, self-healing container orchestration that OpenStack was not designed to deliver. Organisations that try to force either system to do everything tend to encounter real operational pain.
The practical path for most data centre operators is a deliberate combination of both — using each where it is strongest, with clear integration points between them.
Benefits of Running Kubernetes and OpenStack Together
When the integration is thoughtfully designed, the combined stack offers concrete operational advantages:
- Immediate modernisation path: Existing VM-based workloads continue to run unmodified under OpenStack while new containerised workloads are introduced through Kubernetes. This avoids a high-risk big-bang migration.
- Unified networking and security policy: Workloads on both systems can share a single network fabric and a consistent policy model, simplifying compliance and security operations.
- Enterprise storage and networking compatibility: OpenStack supports a wide range of enterprise storage backends and networking systems. Running Kubernetes on top of OpenStack allows containers to leverage the same storage and networking integrations without rebuilding them.
- Self-healing infrastructure: Kubernetes brings self-healing capabilities for containerised services. Integrated into an OpenStack environment, this can extend automated recovery to core services and compute nodes.
- Edge and far-edge deployments: The combination is well-suited to far-edge cloud scenarios where automated deployment, low latency, and compact footprints matter.
- Faster cluster provisioning: Work done by the team behind OpenStack-integrated Kubernetes installers has significantly reduced cluster bootstrap times. (The original article claims a reduction from 10–12 minutes to under 5 minutes for any cluster size using OpenStack Stein — see review notes.)
Relevance to 5G and Telecom Infrastructure
Telecom service providers moving toward 5G have broadly agreed that a cloud-native network core is a requirement, not an option. 5G architectures demand the kind of continuous deployment, automated scaling, and rapid failure recovery that containerised infrastructure enables.
OpenStack and Kubernetes are both mature, open-source frameworks with active communities and proven production deployments at scale. OpenStack brings the storage, networking, and multi-tenancy capabilities that telco environments need. Kubernetes brings the agility and automation that cloud-native service delivery demands. Together, they form a credible foundation for 5G core infrastructure — which is precisely why operators like AT&T have made long-term commitments to this combined approach.
Choosing Your Integration Strategy
The right integration approach depends on where your organisation sits on the cloud-native maturity curve:
- If you are early in your Kubernetes adoption and have a large existing OpenStack environment, Approach 2 (Kubernetes inside OpenStack VMs) is the lowest-risk starting point.
- If you are operating two separate teams and need quick wins without deep integration work, Approach 1 (co-existence) buys time while you plan a longer-term strategy.
- If you are building greenfield infrastructure or a new network edge deployment, Approach 3 (Kubernetes as the unified layer) is worth serious evaluation, particularly as KubeVirt matures.
None of these approaches is permanent. Most organisations will move through them progressively as their teams build expertise and as the upstream projects — particularly KubeVirt, Cluster API, and OpenStack’s own Kubernetes integrations — continue to mature.