CKA — Pod-to-Pod Communication

6 minute read

CKA Exam Domain

Domain Weight
Services & Networking 20%

Understanding how Pods communicate at the network level is critical for the CKA exam. You need to know the Kubernetes networking model, what CNI plugins do, and how to troubleshoot connectivity issues.

Kubernetes Networking Model

Kubernetes enforces three fundamental networking rules:

  1. Every Pod gets its own IP address — No manual IP assignment needed. Each Pod has a unique IP within the cluster.
  2. Pods on the same node can communicate without NAT — They see each other’s real IPs, no address translation.
  3. Pods across different nodes can communicate without NAT — A Pod on Node A can reach a Pod on Node B using the Pod’s IP directly.

This flat networking model is a core principle of Kubernetes. It means:

  • Containers within the same Pod share the same network namespace (and IP). They communicate via localhost.
  • Containers in different Pods always communicate using the Pod’s IP address.
  • No ports need to be mapped between nodes and Pods (unlike Docker’s -p flag).

The CNI plugin is responsible for making all of this work.

Same-Node Communication

When two Pods are on the same node, they communicate through a virtual network bridge:

Pod A (10.244.1.5) ──> veth pair ──> Bridge (cbr0) ──> veth pair ──> Pod B (10.244.1.8)

How it works:

  1. Each Pod has a veth pair — one end inside the Pod’s network namespace, the other end attached to a bridge on the node
  2. The node has a bridge (like cbr0 or cni0) that connects all veth interfaces
  3. When Pod A sends a packet to Pod B’s IP, it goes through the veth pair to the bridge
  4. The bridge knows Pod B’s veth interface (via MAC learning) and forwards the packet

This is similar to virtual machines connected to a virtual switch.

Cross-Node Communication

When two Pods are on different nodes, the networking is more complex. The CNI plugin must ensure that a packet sent from Pod A on Node 1 can reach Pod B on Node 2.

Two common approaches:

Overlay networks (VXLAN):

Pod A (Node 1) ──> veth ──> Bridge ──> VXLAN Tunnel ──> Bridge ──> veth ──> Pod B (Node 2)

The original Pod-to-Pod packet is encapsulated inside a VXLAN packet and sent across the physical network. The receiving node de-encapsulates it and delivers it to the target Pod.

Native routing (BGP):

Pod A (Node 1) ──> veth ──> Bridge ──> Node routing table ──> Physical network ──> Node 2 ──> Bridge ──> veth ──> Pod B (Node 2)

Each node’s routing table knows which Pod IP ranges are on which nodes. Packets are routed natively without encapsulation. This is more efficient but requires the underlying network to support it.

CNI Plugin Role

CNI (Container Network Interface) is a specification that defines how network plugins integrate with container runtimes. In Kubernetes:

  1. When a Pod is created, the kubelet calls the CNI plugin
  2. The CNI plugin allocates an IP address from its pool
  3. It configures the veth pair, bridge, and routing rules
  4. When the Pod is deleted, the CNI plugin cleans up

The CNI plugin is what makes the Kubernetes networking model a reality. Without it, Pods wouldn’t be able to communicate.

CNI plugin location: Usually found in /opt/cni/bin/ on each node. Configuration in /etc/cni/net.d/.

# Check installed CNI plugins (on the node)
ls /opt/cni/bin/

# Check CNI configuration
ls /etc/cni/net.d/
cat /etc/cni/net.d/*.conflist
Plugin Networking Key Features Use Case
Calico BGP routing or VXLAN overlay Network policies, high performance Production clusters
Flannel VXLAN overlay Simple, easy to set up Getting started, small clusters
Cilium eBPF-based Advanced traffic management, observability High-performance, security-focused
Weave Net Mesh overlay Simple setup, encryption support Multi-cloud, small clusters

For the CKA exam, you don’t need to install CNI plugins from scratch, but you should know:

  • What a CNI plugin does
  • How to check which CNI plugin is installed
  • That Pods in Pending state with “network not ready” often mean the CNI plugin is missing
# Check which CNI plugin is installed
ls /etc/cni/net.d/
# Example: 10-calico.conflist, 10-flannel.conflist

# Check if CNI pods are running
kubectl get pods -n kube-system | grep -E "calico|flannel|cilium|weave"

Network Troubleshooting

When Pods can’t communicate, here’s a systematic debugging approach:

Step 1: Check Pod IPs and status:

# Get Pod IPs
kubectl get pods -o wide

# Example output:
# NAME    READY   STATUS    IP            NODE
# pod1    1/1     Running   10.244.1.5    node1
# pod2    1/1     Running   10.244.2.8    node2

Step 2: Test connectivity between Pods:

# Ping from pod1 to pod2
kubectl exec -it pod1 -- ping 10.244.2.8

# HTTP request from pod1 to pod2
kubectl exec -it pod1 -- wget -qO- http://10.244.2.8:80

# Test via Service name
kubectl exec -it pod1 -- wget -qO- http://web-svc:80

Step 3: Check the CNI plugin:

# Are CNI Pods running?
kubectl get pods -n kube-system | grep -E "calico|flannel|cilium|weave"

# Check CNI Pod logs
kubectl logs -n kube-system <cni-pod-name>

Step 4: Check node-level networking:

# Check if the Pod's IP is reachable from the node
ping 10.244.1.5

# Check routing table
ip route

# Check bridge interfaces
ip link show type bridge

kubectl Commands

# Get Pod IPs
kubectl get pods -o wide

# Test connectivity from a Pod
kubectl exec -it <pod> -- ping <target-ip>
kubectl exec -it <pod> -- wget -qO- http://<target>:<port>
kubectl exec -it <pod> -- curl http://<target>:<port>

# Check DNS resolution from a Pod
kubectl exec -it <pod> -- nslookup <service-name>

# Run a temporary networking debug Pod
kubectl run netshoot --image=nicolaka/netshoot --rm -it -- bash

Practice Questions

Q1. What are the three fundamental rules of the Kubernetes networking model?

Show Answer
  1. Every Pod gets its own unique IP address
  2. Pods on the same node can communicate without NAT
  3. Pods on different nodes can communicate without NAT

These rules ensure a flat, predictable network where every Pod can reach every other Pod using real IP addresses.

Q2. A Pod on Node A needs to reach a Pod on Node B. The CNI plugin uses VXLAN. Describe the packet flow.

Show Answer
  1. Pod A sends a packet to Pod B’s IP
  2. The packet exits Pod A’s network namespace via the veth pair
  3. It reaches the bridge on Node A
  4. The CNI plugin encapsulates the original packet inside a VXLAN header
  5. The encapsulated packet is sent across the physical network to Node B
  6. Node B’s CNI plugin de-encapsulates the packet
  7. The original packet is forwarded through the bridge to Pod B’s veth pair
  8. Pod B receives the packet

Q3. How do containers within the same Pod communicate?

Show Answer

Containers within the same Pod share the same network namespace, which means they share the same IP address. They communicate via localhost on different ports.

# Container A can reach Container B on:
curl localhost:8080

Q4. Pods are stuck in Pending status and node shows “network not ready”. What’s the likely cause?

Show Answer

The CNI plugin is not installed or not running properly. Without a CNI plugin, Kubernetes cannot assign IPs to Pods or set up networking.

Check:

# Check for CNI plugin pods
kubectl get pods -n kube-system

# Check CNI configuration on the node
ls /etc/cni/net.d/
ls /opt/cni/bin/

Install or fix the CNI plugin to resolve the issue.

Q5. How do you test HTTP connectivity from one Pod to another Pod’s port 80?

Show Answer 
# Using wget
kubectl exec -it pod1 -- wget -qO- http://<pod2-ip>:80

# Using curl (if available in the image)
kubectl exec -it pod1 -- curl http://<pod2-ip>:80

# Using a temporary debug Pod with network tools
kubectl run netshoot --image=nicolaka/netshoot --rm -it -- curl http://<pod2-ip>:80

Updated:

You may also enjoy