Network functions have moved from dedicated appliances to software. First came virtualised network functions (VNFs) running in virtual machines; now cloud-native network functions (CNFs) run in containers orchestrated by Kubernetes. This article explains how the two models differ and what that means for the engineers who deploy and operate them.
From appliances to software
Traditionally, each network function — a packet gateway, a session border controller, a CSCF — ran on purpose-built hardware supplied by the vendor. Scaling meant buying more boxes, and upgrades were tied to hardware cycles.
Network Functions Virtualisation (NFV), driven by the ETSI NFV industry group from 2012, separated the software from the hardware. Network functions became applications running on standard servers, sharing a common infrastructure.
What is a VNF?
A Virtualised Network Function is a network function packaged as one or more virtual machines. It runs on the NFV Infrastructure (NFVI) — compute, storage and networking resources, typically managed by a Virtualised Infrastructure Manager (VIM) such as OpenStack or VMware.
The ETSI MANO (Management and Orchestration) framework defines how these are managed:
- NFVO (NFV Orchestrator) — manages network services and resources across the infrastructure.
- VNFM (VNF Manager) — handles the lifecycle of individual VNFs: instantiation, scaling, healing and termination.
- VIM — controls the underlying compute, storage and network resources.
Many early VNFs were close to “lifted and shifted” appliance software: large VMs, with internal redundancy and state handled much as before. This delivered hardware independence, but not always the agility operators hoped for.
What is a CNF?
A Cloud-Native Network Function is designed for containers. The function is broken into smaller microservices, each running in containers grouped into Kubernetes pods, and deployed and managed declaratively — often with Helm charts or Kubernetes operators.
The 5G Core’s service-based architecture fits this model well, which is why most 5GC implementations are built as CNFs. Kubernetes provides scheduling, self-healing, rolling upgrades and horizontal scaling, and the network function is expected to be designed around them: stateless where possible, with state held in dedicated data stores.
Key differences at a glance
| Aspect | VNF | CNF |
|---|---|---|
| Packaging | Virtual machine images | Container images, Helm charts or operators |
| Orchestration | VNFM and NFVO over a VIM | Kubernetes, often with an orchestrator above it |
| Scaling | Add or remove VMs; typically slower | Add or remove pods; typically faster and more granular |
| Upgrades | Often VM replacement or in-service procedures | Rolling updates and canary releases |
| Healing | VNFM-driven, or built into the application | Kubernetes restarts or reschedules failed pods |
| Resource footprint | Each VM carries its own guest operating system | Containers share the host kernel |
Networking: where telecom differs from IT
A typical web application needs a single network interface. Telecom network functions often need several separated networks — for signalling, user plane, operations and management — and some need very high packet throughput.
- Multiple interfaces. Kubernetes gives each pod one interface by default; telecom CNFs commonly use Multus to attach additional networks.
- High-performance data plane. User-plane functions such as the UPF may use SR-IOV to give pods direct access to network card virtual functions, and DPDK to process packets in user space.
- Resource pinning. CPU pinning, NUMA alignment and huge pages may be required for consistent performance, which affects node configuration and scheduling.
- Protocols beyond HTTP. SCTP for NGAP, GTP-U and PFCP over UDP, and Diameter all need to be supported through the cluster’s networking and load balancing.
These requirements mean that a “standard” Kubernetes cluster rarely runs telecom CNFs without preparation. Platform readiness is a significant part of any CNF project.
Operating CNFs: practical considerations
- Observability. Correlate platform metrics (pod restarts, resource limits, node pressure) with network function KPIs and logs. A healthy cluster does not guarantee a healthy service.
- Configuration management. Keep Helm values and manifests in version control, and use automated pipelines so every environment is deployed the same way.
- Upgrade testing. Rolling upgrades are only safe if the network function handles them gracefully; test upgrade and rollback under realistic load before production.
- Readiness and liveness probes. Badly tuned probes can cause restart loops, or route traffic to pods that are not ready.
- Security. Apply least-privilege pod security, network policies and image scanning — some telecom workloads need elevated privileges, which should be granted deliberately and documented.
VNF or CNF?
Most operators run both. Established VNFs remain in service where they are stable and well understood, while new functions — especially in the 5G Core — arrive as CNFs. The right choice depends on what the vendor supports, the maturity of your cloud-native platform, your teams’ skills and your operational processes. Moving to CNFs is as much an operational change as a technical one, and works best with automation and clear ownership between platform and application teams.
Summary
VNFs virtualised the network function; CNFs re-architect it for containers and Kubernetes. CNFs offer faster scaling, simpler upgrades and better resource efficiency, but they place new demands on networking, platform engineering and operations.
KL-UK supports VNF and CNF deployment, integration and lifecycle operations, and builds the DevOps pipelines and automation that cloud-native telecom depends on. For the 5G Core that most CNFs implement, see Understanding 5G Standalone Architecture.
Published by KL-UK on . This article is for general information and does not replace vendor documentation or the relevant 3GPP specifications.