Building an End-to-End NFV & Applications Stack Powered by Kubernetes and ONAP
Written by Sagar Nangare, an Akraino community member and technology blogger who writes about data center technologies that are driving digital transformation. He is also an Assistant Manager of Marketing at Calsoft.
Introduction
In this article, we’ll look at how open source projects like Kubernetes, ONAP and many others can be stacked to build a Network Function Virtualization (NFV) framework that is identified as an Akraino Integrated Cloud Network (ICN) blueprint. We’ll outline the step-by-step inclusion of open source projects for various purposes (security, monitoring, orchestration, etc.). Readers will leave with an understanding of the role each open source project will play in the stack.
Glossary
Here are some key terms that I use throughout this article:
NFV: Network Function Virtualization
ONAP: Open Network Automation Framework
CNF: cloud-native network functions
VNF: Virtual Network Functions
Akraino ICN Blueprint: Akraino Integrated Cloud Network or Akraino Edge Stack is a Linux Foundations project for edge computing infrastructure. It is one of the internal projects or blueprints dedicated to the cloud native NFV stack.
CNI: container-native interface
What is NFV (Network Function Virtualization)?
NFV is a concept of transforming hardware-based network functions into software-based applications. It simply decouples network functions from proprietary hardware without impacting performance.
Why do we need NFV?
- Management and orchestration of thousands of network resources from central location
- Enable network programmability
- Allow dynamic scaling of network resources
- High level automation in the network
- Monitoring of resources and network connectivity
- Ability to integrate new services
- Optimization of network performance
The main reasons for enterprises and service to adopt NFV include: a vast scale of network resources containing different types of network equipment from different vendors, reducing the CAPEX and OPEX for network infrastructure, delivering services in an agile manner and enabling scalability and elasticity of network infrastructure to support rapid technology innovation.
Open Source for NFV
Kubernetes and ONAP are the key open source projects for this NFV stack. Using Kubernetes at the edge is something that leading networking solution companies are evaluating to provide dynamic capabilities managed from a central cloud. If you aren’t familiar with ONAP, it is a platform for real-time, policy-driven orchestration and automation of physical and virtual network functions.
We’ve already seen how Kubernetes is used in NFV as a backbone for cloud-native evolvement. This push for Kubernetes to dive into the NFV stack opens up possibilities for other open-source projects to make up the NFV backbone of enterprise and telecom networks. And further, Kubernetes will enable more automation and dynamic orchestration of application and infrastructure resources across the NFV-powered network.
Additionally, since various edges or hubs are involved in the typical 5G and enterprise network backed by NFV architecture, open-source projects like ONAP and Akraino blueprints are coming up with specific modules for critical orchestration and monitoring tasks.
Now that we’ve acknowledged the major role of Kubernetes and ONAP, let’s focus on the exact needs for a complete end-to-end NFV stack that will innovate a software-driven network. Let’s also look at how we can address those needs by combining different open source projects to power a 5G network and enterprise WAN.
Why Do We Need an End-to-End NFV Stack?
Currently, the IT infrastructure of enterprises and communication service providers is transitioning from centrally managed to geographically distributed. 5G presents the prominent use case for edge nodes or hubs as the initial level data center to communicate with IoT devices and host application services. And enterprises are deploying SD-WAN with edge-like capabilities.
In such architectures, workloads types like microservices, virtual network functions (VNFs) and cloud-native network functions (CNFs) are distributed. All those workload types are orchestrated by different solutions like Kubernetes and commercial solutions provided by VMware, Red Hat and Rancher.
In Figure 1, we can see that it’s difficult to manage all the workloads with different orchestrators, for several reasons. Security policy enforcement and monitoring of distributed nodes differs from centralized ones. You’ll need to manage all clouds and applications deployed on them and get insights about the performance of resources deployed on different edge sites. Additionally, this transition will cost the enterprises and telecom network providers.
Last year at ONS Europe (Open Networking Summit), Srinivasa Adeppalli (Intel) and Ravi Chunduru (Verizon) discussed using Kubernetes with ONAP4K8S, a sub-project in ONAP. This stack would manage all the applications and network functions spread across multiple Kubernetes clusters hosted on different edge nodes or data center infrastructures. They showed how a single pane of glass can orchestrate different edge sites, multiple clouds and network traffic.
Let’s See How it Works
In the presentation, Srinivas and Ravi showed an SD-WAN enterprise edge with microservices deployed in clusters and VNFs and CNFs present in an NFV stack. A request for data access generates the traffic that steers from pods to the internet through different VNFs, CNFs and external routers. Some of the microservices can be user-facing, with low latency needs. In this case, you need a multi-traffic orchestrator that controls the traffic flow and prioritizes the user-facing applications to deliver optimal performance.
Figure 3 shows the stack with the traffic orchestrator. In this scenario, Istio service mesh framework couples the microservices deployed at different edge sites. IPAM Manager ensures that each site is assigned a unique IP subnet and avoids overlapping addresses to Microservices/functions.
As we have seen, microservices, along with VNFs and CNFs, span multiple edge sites or clouds. So, we need a multi-zone manager (Figure 4).
Edge sites may face targeted attacks by external threats that can compromise network communication channels, microservices-based apps, software, and SSD/HDD. In Figure 5, we’ll use a new orchestrator called Multi-security orchestrator that uses CA Service, key distribution and attestation. You can integrate Istio, Vault project and Keycloak project with the Multi-security orchestrator to protect sensitive data as well as manage identity and access. In fact, you can run Istio from the central multi-cluster security orchestrator.
Further, a Multi-Cluster Security Orchestrator lets you monitor all the applications, VNFs and CNFs to check the health status and performance of multi-cluster app visibility and monitoring modules. Figure 6 shows how you can integrate Prometheus, Jaeger and Fluentd on each edge site for data monitoring and collect the data logs for analysis at a central location.
Now we have a complete NFV stack, called an Akraino ICN (Integrated Cloud Network) blueprint.
The major frameworks used in the end-to-end NFV stack include ONAP4K8s, OVN4K8sNFV, Kubernetes and Akraino SD-EWAN.
You can use ONAP4K8s as a Multi-Cloud/Cluster orchestrator to perform the following tasks:
- Single-click applications deployment
- Auto-configuration of service meshes
- Auto-configuration of SD-WAN to facilitate connectivity among micro-services in multiple clusters
- Parent CA and Child CA cert/private key enrollment for each edge/zone
You can use Kubernetes to orchestrate microservices-based applications and NFV-specific components like Multus, OVN4K8SNFV and SRIOVNIC as well as application components including Istio and Prometheus. OVN4K8sNFV works as a CNI (container-native interface) that supports multiple types of workloads, such as apps, CNFs, VNFs, etc.
Finally, Akraino SD-EWAN provides overlay connectivity among the Kubernetes clusters.
Conclusion
In this article, I’ve highlighted several open source projects that can be useful at various NFV tasks. Most of these projects are mature and widely integrated into different domains on a different scale. Each of the open source project addresses various features in NFV stack. You need to determine key capabilities from open source projects for each NFV features. You can get more information about implementation details and ongoing development from Akraino ICN and learn more about the NFV stack.
For more information about Akraino Blueprints, click here: https://wiki.akraino.org/. Or, join the conversation on the LF Edge Slack Channel. #akraino-blueprints #akraino-help #akraino-tsc
