Nephio Extends Kubernetes to Solve Cloud Native Automation

Originally published on TheNewStack

The Nephio project was launched in 2022 by the Linux Foundation — who along with Google and a slew of telecom operators, solution vendors, and integrators — set out to build a unified platform that uses Kubernetes to provision intent-driven cloud native automation for large-scale 5G telecom network deployment.

The Nephio community is driven by the belief that cloud native automation has not been fully realized at the large-scale deployment of containers and virtual machines. Adopting a fully cloud native stack still requires effort in terms of capital and operational investment and still, results are not 100% perfect for adopters.

Currently, Kubernetes deployments are facilitating out-of-band automation with containers. Nephio enables Kubernetes to:

• Deploy the cloud infrastructure and network function on top of it without out-of-band management and…
• Manage the configuration of infrastructure and network functions of its own, reducing the need for external orchestration.

Nephio started with a tweak in the perception of how Kubernetes is being deployed and configured at a larger scale. We know that for large-scale or telecom networks, Kubernetes is well suited to act as a unified and automated control plane to configure all aspects of each infrastructure that may be distributed and host network functions.

But it was observed that Kubernetes has not been utilized to automate the cloud native functions (CNFs) and VNFs both. Nephio architecture will be using Kubernetes in the automation perspective in addition to hosting CNFs and VNFs (virtual network functions) both.

Typical large-scale telecom networks involve network functions from multiple vendors and different network management standards. But if we implement configuration from different vendors, and compare for one network function or cloud infrastructure, it is not the same. For example, there are standards like O-RAN (Open Radio Access Network) or 3GPP, but the configuration of deployment is differentiated.

To automate provisioning, Nephio pairs the Kubernetes’ declarative, actively-reconciled methodology along with machine-manipulable configuration. It’s declarative in the sense that configurations will be provided as an intent for infrastructure to self-reconcile until it reaches the intended state, as checked from the observed state.

At this point, most modern infrastructure admins are using Helm charts for such complex Kubernetes workload deployments and configuration, but using them is still complex. Helm charts are thousands of nested YAML template files. The drawback of using Helm charts is that it produces conditionally generated configuration outputs.

With Helm charts, intent-based continuous reconciliation is impossible to achieve as it generates configurations with conditions. With Nephio, this approach will be replaced by CRDs (custom resource definitions).

To tackle the configurations issues with large-scale Kubernetes environments, Nephio is going to be producing CRDs and operators for different network functions to manage the lifecycle and manage the configurations. Furthermore, infrastructure as a Code (IaaC) provided with Helm will be replaced by Configurations as a Data (CaD). These will be deployed in public as well as private cloud infrastructure to enable automation. The implementation of CRDs and operators will be done in conformance to the standards like 3GPP, ORAN, O2, etc.