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 boost SD-WAN and Kubernetes integration. CN-WAN is really a reference open-source implementation that illustrates how SD-WAN solutions, such as for example Cisco Viptela SD-WAN, can seamlessly integrate with the Kubernetes ecosystem to notice the requirements of Cloud-Native applications. CN-WAN maps Kubernetes application attributes to SD-WAN network capabilities to optimize the application form performance on the WAN automatically.

Some background: Enterprises are moving modern applications to cloud-native architectures, including microservices architectures. Many use Kubernetes to orchestrate microservices in containers, and they’re adopting DevOps practices for deployment and management. Furthermore, modern applications are distributed across clouds often, edge locations, data centers, etc., and the users and data could be in lots of different locations also. Therefore, maximizing application performance requires optimizing the connectivity across all the above often. It has been cumbersome historically, manual, and challenging.

In many cases, enterprises deploy an SD-WAN for connecting a Kubernetes cluster with workloads or users that consume cloud-native applications. In an average enterprise, NetOps teams leverage their network expertise to program SD-WAN policies to optimize general connectivity to the Kubernetes hosted applications, with the target to latency reduce, reduce packet loss, etc. The enterprise usually has DevOps teams that maintains and optimize the Kubernetes infrastructure also. However, regardless of the efforts of DevOps and NetOps teams, in the night time today Kubernetes and SD-WAN operate mostly like ships, unaware of one another often. Integration between SD-WAN and Kubernetes involves time-consuming manual coordination between your two teams typically.

Fortunately, modern SD-WAN solutions frequently have APIs that permit them to influence how their traffic is handled on the WAN programmatically. This permits interesting and valuable opportunities for application and automation optimization. We believe there’s a chance to pair the declarative nature of Kubernetes with the programmable nature of modern SD-WAN solutions. This enables us to not and then improve connectivity towards the Kubernetes cluster, but additionally to simplify and automate the intake of SD-WAN capabilities by Cloud-Native applications.

Inside 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 NetOps and DevOps, by automating the tasks had a need to deliver an improved application experience on the SD-WAN. The essential ideas highlighted for the reason that post can connect with any workload, including cloud-native workloads. To that final end, we open-sourced CN-WAN, a couple of components you can use to integrate an SD-WAN solution better, such as for example Cisco Viptela SD-WAN, with Kubernetes to (1) enable DevOps teams expressing 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 SD-WAN and Kubernetes via CN-WAN

Consider the exemplory case of a video conferencing cloud-native application, made up of multiple microservices (voice, video, slides, chat, etc.). These microservices could have different requirements for how their traffic ought to be treated on the WAN. For example, a video microservice requires more bandwidth when compared to a chat microservice, and a voice microservice is more sensitive to when compared to a slide sharing one latency.

CN-WAN comprises a couple of components (a Kubernetes Operator, a Reader, and an Adaptor) that may automate the procedure of optimizing the SD-WAN for every externally exposed microservice and help NetOps and DevOps teams to attain their common goal of providing an improved application experience.

The CN-WAN Operator runs in the Kubernetes cluster, monitoring the deployed services actively. DevOps teams may use standard Kubernetes annotations on the ongoing services to define WAN-specific metadata, like the Traffic Profile of the application form. The CN-WAN Operator then automatically registers the ongoing service combined with the metadata in something Registry. In the demo that people 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 understand about how exactly 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 monitors updates concerning the services exposed and/or the metadata associated. When new (or updated) services or metadata are detected, a note is sent by the CN-WAN Reader towards the CN-WAN Adaptor so SD-WAN policies could be updated.

The CN-WAN Adaptor, on the SD-WAN side also, maps the service-associated metadata in to the detailed SD-WAN policies programmed by the NetOps in the SD-WAN controller. In this manner the SD-WAN controller renders the SD-WAN policies, specified by the NetOps for every metadata type, into specific SD-WAN data plane optimizations for the ongoing service. The SD-WAN may support multiple forms of access at both sender and receiver (e.g., wired Internet, MPLS, wireless 5G) or 4G, in addition to multiple service prioritizations and options per access network, and undoubtedly multiple paths between destination and source. By giving the SD-WAN controller with the application form attributes described above it could automatically and dynamically optimize across every one of the WAN options to increase the application performance. For example, in the easy example in the figure, traffic generated by way of a ongoing service which has the “REAL-TIME” annotation is assigned to a low-latency, minimal drops path on the SD-WAN.

Making SD-WAN alert to Cloud-Native application needs with CN-WAN

Another example are available in the CN-WAN demo released for KubeCon EU (details by the end of the post). That setup replicates a user in a branch streaming from the Kubernetes video service in the cloud, with Cisco Viptela SD-WAN connecting cloud and branch. 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 your user and the cluster goes on 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 simply adding the annotation “traffic-profile=video” to the Kubernetes service the traffic is automatically shifted to the business internet tunnel.

Because of the Cloud-Native SD-WAN project, SD-WAN solutions such as for example Cisco Viptela SD-WAN can seamlessly integrate with the Kubernetes ecosystem to automatically optimize application performance predicated on Kubernetes’ application attributes. We think that CN-WAN + Cisco Viptela SD-WAN offers a Cloud-Native SD-WAN that may provide significant application performance benefits for the Kubernetes-based applications.

See the KubeCon EU CN-WAN Demo

Please visit Cisco’s KubeCon EU site to listen to Vijoy Pandey, VP & CTO of Cloud at Cisco, discuss CN-WAN at his keynote, also to watch a demo of CN-WAN doing his thing.

The code for the CN-WAN project can be acquired as open-source in GitHub. The CN-WAN team could be reached at cnwan@cisco.com. Feel absolve to reach out to speak to us concerning the project and find out about how we are preparing to integrate CN-WAN capabilities in to the Cisco SD-WAN Cloud Hub solution.

The post Cloud-Native SD-WAN: The WAN Your Kubernetes Applications Deserve appeared first on Cisco Blogs.