This article draws on reporting originally published by SDxCentral (March 2020). Some vendor initiatives and project statuses may have evolved since then.
Why 5G Needs a Cloud-Native Core
The commercial promise of 5G — ultra-reliable low-latency communications (URLLC), network slicing, edge services, and converged access — depends on more than just new radio hardware. Fulfilling that promise requires telecommunication providers to fully embrace cloud-native architectures and container-based infrastructure.
Nokia has publicly argued that a cloud-native core is the only viable path forward. That position is not unique: research firm ABI Research concluded that enterprise 5G momentum risks stalling entirely without a cloud-native platform as its foundation. The implication for network operators is stark — legacy virtualization approaches are insufficient to meet 5G’s architectural demands.
This is where Kubernetes enters the picture. The container orchestration platform is increasingly being positioned as the operational backbone for 5G infrastructure — automating workload scheduling, scaling, and lifecycle management tasks that previously required significant manual intervention.
From Theory to Demo: Kubernetes at KubeCon
The cloud-native 5G core is not purely theoretical. At KubeCon + CloudNativeCon North America 2019 in San Diego, Loodse demonstrated a cloud-native 5G network on an open architecture using its Kubermatic Kubernetes Platform. The demonstration showed how Kubermatic could act as a standardized compute infrastructure layer across multiple cloud providers, delivering consistency from cloud to core to edge.
The demo was developed in collaboration with the Linux Foundation’s LF Networking (LFN) Open Platform for NFV (OPNFV) project — a community framework for testing, iterating on, and validating common NFV infrastructure (NFVi). It also incorporated work from the OPNFV Verification Program (OVP), which verifies labs, infrastructure, and virtual network functions (VNFs).
“Containerization in 5G is not only possible, but it can be here today. The industry is changing and if telcos want to keep up they’d better start examining these technologies.”
Bill Mulligan, Kubernetes Advocate, Loodse (2019)
The VNF-to-CNF Transition
To understand why Kubernetes matters to telecom, it helps to understand the evolution from Virtual Network Functions (VNFs) to Containerized Network Functions (CNFs).
- VNFs run network functions — such as firewalls, load balancers, or evolved packet cores — inside virtual machines, typically orchestrated by platforms like OpenStack. AT&T, for example, has run its 5G and FirstNet services as VNFs.
- CNFs are the next evolution: they run the same networking logic inside containers in a cloud-native environment. This enables faster update cycles, finer-grained resource allocation, and better elasticity than VM-based VNFs.
The open source community formalized this transition with the launch of the CNF Testbed, a joint initiative between the Cloud Native Computing Foundation (CNCF) and LFN. Its stated goal was to demonstrate that the same networking code could run both as a VNF on OpenStack and as a CNF on Kubernetes — providing operators with a migration path rather than a hard cutover.
Industry vendors have moved quickly to support this transition:
- Red Hat and Intel created a cloud-based onboarding service and testbed designed to reduce VNF and CNF deployment complexity and bridge compatibility gaps between the two models.
- VMware partnered with Nokia to expand interoperability testing of Nokia VNFs and CNFs running on VMware’s Telco Cloud platform.
The Language Barrier: Security, Networking, and DevOps Teams
Technical architecture is only part of the challenge. A recurring theme among telecom and cloud-native practitioners is the organizational friction between teams that must work together to deliver production-ready Kubernetes deployments in telecoms.
Scott Sneddon, Senior Director and Cloud Evangelist at Juniper Networks, described the problem directly in an interview with SDxCentral:
“Often times security teams are perceived as the people that slow stuff down, the networking team is often still doing manual process and generally takes a long time to get stuff done, and the cloud and DevOps teams either go into public cloud to get around that, or they’re deploying on top of servers and they’re not asking a lot of the network team.”
Scott Sneddon, Senior Director and Cloud Evangelist, Juniper Networks
Sneddon explained that Juniper’s Contrail software portfolio is specifically designed to give networking and security teams tooling that speaks the same operational language as DevOps teams — enabling network-as-a-service delivery models where security policy is designed in from the start rather than bolted on afterward.
“Once we have a common language, once we have a little bit more understanding of how to deliver a network-as-a-service to DevOps teams, then Kubernetes applications become production ready because the requirements of the network were thought of in advance because security policy was designed in.”
Scott Sneddon, Juniper Networks
Red Hat’s Chief Technologist of Cloud and Virtualization, Azhar Sayeed, echoed this broader challenge: “We have to rethink networking” — a statement that applies as much to organizational process as to technical architecture.
Maturity Concerns and the Kubernetes Ramp
Kubernetes was not originally designed with telecom-grade reliability requirements in mind. Network operators expect carrier-grade availability — historically defined as five-nines (99.999%) uptime — along with deterministic latency, strict regulatory compliance, and support for stateful network functions. These requirements push Kubernetes beyond its default capabilities.
Heather Kirksey, VP of Community and Ecosystem Development at the Linux Foundation, offered a measured perspective: telecom adoption could itself accelerate Kubernetes maturation, because “when telecom adopts a technology it tends to bring a maturity perspective.” The implication is that telco use cases will drive hardening of the platform in ways that benefit the broader ecosystem.
In the meantime, several vendors have invested in managed Kubernetes platforms and edge-optimized distributions aimed at closing the maturity gap:
- Cisco, Red Hat/IBM, and Dell/VMware have launched managed Kubernetes platforms targeting enterprise and telco deployments.
- Rancher Labs, CDNetworks, and Edgeworx have introduced lightweight Kubernetes distributions optimized for resource-constrained edge environments — a critical requirement for 5G edge deployments where compute nodes may have limited CPU, memory, and storage.
Key Takeaways for DevOps Engineers in Telecom
For DevOps and platform engineers working at or with telecommunications providers, the 5G-Kubernetes intersection raises several practical considerations:
- OpenStack is not going away overnight. Most operators have significant OpenStack investments. The VNF-to-CNF path is a migration, not a replacement — hybrid environments running both will be the norm for years.
- CNF design requires rethinking state management. Containers are ephemeral by default; stateful network functions require careful design around persistent storage, fast failover, and session continuity.
- Networking and security must be first-class Kubernetes citizens. CNI plugin selection, network policy enforcement, and integration with existing OSS/BSS systems are non-trivial and require cross-team collaboration.
- Edge Kubernetes distributions matter. 5G edge nodes often run in constrained environments. Lightweight distributions (K3s, MicroK8s, and others) are worth evaluating for edge deployments alongside full Kubernetes for core functions.
- Organizational alignment is as important as tooling. The cross-team language barrier between networking, security, and cloud-native DevOps teams is a real delivery risk that tools alone cannot solve.
Conclusion
Kubernetes is not a silver bullet for 5G core complexity, but it represents the most credible open platform available for managing the containerized network functions that next-generation networks require. The ecosystem — from CNCF and LFN to vendors like Nokia, VMware, Red Hat, and Juniper — is actively closing the gaps between what Kubernetes provides out of the box and what carrier-grade deployments demand.
The path from legacy NFV to cloud-native CNFs will be gradual, and success will depend as much on cross-organizational alignment as on technology choices. For DevOps engineers entering this space, understanding both the orchestration layer and the telecom-specific requirements it must satisfy is essential groundwork.