Kubernetes is the de-facto container management system for all sorts of distributed workloads. Known for its extensibility and community support, there are numerous plugins for multiple use cases.
The most unpredictable element for any distributed system is the network. A distributed system is as strong as its weakest link. As networks go down, it leads to various well-known problems like the thundering herd, split-brain, etc. Most applications are today built with the assumption that anything and everything can go down. Though this leads to robust applications, the major reason for having it in-built in the application is that we seldom have control over the network.
With services like AWS Outposts and AWS Transit Gateway, it is evident that AWS is keen on moving to private data centers. There was the introduction of AWS Fargate which means support for serverless containers in the same annual event. Though both the items seem contradictory to each other at first glance, AWS is trying to tie up the elements over which it has very little control. As enterprises adopt this approach, there will be a massive explosion of hybrid heterogeneous infrastructure deployments.
As the adoption of hybrid infrastructure deployment grows, infrastructure vendors like AWS, Azure will have to partner with networking companies. Networking companies will leverage their SD-WAN platforms for this transition and only companies with SD-WAN at their core will thrive compared to those providing ad-hoc SD-WAN features.
Some prominent and core features of SD-WAN platforms are:
-
VPN/VRFs over the internet and private networks alike
-
Ability to identify complex applications
-
Remote application breakout from a data center device
-
Link aggregation to leverage data-capable and quality capable links
-
Application steering based on link quality and capacity
-
Per packet load balancing to leverage the most of all the links
-
Security features like IPS/IDS, Content Filtering, etc
-
and many many more….
The most important point of all, is that for a SD-WAN network, every action is a function.
As the enterprises start discovering the advantages of moving to the cloud with applications running and scaling on serverless containers in their private and public data centers, they will be encouraged and eager to move their legacy applications to the new way of deploying applications.
It is at that point in time where we will see a rise in networking integrations with Kubernetes.
This post seeks to jot the advantages of having an SD-WAN based networking runtime for Kubernetes. Kubernetes comes with CNI (Container Network Interface) by default and there are many worthwhile plugins like Calico, Kubenet, etc which does a fantastic job.
Imagine the following scenario…
-
You have deployed a crucial configuration database service with critical SLAs which requires minimal latency and is not bandwidth-hungry
-
There is a monitoring service which has also been configured on the same node which is not latency-sensitive and is bandwidth-hungry
Perks of an SD-WAN Network
With an SD-WAN network, you can define specific QoS (Quality of Service) policies at runtime to always prioritize the database traffic in case of contention. There can be load balancing policies that are able to steer the database traffic to a low capacity high-quality MPLS link with lesser drops and jitter. The monitoring service traffic can be configured to exit via a broadband link as it can bear the uncertainties of the internet. No more manually configuring policies on the nodes. Just define the database app and make an API call to affect your application traffic over the entire network irrespective of the cloud environment.
You can configure network security groups for your applications across cloud service providers like AWS, Azure, and also for private deployments, with just a function call.
It is amazing how almost every SD-WAN feature can be used to leverage a seamless and robust experience with how applications are delivered to the end-user.
The network has always been treated as a second class citizen when compared to compute or storage. Similar to the introduction of memory-optimized or compute-optimized instances in AWS and other popular CSPs, there will be a need for the introduction of networking as a service for different application needs. Most applications today are data-intensive applications that need a reliable networking backbone to provide the optimal experience to the users.
As the industry moves towards the elimination of the distinction between running applications in the private or public data centers and treating containers as the atomic entity to deploy applications, it is inevitable that Kubernetes and SD-WAN will meet each other somewhere down the road and they will live on happily ever after!
Follow this space for more exciting stuff on Kubernetes!
