TNS
VOXPOP
How has the recent turmoil within the OpenAI offices changed your plans to use GPT in a business process or product in 2024?
Increased uncertainty means we are more likely to evaluate alternative AI chatbots and LLMs.
0%
No change in plans, though we will keep an eye on the situation.
0%
With Sam Altman back in charge, we are more likely to go all-in with GPT and LLMs.
0%
What recent turmoil?
0%
Cloud Native Ecosystem / Edge Computing / Kubernetes

Nephio Extends Kubernetes to Solve Cloud Native Automation

Nephio open-source project brings excitement to the 5G upgrade movement by telecom operators. Read this post to get an overview of what new innovations Nephio brings to the distributed telco infrastructure.
Aug 16th, 2022 9:05am by
Featued image for: Nephio Extends Kubernetes to Solve Cloud Native Automation

Sagar Nangare
Sagar Nangare is technology blogger, focusing on data center technologies (Networking, Telecom, Cloud, Storage) and emerging domains like Edge Computing, IoT, Machine Learning, AI). Based in Pune, he is currently serving Coredge.io as Director of Product Marketing.

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.

Group Created with Sketch.
THE NEW STACK UPDATE A newsletter digest of the week’s most important stories & analyses.