Network Plugins In K8 With Calico

As we know through out the same cluster pods have the same IP. Even though when the pods are in different name spaces pods can talk to each other using their IPs.

so that let us to think what if we wants to keep bit high on us .Not every one can to talk to ,particular one ,but the people who have fulfilled the condition.

We can write a network policy for particular pod in a particular namespace by labeling itself ,if some one trying to reach me ,I allowed only the pods from ‘X’ namespace.

But when we are trying to confirm our network policy by getting pin from a pod ‘Y’ namespace still they can call us.So that basically didn’t work yet.

yes ,yet.We need to put a network policy agent for our cluster. Waveworks ,Calico and ANTERA are the popular one.Well in this article gonna discuss about the Calico.

before that it’s better to refresh about how those pods find the each other with the help of root network name space in Kuberntes.

Assume a packet is going from pod1 to pod4.

1. It leaves pod1’s netns at eth0 and enters the root netns at vethxxx.
2. It’s passed on to cbr0, which makes the ARP request to find the destination.
3. It comes out of cbr0 to the main network interface eth0 since nobody on this node has the IP address for pod4.
4. It leaves the machine node1 onto the wire with src=pod1 and dst=pod4.
5. The route table has routes setup for each of the node CIDR blocks, and it routes the packet to the node whose CIDR block contains the pod4 IP.
6. So the packet arrives at node2 at the main network interface eth0.
   Now even though pod4 isn’t the IP of eth0, the packet is still forwarded to cbr0 since the nodes are configured with IP forwarding enabled.
   The node’s routing table is looked up for any routes matching the pod4 IP. It finds cbr0 as the destination for this node’s CIDR block.
   You may list the node route table using route -n command, which will show a route for cbr0 like this:

7. The bridge takes the packet, makes an ARP request and finds out that the IP belongs to vethyyy.

8. The packet crosses the pipe-pair and reaches pod4

This is how containers on a node talk to each other. Obviously there are other ways, but this is probably the easiest, and what docker uses as well.

But to point out here our goal is to learn about Callco :)

before start just think networking in real world remain the same compared to the Kubernetes environment.

in calico architecture :

there is no bridging which make the things complicated , it is using layer3 based routing approach.

calico BGP for routs distribution.this is policy driven by IP table rules.

let’s go through the inner architecture in high level: ,first :)

Filix is a network deamon set ,whuich communicate back with the calico and the BGP clients.

then have a look in orchestration plugin. ok first kuberntes is popular ,yp but what about the other orchestration platforms.Hmm..like ,open stack.

while talking to each other need a common configuration.this is where etcd data base and the orchestration plugin comes to picture.

BGP client help when communicating pods to each other by creating BGP mesh.But currently people using BGP route reflector to have a proper journey for packets.

by the ways at any point we can see these by our selves by just using hell chart.based on your helm version use the proper command after downloading the helm chart for calico.

remember after installation we can see new three pods, which i talk later.But in setting we need to keep the mesh and BGP on.

How Calicao works really ?

As we know upto now after calico getting installed ,3 new pods occur in node. in name they are c-controler, C-ETCD and calico node.

from the cali interface KubeDNS gets IP which shows in left node ,which works with kernel.Lets’s onboard a another node.What will be happen to our network agent??

those running calico node identifies it.calico node (means pod really :) )push a proxy and keep BGP peer as shown below.

as I mentioned before these architecture are using IP table rules.Due to that change we just made all the tables getting updated according to the network interface.

let’s say instead of node ,new pod comes in to picture.let’s schedule a busybox pod(BusyBox is a software suite that provides several Unix utilities in a single executable file. )

when we tell kubelet about our new requirement,it talk to c-ETCD(one of new pod from calico install).then ETCD calls to kubernetes scheduler ,then go to routing tables and make a entry.Then we are done with the things basically.After that request raised for kubelet .Again it calls to ETCD ,ETCD calls to calico node(pod).After that Busybox comes through calico interface.baby pod there with it’s new IP :).