In this lecture we will discuss about one solution
based on CNI, in particular, Weaveworks,
the Weaveworks Weave CNI plugin.
In the previous practice test,
we saw how it is configured.
Now we will see more details about how it works.
We will start where we left off
in the pod networking concepts section,
we had our own custom CNI script
that we’ve built and integrated into Kubelet through CNI.
In the previous lecture,
we saw how instead of our own custom script,
we integrated the Weave plugin.
Let is now see how the Weave solution works
as it is important to understand at least one solution well.
You should then be able to relate this
to other solutions as well.
So the networking solution we set up manually
had a routing table
which mapped what networks are on what hosts.
So when a packet is sent from one pod to the other,
it goes out to the network, to the router,
and finds its way to the node that hosts that pod.
Now that works for a small environment
and in a simple network,
but in larger environments with hundreds of nodes,
in a cluster and hundreds of pods on each node,
this is not practical.
The routing table may not support so many entries,
and that is where you need to get creative
and look for other solutions.
Think of the Kubernetes cluster as our company
and the nodes as different office sites.
With each site, we have different departments,
and within each department we have different offices.
Someone in office one wants to send a packet to office three
and hand it over to the office boy,
all he knows is it needs to go to office three,
and he doesn’t care who or how it is transported.
The office boy takes the package, gets in his car,
looks up the address for the target office in GPS,
uses directions on the streets
and finds his way to the destination site,
delivers the package to the payroll department,
who in turn forwards the package to office three.
This works just fine for now.
We soon expand to different regions and countries,
and this process no longer works.
It’s hard for the office boy to keep track of so many routes
to these large number of offices across different countries.
And of course, he can’t drive to these offices by himself.
That’s where we decide to outsource
all mailing and shipping activities to a company
who does it best.
Once the shipping company is engaged,
the first thing that they do is place their agents
in each of our company’s sites.
These agents are responsible
for managing all shipping activities between sites.
They also keep talking to each other and are well connected.
So they all know about each other’s sites,
the departments in them, and the offices in them.
And so when a package is sent from, say,
office 10 to office three, the shipping agent in that site
intercepts the package and looks at the target office name.
He knows exactly in which site and department
that office is in through his little internal network
with his peers on the other sites,
he then places this package into his own new package
with the destination address
set to the target site’s location,
and then sends the package through.
Once the package arrives at the destination,
it is again intercepted by the agent on that site,
he opens the packet, retrieves the original packet,
and delivers it to the right department.
Back to our world,
where the Weave CNI plugin is deployed on a cluster,
it deploys an agent or service on each node.
They communicate with each other to exchange information
regarding the nodes and networks and pods within them.
Each agent or peer stores a topology of the entire setup.
That way they know the pods and their IPs
on the other nodes.
Weave creates its own bridge on the nodes and names
at Weave, then assigns IP address to each network.
The IPs shown here are just examples.
In the upcoming practice test,
you will figure out the exact range of IP addresses
we’ve assigned on each node.
We will talk about IP address management
and how IP addresses are handed out to pods
and containers in the next lecture.
Remember that a single pod may be attached
to multiple bridge networks.
For example, you could have a pod
attached to the Weave Bridge
as well as the Docker Bridge created by Docker.
What path a packet takes to reach its destination
depends on the route configured on the container.
Weave makes sure that pods gets the correct route configured
to reach the agent,
and the agent then takes care of other pods.
Now, when a packet is sent from one pod
to another on another node,
Weave intercepts the packet and identifies
that it’s on a separate network,
it then encapsulates this packet
into a new one with new source and destination
and sends it across the network.
Once on the other side,
the other Weave agent retrieves the packet, decapsulates it,
and routes the packet to the right pod.
So how do we deploy Weave on a Kubernetes cluster?
Weave and Weave Peers can be deployed
as services or daemons on each node in the cluster manually,
or if Kubernetes is set up already,
then an easier way to do that is to deploy it as pods
in the cluster.
Once the base Kubernetes system is ready,
with nodes and networking configured correctly
between the nodes
and the basic control plane components are deployed,
Weave can be deployed in the cluster
with a single kubectl apply command.
This deploys all the necessary components
required for Weave in the cluster.
Most importantly, the Weave peers are deployed
as a daemon set.
A daemon set ensures that one pod of the given kind
is deployed on all nodes in the cluster.
This works perfectly for the Weave cluster.
If you deployed your cluster with a Kubeadm tool
and Weave plugin, you can see the Weave peers
as pods deployed on each node.
For troubleshooting purpose,
view the logs using the kubectl logs command.
Well, that’s it for this lecture,
I will see you in the next.