The Kubernetes networking model is based on a flat address space and doesn’t required to configure NAT. But every pod in the cluster can talk directly to each other and have its own unique IP address. In addition, containers in the same pod share their pod’s IP address and can communicate with each other through localhost.
Pod’s IP address and network namespace are created and held by the pause container. Before the pause container is started, a virtual Ethernet interface pair (a veth pair) is created for the container. One interface of the pair remains in the host’s namespace and other is moved into the container’s network namespace as eth0.
The other end of interface in the host’s network namespace is attached to a network bridge that the container run-time is configured to use. The eth0 interface in the container is assigned an IP address from the bridge’s address range. Whatever that an application running inside the container sends to the eth0 network interface comes out at the other veth interface in the host’s namespace and is sent to the bridge. This means it can be received by any network interface that’s connected to the bridge.
So, Now I hope it is clear how the communication is happen between the pods in same node. But to enable communication between pods on different node there should be a way of bridges to get connected. To do this we use a Software Defined Network (SDN), which makes the nodes appear as though they’re associated to the same network switch, irrespective of the actual underlying network topology, no matter how complex it is. Packets sent from the pod are encapsulated and sent over the network to the node running the other pod, where they are de-encapsulated and delivered to the pod in their original form.
To connect containers into a network easier, a project called Container Network Interface (CNI) was started. The CNI lets Kubernetes to be configured to use any CNI plugin that’s out there.
These are few plugins include,
- Calico
- Flannel
- Weave Net
In Kubernetes we can have multiple pods provide the same service and with the requirement we can scale them up and down. As you scale up there will be new pods get created with new IPs are added to the Pod network and get removed when scale down the pods. This makes lots of issues. So, Kubernetes services is a resource that allow grouping pods under a common access policy (load-balanced). The service gets assigned a virtual unique IP and port which pods outside the service can communicate with. Those requests are then transparently proxies (via the kube-proxy component that runs on each node) to the pods inside the service.
So, Now we have a clear idea on how the Kubernetes talk to each other (POD to POD, POD to Service and Container to Container)
Author: Iflan Mohamed is a Kubernetes Certified, Docker Certified & RedHat Certified DevOps Engineer at CMS.
