Understanding Pod Networking and Communication in a Kubernetes Cluster

In Kubernetes, every pod gets its own IP address and can communicate with any other Pod in the cluster without NAT. The Container Network Interface (CNI) plugin ensures routing between pods across nodes inside the Kubernetes cluster.

Pods in Kubernetes are temporary and their IP addresses can change. To solve this problem, Kubernetes uses Services. A service provides a stable IP address, a DNS name and load balancing between pods.

Kubernetes uses kube-proxy to maintain networking rules on each node using iptables or IPVS. It handles Service traffic and load balances requests to healthy Pods.

How Pod Networking Is Created Inside a Kubernetes Cluster

Networking inside pods

Networking Inside Pods

When a Pod is created, the Container Runtime Interface (CRI) creates a network namespace (netns) for the Pod. At this stage, the Pod is isolated and has no network connectivity yet.

The CRI then asks the Container Network Interface (CNI) plugin to execute the ADD command with the Pod’s network namespace path. The CNI plugin performs the following tasks:

• Creates a virtual Ethernet pair (veth).
• Connects one end to the Pod namespace and the other end to the node network.
• Assigns an IP address to the Pod.
• Configures routing rules.
• Enables communication across the cluster network.

Finally, the CNI plugin returns the Pod networking information to the CRI, and the CRI reports the Pod as ready to the kubelet.

How Direct Pod-to-Pod Communication Works

Let’s say we have three worker nodes inside a Kubernetes cluster. Pod A runs on Node A and Pod C runs on Node C. Pod A wants to communicate directly with Pod C without using a Service.

Communication Flow

Pod A → Node A → CNI Network → Node C → Pod C

In this scenario, the CNI plugin is responsible for inter node networking. kube-proxy is not involved in direct Pod-to-Pod communication. We assume Pod A IP: 10.244.1.2 and Pod C IP: 10.244.3.5

Pods communication without using services

Step by step flow:

1. Pod A sends a packet to Pod C (10.244.3.5).
2. Node A checks its routing table.
3. The routing table identifies that the destination network exists through the cluster network managed by the CNI plugin.
4. The packet travels through the cluster network.
5. Node C receives the packet.
6. Node C forwards the packet to Pod C.

How Pod to Pod Communication Works via Service ?

In this example, we have three nodes A, B and C. The pod A running inside node A wants to send a request to Pod C via a service called my-service.

Communication Flow

Pod A → Service IP → kube-proxy → Pod C

Pods communication using services

Step by step flow:

1. Pod A sends a request to my-service.
2. Kubernetes DNS resolves the service name to the service ClusterIP.
3. The packet reaches the node networking layer.
4. kube-proxy on Node A intercepts the traffic.
5. kube-proxy selects one healthy backend Pod using load balancing.
6. kube-proxy rewrites the destination from the service IP to the selected pod IP using iptables or IPVS rules.
7. The packet is routed through the CNI network.
8. Node C receives the packet.
9. The packet is forwarded to Pod C.
10. Pod C processes the request and sends the response back to Pod A

Since pods are temporary and their IP addresses can change frequently, understanding how pods communicate directly and through services is essential for designing scalable, reliable, and production-ready Kubernetes applications.