Cloud-Native Network Function (CNF)

CNFs decompose monolithic network functions into independently deployable microservices, each packaged as a lightweight container. This architecture enables:

• Isolated failure domains: A crash in one service (e.g., session management) does not bring down the entire stack
• Polyglot development: Teams can write different services in different languages
• Granular scaling: Only bottlenecked components scale out, not the entire function

Example: A 5G User Plane Function (UPF) might separate packet detection, forwarding, and reporting into distinct containers.

CNFs are deployed and managed by Kubernetes, the de facto container orchestration platform. This provides:

• Declarative desired state: Operators define the target configuration, and Kubernetes reconciles reality to match
• Self-healing: Failed containers are automatically restarted or rescheduled onto healthy nodes
• Service discovery: Built-in DNS and load balancing between microservices

Kubernetes replaces the VNF Manager (VNFM) used in legacy NFV architectures, unifying telecom and IT operations.

CNFs scale horizontally by adding or removing container replicas based on real-time demand, rather than vertically by adding resources to a single instance. Mechanisms include:

• Horizontal Pod Autoscaler (HPA): Scales based on CPU/memory metrics
• Custom metrics: Scales based on telecom-specific KPIs like active sessions or throughput
• Event-driven scaling: KEDA (Kubernetes Event-Driven Autoscaling) triggers scaling from message queue depth

This elasticity is critical for handling bursty traffic patterns without over-provisioning infrastructure.

CNFs embrace immutability: containers are never patched or modified in place. Instead, a new container image is built, tested, and deployed as a complete replacement. Benefits include:

• Reproducible deployments: The exact same artifact moves from CI/CD to production
• Rollback simplicity: Revert to a previous image version instantly
• Drift elimination: No configuration divergence between instances over time

This principle, combined with GitOps workflows, ensures that the desired state in a Git repository is the single source of truth.

CNFs leverage a service mesh (e.g., Istio, Linkerd) to externalize cross-cutting communication concerns from application code. The mesh provides:

• Mutual TLS (mTLS): Automatic encryption and authentication between all services
• Traffic splitting: Canary deployments and A/B testing for new CNF versions
• Observability: Distributed tracing, latency histograms, and success rate metrics without code changes

This is essential for the zero-trust security posture required in multi-tenant 5G core networks.

CNFs extend the Kubernetes API with Custom Resource Definitions (CRDs) to model telecom-specific resources. Operators define the desired state of a CNF using YAML manifests, and a custom operator (a Kubernetes-native controller) reconciles it. Examples:

• UPFDeployment: Defines a User Plane Function instance with specific QoS profiles
• SliceConfiguration: Declares a network slice with its associated CNFs

This pattern enables intent-based networking, where high-level business policies are automatically translated into infrastructure configuration.

A plugin interface that enables the kubelet to use a wide variety of container runtimes without needing to recompile Kubernetes. For CNFs, the CRI abstracts the underlying execution environment—whether containerd or CRI-O—allowing network functions to be deployed consistently across heterogeneous edge and core data centers. This decoupling is critical for telecom operators who must avoid vendor lock-in at the infrastructure layer.

A dedicated infrastructure layer that manages service-to-service communication within a CNF deployment. It provides:

• Mutual TLS (mTLS) for zero-trust encryption between microservices
• Traffic splitting for canary deployments of new network function versions
• Circuit breaking to prevent cascading failures across 5G control plane components In a CNF context, the service mesh offloads non-functional networking concerns from the application, allowing developers to focus on protocol logic.

The package manager for Kubernetes that defines, installs, and upgrades CNF applications. A Helm chart bundles all Kubernetes manifests—Deployments, Services, ConfigMaps—into a versioned, templated artifact. Telecom operators use Helm to manage the lifecycle of CNFs across multi-cluster environments, ensuring that a 5G User Plane Function (UPF) can be deployed identically in a central data center or at a far-edge cell site.

A method of extending the Kubernetes API to automate the operational knowledge of a CNF. An Operator is a custom controller that encodes human operator logic—such as rolling upgrades, backup and restore, and auto-scaling triggers—directly into software. For a CNF like a 5G Session Management Function (SMF), an Operator can automatically reconfigure the function when dependent resources change, achieving true zero-touch operations.

A specification for configuring network interfaces in Linux containers, focused on providing IP addresses and basic connectivity. In CNF deployments, CNI plugins like Multus enable advanced networking by attaching multiple interfaces to a single pod—allowing a 5G User Plane Function to have one interface for control signaling and another for high-throughput data plane traffic using SR-IOV or DPDK for hardware-accelerated packet processing.

An operational model where a Git repository serves as the single source of truth for the desired state of a CNF deployment. Tools like Argo CD or Flux continuously reconcile the live cluster state with the declarative configuration stored in Git. This provides:

• Auditability: Every configuration change is version-controlled
• Rollback capability: Instantaneous reversion to a known-good state
• Compliance: Automated drift detection for telecom regulatory requirements