Kubernetes - Weave Network Overlay

Hello there and welcome to my next microblog(doc) of K8S We'll be discussing about Weave Network Overlays today and why we will need something like this in the first place. If you want to check out how you can set up a K8S cluster before you read this section, check out my blog post here.

This blog post will cover why we need an overlay network in a Kubernetes cluster, what WeaveNet is and some basics fundamentals about WeaveNet that can help you get started.

Why do we need an overlay network?

Imagine that you developed a shiny new shopping application that is ready to be deployed onto your Kubernetes cluster. You want this application to be available to a large set of customers, so you decide that you want to deploy 3 containers in total, one on each node of your Kubernetes cluster. The diagram below should help you visualize what that might look like.

Now, notice that your cluster nodes are all connected to each other in a mesh network. And each of those nodes have a container (in the Kubernetes world, you call it a pod; a collection of containers) that is running your application.

You want your customers to be able to access your application. In order to access your application, one would need an IP address. For the sake of simplification, lets say that you have this single IP address that represents this entire cluster, and all requests to it will be forwarded to the appropriate container in the cluster. Note that each of these containers will have their own IP address as well. How do you decide which container should receive the request and when? Furthermore, let us imagine that your cluster got bigger because Thanksgiving is around the corner, so you go ahead and add 10 more nodes to your cluster, each hosting a container of your application. How would you handle that scale up operation and route traffic equally between all the containers?

You can already see that things are starting to get a little more complicated to be handled manually. This was just a simple example of 1 container for your application. A production grade application would have multiple micro-services that may even need to talk to each other over a same LAN network. How would one set up that communication? Well, this is where solutions like WeaveNet come in, because the task of providing container networking (just a fancy term for regular networking between containers - don't let anyone else tell you different) is handled by WeaveNet, which makes things seem like all your containers - no matter which node - are connected to a switch and belong to the same LAN. If you want to know more about this kind of technology, look up VxLANs on the Internet.

What is WeaveNet?

WeaveNet is a peer-to-peer network that is created by running a WeaveNet router on each node in the cluster. The most important goal that WeaveNet achieves is to be able to allow containers to be able to talk to one another even though they are distributed among multiple nodes. WeaveNet is able to achieve this be connecting each container to a virtual Linux Bridge (OVS bridge) and assign it an IP address from a pool managed by WeaveNet routers. Weave Net routers learn which peer host a particular MAC address resides on. They combine this knowledge with topology information in order to make routing decisions and thus avoid forwarding every packet to every peer.

Note: Weave Net can route packets in partially connected networks with changing topology. For example, in this network, peer 1 is connected directly to 2 and 3, but if 1 needs to send a packet to 4 or 5 it must first send it to peer 3.

How does WeaveNet interpret the network topology?

Think of a scenario where you connect three switches together. In order to avoid a network loop, a protocol called STP would broadcast BPDUs over the network which would help each switch in the network identify the others. In the same way, WeaveNet routers are all meshed to each other using TCP. All topology changes and information are broadcast to the peers over the TCP links. WeaveNet also used another method called Gossip in order to provided incremental topology updates to the peers of the network. Gossip messages are sent periodically to a subset of the peers in the topology in order to account for rapid network changes (like a peer going offline or a container in a peer going offline and re-spawning in another peer) that can outdate the routing tables.

Note: There is a lot more information about how exactly this works and there is no better place to learn than Weave's own Website: https://www.weave.works/docs/net/latest/concepts/network-topology/

Install WeaveNet

In order to install Weave Net onto your Kubernetes cluster, use the following command for Kubernetes versions 1.6 and above.
kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"

For Kubernetes versions up to 1.5, use the following command.
kubectl apply -f https://git.io/weave-kube

Note: More information about how to install WeaveNet can be found here.

And that's it! I hope this information has helped you learn something new in your Kubernetes Learning Journey! ☺️