This new capability of ETSI OSM is specifically important considering the ushering of 5G SA architecture and solutions which already find its way to the market thanks to early work from CNCF and specifically CNTT K8s specs. OSM brings value to the picture as it allows to design, model, deploy and manage CNFs (Containerized VNFs) without any translation or re-modeling. It also allows operators to experience early commercial use case of integration of Helm 2.0 in their production environments. On top of that, it allows a NS (Network Service) to combine CNFs with existing VNFs or legacy PNFs to deliver complex services in an easy to deploy and manageable manner.
In the following part of this paper I will try to share my understanding on OSM Release SEVEN and sum up the results from ETSI OSM webinars on this subject held on January 15-16 2020. For details you may need to refer to webinar content itself which can be found at https://www.brighttalk.com/webcast/12761/380670
Why Kubernetes is so important for Telco and Enterprise
Telco industry has experienced lot of pain points the way NFV journey has steered with focus on migrating existing PNFs to the Cloud. K8s offers opportunity for all Platform providers, application vendors, assurance partners to build something on modern principles of micro services, DevOps and Open API’s driven. This is something that already made its way to Telco’s in OSS and IT systems as an example Mycom-OSI UPM, OSM and ONAP are already based on Kubernetes, the arrival of 5G SA and uCPE branches has driven almost all operators adopt networks to use Kubernetes. Further it is principally agreed as CSP’s move to Edge that K8s will be the platform of choice.
Foundation for K8s Clusters
Kubernetes made it simple for the applications and CNFs to use APIs in a standard fashion using K8s Clusters which are deployed either from upstream open source or via Distros. The early adoption of CNFs in Telco largely supports the consumption model of vendor Distros like RedHat OpenShift, VMware PKS, Ericsson CCD to mention the most important ones.
The re-usability of APIs makes it simple to craft unique applications in form of build configuration files using artifacts of PoD, services, cluster, config map and persistent volumes which are defined in a very standard manner in K8s by which you can deploy all artifacts through a single file.
ETSI OSM can be deployed using both HELM 2.0 as well as Juju charmed bundles.
Foundation for Helm
Helm gives teams the tools they need to collaborate when creating, installing, and managing applications inside of Kubernetes. With Helm, you can:
- Find prepackaged software (charts) to install and use,
- Easily create and host your own packages,
- Install packages into any Kubernetes cluster
- Query the cluster to see what packages are installed and running
- Update, delete, rollback, or view the history of installed packages
Helm makes it easy to run applications inside Kubernetes. For details please refer to details HELM packages on https://helm.sh/blog/helm-3-released/
Key Features of OSM Release SEVEN
OSM Release SEVEN is carrier grade and below are its key features :
- Improved VNF Configuration interface (One stop shop) for all Day-0/1/2 operations
- Improved Grafana dashboard
- VNFD and NSD testing
- Python3 support
- CNFs support in both options where OSM creates the Cluster or rely on OEM tools to provision it
- Workload placement and optimization (something very important for Edge and Remote clouds)
- Enhancements in both Multi VIM and Multi SDN support
- Additional support for Public Clouds
How OSM handles deployment of CNFs
Fortunately, OSM approach on this is modeling applications in a standard fashion which means the same package can be enhanced to reflect containerized deployment. On a NS level, it can flexibly inter-work with VNFs/PNFs as well, the deployment unit used to model CNF specific parameters is called KDU’s (Kubernetes Deployment Unit) other major change is K8s cluster under resources. It is important as it explains most important piece the Networking and related CNI interfaces.
OSM can deploy the K8s cluster using API integration or rely on 3rd party tools like Openshift® or PKS to deploy it on instructions form OSM.
Changes to NFVO interfaces
Just like Or-Vi is used for infrastructure integration with Orchestration Helm 2.0 (will also support 3.0 in near future) is used for infrastructure integration with K8s applications. Since the NBI supports mapping KDUs in the same NSD it means the only changes from orchestration point of view are on the south side.
Workload Placement
As per latest industry standing and experience sharing in KubeCon and CloudNativeCon summit Americas there is a growing consensus that Container is the platform of choice for the Edge primarily due to its robustness, operational model and lighter foot print. As per our experience of containers here in STC a 40% reduction in both CAPEX and foot print will be realized on DC’s if deployed Edge using Containers.
However, the business definition of Edge raises a number of queries, the most importants being work load identification, placement and migration specially considering the fact that Edge has a lighter foot print that and that in the future will host carrier mission critical applications.
The issues with the upgrades and how OSM addresses them
Compared to earler releases, the OSM NS action primitives allow the CNF to be upgraded to the latest release and execute both dry run and Juju tests to ensure the application performance bench mark is same as before. Although this works best for small applications like LDAP the same is difficult to achieve with more complex CNFs like 5G SA. Through liaison with LFN OVP program I am sure soon the issue will be addressed. We as operators have a plan to validate it on 5G SA nodes.
Many thanks to colleagues, mentors and industry collaborators Jose Miguel Guzman, Francisco Javier Ramón Salguero Gerardo García and Andy Reid for OSM growth in recent years … See you in Madrid!