The Linux Networking Fund (LNF) is making significant progress toward embracing Kubernetes as a platform for delivering a range of networking services that are expected to be widely embraced by telecommunications carriers and cloud service providers (CSP).
Arpit Joshipura, general manager of networking an orchestration for The Linux Foundation, says the latest Beijing release of the Open Networking Automation Platform
(ONAP) contains several modules that have been ported to Kubernetes, with more to follow once the Casablanca release of ONAP is released.
For example, the ONAP Operations Manager (OOM), which enables ONAP services to be managed and deployed as containers, makes use of both Kubernetes and Helm, a package manager for Kubernetes.
ONAP is an ambitious open source effort to define an open source management and network orchestration (MANO) framework for delivering software-defined networking (SDN) services. ONAP was formed as a merger of OpenECOMP, the open source version of AT&T’s ECOMP project, and the OPEN-Orchestrator project, a project created under the auspices of The Linux Foundation that was led primarily by China Mobile, Huawei and ZTE. The ONAP framework consists of 31 sub-projects for which various vendors and carriers are contributing code to make network services at scale programmable and responsive to rapidly changing requirements.
Kubernetes, meanwhile, is overseen by the Cloud Native Computing Foundation (CNCF), a sister arm of The Linux Foundation that also oversees LNF.
Most carriers today make extensive use of the OpenStack cloud management framework, which most often is deployed on top of an open source instance of a Xen-based virtual machine. Support for Kubernetes will give carriers and CSPs the option to deploy modules based on containers on top of their existing OpenStack investments or deploy them on other cloud services platform, says Joshipura.
As part of making ONAP more accessible, LNF also has now added support for application programming interfaces (APIs) developed by TF Forum, the MEF (Metro Ethernet Forum) and ETSI (the European Telecommunications Standards Institute).
Thus far, Joshipura says, more than 100 service providers have pledged to implement ONAP modules, mainly as part of a long-term transition to relying on SDNs to deliver next-generation 5G networking services. In fact, with the Beijing release, various modules defined by LNF are now mature enough to start deploying in production environments, he notes.
Less is clear going forward is the degree to which network services will be delivered as a microservice based on containers instead of relying on virtual network function (VNF) software, which today is largely optimized for one specific type of hypervisor.
The progress LNF is making on ONAP is critical from a DevOps perspective, because once a MANO is in place, it will become feasible for both carriers and CSPs to expose programmable network services via well-defined open APIs. Today, developers can programmatically spin up virtual machine and containers in minutes. But it still takes weeks to provision networking services across multiple on-premises servers and external cloud services. Each CSP, for example, has its own SDN. But connecting all those SDNs in way that can be programmatically invoked represents the next big frontier in telecommunications. Once those networking services are in place, it should become more much more feasible to build and deploy a wide range of applications spanning everything from the network edge to the cloud and back again.