Kubernetes Networking Models

Kubernetes is an open-source tool for containerized applications. This tool will help the application is automatically scale, deploy, and manage. Kubernetes makes the group of containers make applications into logical units. This makes deployment, maintenance, and other reliability concerns easier. Basically, Kubernetes has 4 major components which are, Controllers, API server, Pods, and Nodes. Where the API server is the gateway to cluster state management tool called etcd and cluster. Controllers (Kubelet) are responsible for making the current state to state matches each other. Pods are the deployable workload that encapsulates one or more Docker Containers with network configurations. Nodes are the instance that runs the Kubernetes cluster which has one or more pads running inside. Since Kubernetes is having a different component that needs to talk to each other and with external internet, Understanding of Kubernetes Networking Model is very important.

Kubernetes Networking Models

We have discussed more on Kubernetes architecture and components. To Refresh about Kubernetes basics and concepts. Please read the article.

Read Article: Architecture of Kubernetes

Basically, we need to consider three different Kubernetes networking that we need to discuss. Those are

1. Container to Container Networking
2. Pod to Pod Networking
3. External Internet to Cluster Networking.

In this article, we will discuss and Kubernetes Networking Model and how this will give solution to all these four-networking situation.

Container to Container Networking.

Container to Container networking is happening through the Network Namespace. Network namespace means the logical networking stack which is having its own logical router, firewall, and other network devices. So, Container within the Pods will communicate with each other with the Pod Network namespace and each Pods will communicate with each other with Root Network Namespace. In which, Root Network Namespace is created within the Node or instance. For example, eth0.

Basically, Containers inside a pod will share the same IP address and port assigned via the Pod Network namespace which is assigned to the Pod. Similarly, every Pod will have its own Pod Network namespace.

Pod to Pod Networking

Unlike Container Networking, Pod to Pod Networking is having a real IP address. From the Root Network Namespace, root interface (eth0) will create a virtual interface (veth0, veth1,.) for every Pods and which is assigned to each Pod network namespace. Then, every Virtual interface will connect through the virtual bridge which will send and receive data using ARP protocol.

[Image] -ok

So, As shown in figure, If, Pod-1 wants to send data to Pod-2,

1. First, it will connect using Pod-1’s interface (eth0) to root network namespace’s virtual interface-0 (veth0)
2. Then, Root Network Namespace’s virtual interface-0 (veth0) will connect to the virtual bridge (vbr0).
3. Next, data will send from vbr0 to virtual interface-1 (veth1).
4. Finally, data will be sent from veth1 to eth0 of pod-2’s Network Namespace.

Similarly, if the communication is happening from different Node which is in intranet/internet means, the virtual bridge will send the data to the intranet/internet through the ethernet (eth0) of root network namespace. Then the other node will receive the data from the intranet/internet to the interface (eth0) and send it to the virtual bridge (vbr0) then to the destinated Pod.

Just like different node network communication, Service to Node or Pod will communicate. This will be done by using either DNS or local IP address depends on the placement of the Node in the network.

Internet to Cluster Networking.

Now the challenging and interesting part in the Kubernetes Networking model is the Networking model of External Internet to cluster. External Internet network traffic can be divided into two part s

1. Egress
2. Ingress

Egress is the network traffic from Kubernetes clusters to the Internet and Ingress is the network traffic from the Internet to Kubernetes clusters.

Egress – Network Traffic from Kubernetes to Internet

Implementation of Egress network traffic is made simple with iptables NAT. Basically, the internet will connect to the VM using Internet Gateway and this internet Gateway will understand only VM’s network namespace. So iptables with Source NAT configuration will connect with the virtual bridge which will help pods to send data through the NAT configuration using iptables. So, Internet will understand that data is coming from the VM but internally, iptables will do the network routing from Pods to the virtual bridge via virtual ethernet and source NAT between Root Network namespace’s interface to the virtual bridge.

In the Figure,

1. Pod-2 is sending the package to Root Network Namespace’s veth1 via eth0 of Pod-2’s network namespace.
2. Then, veth1 will route the package to vbr0 if the root network namespace.
3. Next, the iptables will do the NAT-ing from virtual bridge (vbr0) to internet gateway via eth0 if root network namespace.
4. Finally, the Internet Gateway will change the source IP address from internal IP to External IP so that the outer world will receive what the Kubernetes cluster sends.

Ingress – Network Traffic from internet to Kubernetes.

Ingress is the network implementation that is getting network traffic from the internet to Kubernetes clusters. Internet traffic routing to Kubernetes has two different implementation:

1. Load Balancer
2. Ingress Controller.

Load balancer: Ideally, Cloud providers or separate implementation with proxy servers like Nginx or squid will provide a load balancer and advertise the IP address. Through this IP address. External words will communicate to Kubernetes. Inside Kubernetes, configured iptables will take care of routing to the right pod inside the Kubernetes.

Ingress Controller: Ingress Controller works with Nodeport service type with Kubernetes. When we use Nodeport type service in out Kubernetes, Kubernetes master will assign a range of network ports and the iptables rules will route the respective traffic to the right Pods. Ingress object is used to expose the Nodeport to the internet.

In the above figure, data flow from the internet to Kubernetes clusters is happening using an ingress load balancer. Let’s see this in the step by step explanation.

1. When traffic is coming from the internet to ingress load balancer, it will create an ingress object to identify the iptables.
2. Then, iptables rules will know which Nodeport is assigned to which pod.
3. Through the Nodeport, traffic will move to the right pod.

This way ingress controller will help network traffic routing from internet to Kubernetes cluster.

Conclusion

In this article, we have discussed how networking is happening between container to container, Pod to Pod and Internet to Kubernetes clusters. This is the basic Kubernetes Networking model to implement network configuration within and out of the Kubernetes cluster. In our upcoming articles, we will discuss how to implement all the mentioned network configuration. Stay tuned and subscribe DigitalVarys for more articles and study materials on DevOps, Agile, DevSecOps and App Development.