Network Function Virtualization (NFV) has historically relied on hypervisor-based infrastructure and dedicated VNF managers (VNFMs) from vendors such as Nokia, Cisco, Ericsson, Huawei, and NEC, as well as open-source platforms like OpenStack Tacker. Over the past few years, a significant shift has occurred: the industry is moving from virtualisation toward containerisation, and Kubernetes has emerged as the leading orchestration platform driving this change—including within NFV architectures.
The momentum of this shift was visible at VMworld 2019, where VMware’s announcements underscored that enterprise IT infrastructure is increasingly built around Kubernetes clusters rather than traditional VM-centric approaches. Meanwhile, the Cloud Native Computing Foundation (CNCF) has been actively pushing cloud-native projects into enterprise IT and telecom environments, positioning containerised and microservices-based methods as the foundation for modern data centres.
From VNFs to CNFs: The Cloud-Native Transition in NFV
NFV gave CXOs the ability to move toward software-defined data centres by replacing dedicated network hardware with Virtual Network Functions (VNFs) running on commodity infrastructure. With the rise of cloud-native development practices, VNFs are evolving into Cloud-Native Network Functions (CNFs)—network functions architected using containers and, in many cases, microservices.
Cloud-native development of network functions offers several advantages over traditional VNF approaches:
- Portability and reusability: CNFs can run independently of the underlying infrastructure, making code portable across environments.
- Elastic scaling: Applications can scale up or down dynamically in response to demand, which is essential for variable network traffic.
- Microservices-compatible: While not mandatory, CNFs can be decomposed into microservices for finer-grained lifecycle management.
- Distributed computing support: CNFs are well suited for distributed and elastic computing environments, including edge deployments.
- DevOps and agile enablement: Cloud-native NFV allows teams to apply DevOps practices—CI/CD pipelines, automated testing, rapid iteration—to network function development.
Container orchestration engines like Kubernetes become the natural management layer for CNFs, bringing the same operational dynamism to the NFV core stack that Kubernetes already provides for application workloads.
Kubernetes in the NFV Picture
Kubernetes has matured into a platform capable of handling diverse workload types across data centres of every scale, and increasingly at the network edge. For NFV specifically, Kubernetes provides several capabilities that make it a practical orchestration layer:
- Unified workload orchestration: Kubernetes can host VNFs, CNFs, standard containers, and serverless functions within a single cluster, allowing mixed workload architectures without separate management planes.
- Multi-site orchestration via ONAP: ONAP (Open Network Automation Platform) is a leading service orchestrator and NFV MANO platform. A Kubernetes plugin developed for ONAP enables orchestration of services and workloads across multiple sites from a single control plane.
- Lightweight deployment with ONAP4K8S: ONAP has historically been resource-intensive in terms of storage and memory. A lighter-weight profile called ONAP4K8S has been developed to fit within a broader range of NFV architectures. Requirements and package contents are published on its project profile page.
- VM integration where needed: Not all network functions can be containerised. Legacy VNFs that must remain on virtual machines can be managed alongside containers using projects such as KubeVirt (from the Kubernetes community) and Mirantis’s Virtlet framework, both of which integrate VM lifecycle management directly into Kubernetes.
- Edge orchestration: Kubernetes-based control planes consume relatively few resources, making them suitable for edge nodes running on limited hardware—sometimes as few as a single server.
Several industry collaborations around 5G have specifically targeted the combination of Kubernetes for container orchestration and OpenStack for legacy VM management, reflecting the reality that many production NFV deployments must support both paradigms during the transition period.
The Cloud-Native NFV Stack: Akraino and ICN
The Akraino Edge Stack project hosts a blueprint called the Integrated Cloud Native (ICN) NFV Stack, which brings together open-source cloud-native projects to build a fully cloud-native NFV core. The ICN blueprint integrates contributions from Linux Foundation communities including ONAP, OPNFV, CNCF, and LF Edge (LFE), with ongoing development aimed at making core NFV components cloud-native by default.
Progress across these communities reflects a broader industry consensus: Kubernetes is becoming the de facto orchestration layer not only for cloud-native applications but for the network functions that underpin telecommunications infrastructure.
VNF to CNF Evolution: A Visual Summary
The following diagram (sourced from Calsoft’s engineering blog) illustrates how network function management has evolved: from traditional VNF management, through hybrid VNF/CNF environments, to a Kubernetes-centric architecture capable of handling both VNFs and CNFs as first-class workloads.
Key Takeaways for DevOps and Platform Teams
- Kubernetes is no longer purely an application orchestration tool—it is increasingly being adopted as the control plane for NFV workloads in telecom and enterprise environments.
- The transition from VNFs to CNFs is underway, but hybrid architectures supporting both VMs and containers (via KubeVirt or Virtlet) will remain common for the foreseeable future.
- ONAP provides the service orchestration and MANO layer above Kubernetes; the ONAP4K8S profile reduces resource overhead for constrained environments.
- Open-source communities—CNCF, ONAP, OPNFV, LF Edge—are actively collaborating to define and standardise cloud-native NFV stacks, with Kubernetes at the centre.
- Edge deployments benefit from Kubernetes’s lightweight control plane, making it practical even for single-server edge nodes.
This article is based on analysis originally published in 2019 reflecting the state of cloud-native NFV at that time. The Kubernetes, ONAP, and Akraino ecosystems have continued to evolve since publication.