8.07 Pod Networking
Abstract
Pod Networking defines how Pods receive IP addresses and communicate across nodes in a Kubernetes cluster.
Kubernetes does not provide a built-in Pod network implementation by itself. Instead, it defines a networking model and expects a CNI plugin to implement it.
In production, Pod networking must be reliable, scalable, observable, and secure.
Kubernetes Networking Model
Kubernetes expects the Pod network to satisfy these rules:
- Every Pod must get its own unique IP address
- Every Pod must communicate with every other Pod on the same node
- Every Pod must communicate with every other Pod on different nodes
- Pod-to-Pod communication should work without NAT
Note
Kubernetes defines the expected networking behavior, but the actual implementation is provided by a CNI plugin.
Why Pod Networking Matters
A Kubernetes cluster can have many Pods running across many nodes.
Pod networking answers:
- How does each Pod get an IP?
- How do Pods on the same node communicate?
- How do Pods on different nodes communicate?
- How do Services reach Pods?
- How do network policies control traffic?
Warning
If Pod networking is not configured correctly, Pods may stay in Pending, ContainerCreating, or fail to communicate across nodes.
Example Cluster Layout
Assume a 3-node cluster:
| Node | Node IP | Pod CIDR Example |
|---|---|---|
| Node 1 | 192.168.1.11 |
10.244.1.0/24 |
| Node 2 | 192.168.1.12 |
10.244.2.0/24 |
| Node 3 | 192.168.1.13 |
10.244.3.0/24 |
Combined Pod network:
Tip
Each node can have its own Pod subnet, and the whole cluster can use one larger Pod CIDR range.
Pod Networking High-Level Flow
Pod created
↓
Container runtime creates network namespace
↓
CNI plugin is called
↓
CNI creates veth pair
↓
One end goes into Pod namespace
↓
Other end connects to node bridge/network
↓
Pod gets IP address
↓
Routes are configured
Success
The CNI plugin automates the Linux networking steps required for every Pod.
Node-Level Bridge Network
Each node can have a bridge network.
Example bridge:
Create bridge:
Bring bridge up:
Assign bridge IP:
Note
The bridge acts like a virtual switch for Pod network namespaces on that node.
Pod Network Subnets Per Node
Connecting a Pod to the Bridge
For every Pod, a veth pair is created.
Example steps:
ip link add veth-red type veth peer name veth-red-br
ip link set veth-red netns red
ip link set veth-red-br master v-net-0
ip -n red addr add 10.244.1.2/24 dev veth-red
ip -n red link set veth-red up
Example
This is similar to how CNI plugins attach Pods to the node network automatically.
Same-Node Pod Communication
Pods on the same node communicate through the local bridge.
Example:
Traffic flow:
Success
Same-node Pod communication works once Pods are connected to the same bridge/network.
Cross-Node Pod Communication
Pods on different nodes are in different Pod subnets.
Example:
Node 1 must know how to reach 10.244.2.0/24.
Add route on Node 1:
Add route on Node 1 for Node 3 Pod subnet:
Note
Cross-node Pod communication requires routing between Pod CIDRs.
Example Routes Across Nodes
Warning
Manual routes work for learning, but they do not scale well in production.
Better Routing Approach
Instead of manually configuring routes on every node, production networks usually use:
- CNI-managed routing
- overlay networking
- BGP routing
- cloud-native routing
- centralized router routes
Tip
CNI plugins automate routing, IP allocation, and Pod connectivity so administrators do not manually manage every route.
CNI Role in Pod Networking
CNI stands for Container Network Interface.
CNI defines:
- how the container runtime calls the network plugin
- where CNI config files are stored
- where plugin binaries are stored
- how Pods are added to or removed from the network
Common paths:
Note
The container runtime calls the CNI plugin when a Pod sandbox is created or deleted.
CNI ADD and DEL Operations
A CNI plugin usually handles two major operations:
| Operation | Purpose |
|---|---|
ADD |
Attach Pod/container to the network |
DEL |
Remove Pod/container from the network |
Example script responsibilities:
# ADD
# Create veth pair
# Attach veth pair
# Assign IP address
# Bring up interface
# Add routes
# DEL
# Delete veth pair
# Release IP address
Success
CNI standardizes how container runtimes integrate with networking plugins.
Container Runtime and CNI
The container runtime uses CNI configuration.
Flow:
Container Runtime
↓
--cni-conf-dir=/etc/cni/net.d
↓
--cni-bin-dir=/etc/cni/bin
↓
CNI plugin ADD <container> <namespace>
Tip
If Pod networking fails, check whether CNI config and binaries exist on every node.
Common CNI Plugins
Popular CNI plugins:
| CNI Plugin | Notes |
|---|---|
| Flannel | Simple overlay networking |
| Calico | Routing + NetworkPolicy support |
| Cilium | eBPF-based networking and security |
| Weave Net | Overlay networking |
| Kube-router | Routing and network policy |
Warning
Not every CNI plugin supports Kubernetes NetworkPolicy. Choose based on production requirements.
Manual Pod Networking vs CNI
| Area | Manual Setup | CNI Plugin |
|---|---|---|
| IP allocation | Manual | Automated |
| veth creation | Manual | Automated |
| Bridge setup | Manual | Automated |
| Route setup | Manual | Automated |
| Pod lifecycle handling | Manual | Automated |
| Production use | Not recommended | Recommended |
Danger
Manual Pod networking is only for learning. Production clusters should use a supported CNI plugin.
Production Best Practices
Recommended
- Use a supported and maintained CNI plugin
- Ensure Pod CIDR does not overlap with node or service CIDRs
- Verify every Pod gets a unique IP
- Validate cross-node Pod connectivity
- Use NetworkPolicy if workload isolation is required
- Monitor CNI Pods and logs
- Keep CNI plugin version compatible with Kubernetes version
- Document Pod CIDR and routing design
Do's
- Verify CNI Pods are running
- Check Pod IPs with
kubectl get pods -o wide - Validate Pod-to-Pod communication across nodes
- Check node routing tables
- Check
/etc/cni/net.d - Check
/etc/cni/bin - Use NetworkPolicy-capable CNI for production security
Don'ts
- Don't use overlapping CIDRs
- Don't manually modify CNI-managed interfaces in production
- Don't assume Pod networking works before installing CNI
- Don't expose all Pod networks without policy controls
- Don't ignore CNI logs during troubleshooting
- Don't mix incompatible CNI plugins
Danger
Incorrect Pod networking can break application communication, DNS, service discovery, and cluster readiness.
Troubleshooting Checklist
When Pod networking fails, check:
- Are nodes
Ready? - Is a CNI plugin installed?
- Are CNI Pods running in
kube-system? - Does every Pod have an IP?
- Can Pods communicate on the same node?
- Can Pods communicate across nodes?
- Are routes present for Pod CIDRs?
- Are CNI config files present under
/etc/cni/net.d? - Are CNI binaries present under
/etc/cni/bin? - Are firewall rules blocking Pod traffic?
Useful Commands
kubectl get nodes
kubectl get pods -A -o wide
kubectl get pods -n kube-system
ls /etc/cni/net.d
ls /etc/cni/bin
ip route
ip link
ip addr
ip addr show v-net-0
Learning Commands from Manual Setup
ip link add v-net-0 type bridge
ip link set dev v-net-0 up
ip addr add 10.244.1.1/24 dev v-net-0
ip link add veth-red type veth peer name veth-red-br
ip link set veth-red netns red
ip link set veth-red-br master v-net-0
ip -n red addr add 10.244.1.2/24 dev veth-red
ip -n red link set veth-red up
ip route add 10.244.2.0/24 via 192.168.1.12
Note
These commands explain the concepts behind Pod networking. In real Kubernetes clusters, CNI plugins perform these tasks automatically.
Summary
Quote
- Every Pod needs a unique IP address
- Pods must communicate across nodes without NAT
- Kubernetes defines the networking model but does not implement it directly
- CNI plugins implement Pod networking
- CNI handles veth creation, IP assignment, routing, and cleanup
- Production clusters should use a supported CNI plugin, not manual networking