Kubernetes Networking: A Complete Guide to Understand Network Model

Container management is a vital aspect of networking. With today’s changing traffic requirements, the importance of Kubernetes has increased tenfold. And if you’re interested in learning about networking, you’ll have to get familiar with Kubernetes first. Learning about Kubernetes will help you with handling container management effectively. Kubernetes is also one of the top DevOps tools in the market for 2020.

But don’t worry because, in this detailed guide, we’ll be discussing the same. Kubernetes is a container management tool, and in this article, you’ll learn why it’s used, what are its network’s components, and how they route traffic. 

Check out our free courses to get an edge over the competition.

Learn Software engineering online from the World’s top Universities. Earn Executive PG Programs, Advanced Certificate Programs, or Masters Programs to fast-track your career.

Let’s dive in. 

What is Kubernetes?

Before we start discussing networking in Kubernetes, we must consider the basic concepts of this tool. This way, you wouldn’t face confusion later on in the article and have a basic understanding of everything mentioned here. 

Kubernetes is an open-source container orchestration tool. It helps you with managing containers, which have become the most critical aspect of networking these days. Kubernetes has many functions, including scaling of containers, deployment of containers, descaling of containers, etc.

While Docker helps professionals with the creation of containers, Kubernetes helps them in managing the same. That’s why both of them are so important. Kubernetes runs a distributed system over a cluster. Understanding its structure and its networking will let you avoid mistakes and manage containers without errors. 

Check out upGrad’s Full Stack Development Bootcamp

Why is Kubernetes used?

The container requirements of companies have increased vastly in the past few years. Unless they are too small, they can’t rely on one or two containers. They would need to have a large set of containers for load balancing. The requirement could be in hundreds to maintain a high availability and to balance the traffic. 

When the traffic would increase, they would need more containers for handling requests. Similarly, when the traffic would be less, they will need scaling down of the containers. Managing the containers according to the demand can be challenging, especially if you do it manually.

Check out upGrad’s Java Bootcamp.  

Manually orchestrating the containers can take a lot of time and resources, which would have easily been spent elsewhere. Automating this task makes things a lot simpler. Then you wouldn’t have to worry about scaling and descaling the containers. That’s what Kubernetes does. Read how to create DevOps projects for beginners with the help of Kubernetes in our top DevOps projects for beginners article.

It automates the orchestration and management of containers. It’s widely popular because of its functionality. It’s a Google product, and its performance helps organizations considerably in automating the scaling of containers. 

Components of Kubernetes

Now that you know what Kubernetes is and what its functions are, we can start discussing its multiple components. You can understand networking in this tool only after getting familiar with its different parts. There isn’t much to worry about, however. That’s because we’re here to help. Following is a brief description of its various components. Although the description is concise, it should be enough to give you a general idea. 

Pods

Remember atoms in chemistry, the smallest independent objects of matter? Well, Pods are the atoms of Kubernetes. One Pod is a workload in a cluster. It can contain one or multiple containers with storage. Every Pod has a unique IP address that acts as its identity when it interacts with other components of Kubernetes. All the containers of a pod are scheduled and located within the same machine. 

Controllers

Controllers build the Kubernetes. Controllers watch the state of the API server to make sure that its current state matches the state you’ve specified. If the state of the API server changes for some reason, it reacts accordingly. Controllers use a loop for checking the states of clusters and for comparing them with the required states. It can also perform tasks to change the current state into the necessary state.

Nodes

If Pods are the atoms, Nodes are the gears of Kubernetes. They run the cluster. Virtual machines are accessible nodes in Kubernetes clusters. Many people tend to use the word ‘host’ instead of ‘node.’ We’ve tried to use the term nodes consistently in this article. 

API Server

The API server is the gateway to the datastore in Kubernetes. It lets you specify your desired state for clusters. You’ll have to make API calls if you want to change the state of your Kubernetes cluster and describe your required state.

As you’re familiar with the components of Kubernetes networking, we can start with its networking model and how it works. 

Kubernetes Networking Explained

Kubernetes networking follows a specific model that has the following constraints:

• Pods communicate with all other Pods without network address translation
• Nods can communicate with Pods without network address translation
• The IP of a Pod other Pods see for it is the same IP it sees for itself

Due to these restraints, Kubernetes has only a few networking sections. They are:

• Container to Container transfers
• Pod to pod transfers
• Pod to service transfers
• Internet to service transfers

Container to Container

You might think that in networking, a virtual machine interacts with an ethernet device directly, but there’s more to it than that. 

If you’re using Linux, the network namespace will give you a networking stack that has its network devices, routes, and rules for the firewall. Every running process in Linux would communicate with this network namespace. 

A Pod possesses a group of containers within a network namespace. These containers have the same port space and IP address, which is assigned to them through the network namespace. These containers find each other through the localhost because they are located in the same namespace. If your applications are within a pod, they can access the shared volumes as well. 

Pod to Pod

Pods communicate with each other through their IP addresses. Every Pod has a real and distinct IP address in Kubernetes. You already know what Pods are, so we don’t need to touch that subject. We know that Kubernetes uses IPs to facilitate communication between pods; let’s discuss how it does so. 

Pods communicate through their nodes. That’s why to understand Pod to pod communication, and you’ll need to understand the interaction between nodes. 

• Inter Node Communication
• Intra Node Communication

We’ll discuss each one of them in detail:

Inter Node Communication

When the nodes are situated in different pods, they will communicate through this method. We can understand this communication method through an easy example. Suppose there are four various pod networks, namely pod 1, pod 2, pod 3, and so on. Pods 1 and 2 are situated in the Node 1 root network, and pod 3 and 4 are located in the 2nd network. 

You need to transfer a packet from pod 1 to pod 4. 

The packet first has to leave the pod 1 network and go into the root network through veth0. It goes through the Linux bridge, which helps it in finding its destination. As the node doesn’t have a goal within its Pod, it’s sent back to the interface eth0. Now it leaves the first node for the route table. Route table routes the packet to the required node, which is situated in pod4. The packet first reaches node 2, then it reaches the bridge, which directs it to its destination. 

Intra Node Communication

Intra Node communication takes place when the nodes are situated in the same Pod. We can explain intra node communication the same way we explained inter-node communication. In these cases, the packet travels from the first Pod at eth0. It goes into the root network through veth0. Then it has to pass onto the bridge after which, it goes to the designated IP. 

That’s how pods communicate with each other in Kubernetes. Let’s move onto the next section. 

Pod to Service

You’ve already seen in the previous section how traffic is routed between the IP addresses of pods. However, there’s an issue with IP addresses. Pod’s IPs can disappear and reappear according to the scaling of the containers. So, if the containers are scaled, the number of pod IPs will increase the vice versa is also true.

The services help in the management of this situation. Here’s a brief explanation of what services are in Kubernetes, so you don’t have any confusion. 

What are Services in Kubernetes?

Services in Kubernetes configure proxies that have to transfer requests to a group of pods. Those pods get traffic, and the selector handles this task. After the creation of a service, it receives an IP address that handles its requests. There are multiple types of services, and we must discuss them before we move onto Pod to service communication. 

There are a total of 4 kinds of services in Kubernetes. They are:

• ClusterIP
• NodePort
• LoadBalancer
• ExternalName

ClusterIP is the default service type. In this type, the service is accessible only in the cluster. In NodePort, the service is exposed to every node’s IP. The NodePort routes to a ClusterIP service as the system creates it beforehand. Unlike ClusterIP, you can contact this service outside a cluster.

LoadBalancer uses the load balancer of a cloud to expose the service to external networks. NodePort and ClusterIP are automatically created because of it, and ExternalName service transfers it as it reflects a CNAME record. 

Now that you know what services are and how many types of service are there let’s discuss how Pod to service communication takes place. 

How it Works?

In this scenario, the packet leaves the Pod through eth0. It goes to the bridge through the Ethernet device from where it is transferred to the default route of eth0. However, it has to go through iptables before it gets accepted at eth0. The iptables determine the destination of the packet by using the specified rules it has, and it sends the packet to the required Pod. Once it has done that, the packet goes to a pod’s real IP instead of the service’s virtual IP.

External to Service

The previous three methods of traffic routing were concerned with Kubernetes only. But in real cases, chances are, you’ll have to connect your Kubernetes network to a third party network for routing traffic. And this section is about the same. 

When connected with an external network, Kubernetes can perform two functions:

• Route the traffic from the internet to its network
• Route the traffic from its network to the internet

The former requires an Ingress network, and the latter requires an Egress network. Let’s take a look at them. 

Ingress 

Routing your traffic from a public network to your Kubernetes system is very tricky. It requires the LoadBalancer and the Controller to handle the packets. Here’s an example of how it works. 

First, you’ll deploy a service, and your cloud provider will create a new load balancer. The load balancer will distribute the traffic across the virtual machines within your cluster by using the designated port of your service. Here, iptables transfer the traffic they get from the load balancer to the required Pod. The Pod will respond to the client with its IP, and conntrack helps in rewriting the IPs in the right way. 

Layer-7 load balancers present in the network are capable of segmenting the incoming traffic according to URLs and paths. This is very helpful when you’re working with an Ingress network. 

Egress

When you route traffic from a node of your Kubernetes network to the internet, it depends a lot on your network configurations as to how everything would work. We’ll discuss a general example here to touch the topic.

The packet starts from the Pod’s namespace and goes to the root namespace through the veth. Then it goes to the bridge from where it travels to the default service because the IP it needs to go to isn’t in connection with the bridge. It goes through iptables while going to the root namespace . 

Read: Prerequisite for DevOps: It’s not what you think it is

Now Internet gateways only accept IP addresses that are in connection with virtual machines. And our pocket’s source pod is not connected with a VM. So the iptables do a source NAT and change the packet’s source. Now it reaches the internet gateway where it goes through another NAT and then enters the public internet (its destination). 

And this is it. Now you know all about Kubernetes networking and its various components. 

Conclusion

Kubernetes is undoubtedly one of the essential tools you should learn if you’re interested in networking. Those who aren’t familiar with this field wouldn’t know how vital it is. Managing containers and routing traffic according to those traffic requirements can help you considerably. We’ve tried to keep this guide as clear as possible to help you understand everything. 

If you want to learn and master Kubernetes, DevOps, and more, check out IIIT-B & upGrad’s Executive PG Programme in Software Development- Specialisation in Full Stack Development.