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. Theenterprise 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. Theideas 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.

TheCN-WAN Operatorruns 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