Kubernetes Networking - Traffic Flow from Internet to Application Pod

Last Updated on September 16, 2023 by cscontents

Table of Contents

Introduction

Kubernetes is a container orchestration platform that allows you to deploy and manage containerized applications at scale. To understand the workings of a Kubernetes cluster deeply we must understand how networking works inside the cluster. Kubernetes networking is the invisible glue that holds your containerized applications together.

In this article, we will discuss how network traffic flows from the internet to your application pod in Kubernetes cluster.

Before going through this article, it will be better if you make yourself aware of the various components in a Kubernetes cluster.

For reference, you can go through the below article: Components of Kubernetes Cluster

What is Kubernetes networking?

Kubernetes networking is the system that allows containers/pods on the same node or different nodes in a Kubernetes cluster to communicate with each other. It provides a number of features that make it easy to manage network traffic, such as load balancing, service discovery, and network policies.

How does Kubernetes networking work?

Kubernetes networking is based on the concept of a virtual network. A virtual network is a logical network that is isolated from other networks. This means that traffic between containers/pods running on the same virtual network can be isolated from traffic between containers/pods running on different virtual networks.

Kubernetes networking components

The following are the main components of Kubernetes networking:

Container Network Interface (CNI): CNI is a plugin system that allows Kubernetes to integrate with different networking providers. Some popular CNI plugins include Calico, Flannel, and Weave Net.
Kubernetes Proxy: Kubernetes Proxy is a network proxy that runs on each node in the cluster. It is responsible for routing traffic between containers/pods on the same node and between containers/pods on different nodes.
DNS Server: Kubernetes DNS Server is a DNS server that provides service discovery for containers/pods in the cluster. It resolves Kubernetes service names to the IP addresses of the containers/pods that are running the service.
Services: Services are a way to expose pods to the outside world. They provide a load-balanced IP address and DNS name for a pod or group of pods.
Ingresses: Ingresses are a way to configure external load balancing for your applications. They allow you to route traffic from outside the cluster to your services.

Understanding Network Flow in K8s cluster

Let’s try to understand network traffic flow in a Kubernetes cluster in simple way. For simplicity, we won’t bring the concept of “ingress” here.

External/outside/internet to Service Communication

To access your application from outside (e.g., internet), external traffic should be allowed to reach the Kubernetes services within the cluster. This can be achieved by using these 4 different types of service –

ClusterIP
NodePort
LoadBalancer (Used in a cloud-hosted environment)

Kubernetes service is an object that will take your request to the right destination (application pod).

Service to Pod Communication

Service – it is a Kubernetes object/resource that helps us to expose our application pod outside.

Pod – it is the smallest deployable unit in K8s.

By definition, service is used to expose our application. Service is one type of Kubernetes object/resource. If we see the service definition file (manifest file) we will get to know how the service is connected/linked with any pod or set of pods.

After deploying the service, we can also get to know the service “endpoints” by running the below command.

kubectl describe service <service name>

Pod to Pod Communication

Now here are two cases,

Case 1: Pod to Pod communication which is within the same node.
Case 2: Pod to Pod communication which are on different nodes.

Two points to be noted here –

Each pod is assigned an IP address.
When a pod gets destroyed, that IP address associated with it also gets destroyed.

Case 1: Pod to Pod communication which is within the same node

Let’s see the below diagram first.

This pod-1 to pod-2 (and vice versa) communication is enabled by default since they are part of the same node. This is enabled by default since they are in the same host and their IP will be different (obviously). The IPs of the pod-1 and pod-2 are assigned from the local network of that node.

Case 2: Pod to Pod communication which are on different nodes

Let’s see the below diagram first.

Here, pod-1 and pod-2 are on two different nodes. Communication between them happens through a “network plugin”. This “network plugin” will create some route tables. Using this route table traffic from one pod to another pod is forwarded.

Container to Container Communication

Here container to container communication means communication between containers within the same pod.

Let’s see the below diagram first.

Container 1 & Container 2 has the same IP and it is the same as Pod IP. But the communication to these containers happens over different ports.
For example, To send any traffic from outside of the pod to container-1, if it uses port 90, then to send traffic to container-2, it will use port 95.
Similarly, communication between container-1 and container-2 happens over different port. From container-2 to container-1 it should use port 90, and port 95 in opposite way.

Conclusion

Kubernetes networking is the foundation for building scalable and reliable containerized applications. By understanding how Kubernetes networking works, you can leverage its features to improve the performance, reliability, and security of your applications.

Thank you.

If you are interested in learning DevOps, please have a look at the below articles, which will help you greatly.