Latest ONAP Release Deepens Kubernetes Ties
The latest Frankfurt edition of the Open Network Automation Platform (ONAP) being developed under the auspices of the LF Networking consortium significantly tightens integration between the open source framework for automating the deployment of network services and Kubernetes.
Arpit Joshipura, general manager for networking, edge and internet of things (IoT) at the Linux Foundation, which hosts the LF Networking consortium, says ONAP is emerging as the de facto framework telecommunications providers will rely on to deliver next-generation wireless 5G services by enabling network slicing, among other capabilities.
As part of that effort, the LF Networking consortium has been working to automate the deployment of network services on frameworks such as Kubernetes and OpenStack. With the latest release of ONAP, the framework now supports deployments in Kubernetes-as-a-service (KaaS) environments spanning multiple clouds to ensure portability and increase scalability, says Joshipura.
In addition, ONAP now supports deployments of container network functions (CNFs) on multiple platforms alongside existing support for virtual network functions (VNFs) and physical network functions (PNFs). The latest edition also adds support for multiple virtual networks per Kubernetes cluster in a way that can span multiple instances of Kubernetes.
ONAP now also supports the Akraino edge computing platform, which is based ONAP, OpenStack and Kubernetes, as well as supports StarlingX, an edge computing framework defined by the OpenStack Foundation (OSF).
Finally, the Frankfurt release embraces additional best DevOps practices in the form of improvements in the continuous integration (CI) process such as the ability to run automated testing in response to new patch submissions. In addition, the ONAP integration team has defined five test categories, test application programming interfaces and test database.
Joshipura says the carriers that support ONAP have been working closely with both OSF and the Cloud Native Computing Foundation (CNCF), which oversees the development of Kubernetes, to advance network virtualization at scale. Most of the carriers are expected to employ all the elements of ONAP to manage network services at scale. However, he notes, ONAP is based on a modular architecture that enables any IT organization to employ elements as they best see fit.
Telecommunications carriers appear to be marshaling their resources to extend and harden network services spanning multiple Kubernetes clusters in much the same way they worked together to harden OpenStack. It’s too early to say how much downstream benefit those efforts might provide enterprise IT organizations; however, it is apparent networking services for Kubernetes are being advanced by contributors both within and outside the CNCF. Like the LF Networking consortium, the CNCF is an arm of the Linux Foundation.
There are now more than 400 developers from 34 organizations making contributions to ONAP. As the percentage of those efforts increasingly focuses on Kubernetes, many IT vendors and enterprise IT organizations may need to consider whether they want to reinvent the wheel. In fact, a forthcoming Guilin release of ONAP, planned for the second half of 2020, provides even deeper integration with Kubernetes.
In the meantime, networking within Kubernetes environments is becoming a more pressing issue as the number of Kubernetes clusters being deployed inside and out of traditional enterprise IT environments steadily increases.
