Co-authors: Alberto Rodriguez-Natal, Vijoy Pandey, Lori Jakab, Fabio Maino
This week at KubeCon Europe 2020, we introduced the Cloud-Native SD-WAN (CN-WAN) project to improve SD-WAN and Kubernetes integration. CN-WAN is a reference open-source implementation that illustrates how SD-WAN solutions, such as Cisco Viptela SD-WAN, can seamlessly integrate with the Kubernetes ecosystem to become aware of the needs of Cloud-Native applications. CN-WAN maps Kubernetes application attributes to SD-WAN network capabilities to automatically optimize the application performance over the WAN.
Some background: Enterprises are moving modern applications to cloud-native architectures, including microservices architectures. Many use Kubernetes to orchestrate microservices in containers, and they are adopting DevOps practices for management and deployment. Furthermore, modern applications are often distributed across clouds, edge locations, data centers, etc., and the users and data may also be in many different locations. Therefore, maximizing application performance often requires optimizing the connectivity across all of the above. Historically this has been cumbersome, manual, and challenging.
In many cases, enterprises deploy an SD-WAN to connect a Kubernetes cluster with users or workloads that consume cloud-native applications. In a typical enterprise, NetOps teams leverage their network expertise to program SD-WAN policies to optimize general connectivity to the Kubernetes hosted applications, with the goal to reduce latency, reduce packet loss, etc. The enterprise usually also has DevOps teams that maintains and optimize the Kubernetes infrastructure. However, despite the efforts of NetOps and DevOps teams, today Kubernetes and SD-WAN operate mostly like ships in the night, often unaware of each other. Integration between SD-WAN and Kubernetes typically involves time-consuming manual coordination between the two teams.
Fortunately, modern SD-WAN solutions often have APIs that allow them to programmatically influence how their traffic is handled over the WAN. This enables interesting and valuable opportunities for automation and application optimization. We believe there is an opportunity to pair the declarative nature of Kubernetes with the programmable nature of modern SD-WAN solutions. This allows us to not only to improve connectivity towards the Kubernetes cluster, but also to simplify and automate the consumption of SD-WAN capabilities by Cloud-Native applications.
In our previous post, Simplifying the DevOps and NetOps Journey using Cisco SD-WAN Cloud Hub with Google Cloud, we described how Cisco SD-WAN Cloud Hub simplifies the workflow for DevOps and NetOps, by automating the tasks needed to deliver a better application experience over the SD-WAN. The ideas highlighted in that post can apply to any workload, including cloud-native workloads. To that end, we open-sourced CN-WAN, a set of components that can be used to better integrate an SD-WAN solution, such as Cisco Viptela SD-WAN, with Kubernetes to (1) enable DevOps teams to express the WAN needs of the microservices they deploy in a Kubernetes cluster, and (2) allow NetOps to automatically render the microservices needs into dynamic WAN optimizations.
Seamless integration of Kubernetes and SD-WAN via CN-WAN
Consider the example of a video conferencing cloud-native application, composed of multiple microservices (voice, video, slides, chat, etc.). These microservices might have different requirements for how their traffic should be treated over the WAN. For instance, a video microservice requires more bandwidth than a chat microservice, and a voice microservice is more sensitive to latency than a slide sharing one.
CN-WAN is composed of a set of components (a Kubernetes Operator, a Reader, and an Adaptor) that can automate the process of optimizing the SD-WAN for each externally exposed microservice and help NetOps and DevOps teams to achieve their common goal of providing a better application experience.
The CN-WAN Operator runs in the Kubernetes cluster, actively monitoring the deployed services. DevOps teams can use standard Kubernetes annotations on the services to define WAN-specific metadata, such as the Traffic Profile of the application. The CN-WAN Operator then automatically registers the service along with the metadata in a Service Registry. In the demo that we show at KubeCon EU we use Google Service Directory as Service Registry.
The CN-WAN Reader, on the SD-WAN side, connects to the Service Registry to learn about how Kubernetes is exposing the services and the associated WAN metadata extracted by the CN-WAN operator. The CN-WAN Reader periodically polls the Service Registry and keeps track of updates regarding the services exposed and/or the metadata associated. When new (or updated) services or metadata are detected, the CN-WAN Reader sends a message towards the CN-WAN Adaptor so SD-WAN policies can be updated.
The CN-WAN Adaptor, also on the SD-WAN side, maps the service-associated metadata into the detailed SD-WAN policies programmed by the NetOps in the SD-WAN controller. In this way the SD-WAN controller automatically renders the SD-WAN policies, specified by the NetOps for each metadata type, into specific SD-WAN data plane optimizations for the service. The SD-WAN may support multiple types of access at both sender and receiver (e.g., wired Internet, MPLS, wireless 4G or 5G), as well as multiple service options and prioritizations per access network, and of course multiple paths between source and destination. By providing the SD-WAN controller with the application attributes described above it can automatically and dynamically optimize across all of the WAN options to maximize the application performance. For instance, in the simple example in the figure, traffic generated by a service that has the “Real Time” annotation is assigned to a low-latency, minimal drops path over the SD-WAN.
Making SD-WAN aware of Cloud-Native application needs with CN-WAN
Another example can be found in the CN-WAN demo released for KubeCon EU (details at the end of this post). That setup replicates a user in a branch streaming from a Kubernetes video service in the cloud, with Cisco Viptela SD-WAN connecting branch and cloud. For the demo, we established two tunnels on the SD-WAN, that respectively mimic the behavior of a public internet link (average latency and bandwidth) and a business internet link (better latency and bandwidth). All traffic between the user and the cluster goes by default through the public internet tunnel. However, we configured the CN-WAN Adaptor to automatically steer traffic for services annotated with “traffic-profile=video” through the business internet tunnel. The demo demonstrates how by just adding the annotation “traffic-profile=video” to the Kubernetes service the traffic is automatically shifted to the business internet tunnel.
Thanks to the Cloud-Native SD-WAN project, SD-WAN solutions such as Cisco Viptela SD-WAN can seamlessly integrate with the Kubernetes ecosystem to automatically optimize application performance based on Kubernetes’ application attributes. We believe that CN-WAN + Cisco Viptela SD-WAN provides a Cloud-Native SD-WAN that can provide significant application performance benefits for your Kubernetes-based applications.
See the KubeCon EU CN-WAN Demo
Please visit Cisco’s KubeCon EU site to hear Vijoy Pandey, VP & CTO of Cloud at Cisco, discuss CN-WAN at his keynote, and to watch a demo of CN-WAN in action.
The code for the CN-WAN project is available as open-source in GitHub. The CN-WAN team can be reached at cnwan@cisco.com. Feel free to reach out to chat with us about the project and learn more about how we are planning to integrate CN-WAN capabilities into the Cisco SD-WAN Cloud Hub solution.
Thanks John for sharing this great work and initiative. Love the progress and possibilities for our customers.
Thanks Prakash — we appreciate the feedback!
Great info! Is there work being done to do the same thing with OpenShift?
Great question! Since OpenShift has a nice packaging of Kubernetes we expect CN-WAN to work with OpenShift. However we have not tried it yet. Along these lines, perhaps we should add CN-WAN to OpenShift’s OperatorHub to streamline deployments. Thanks for raising this topic!