Kubernetes Networking Overview

Kubernetes networking is one of the most frequently misunderstood areas of the platform — not because it is conceptually hard, but because it spans multiple abstraction layers, each implemented by a different pluggable component. This overview establishes the four fundamental networking problems Kubernetes solves, the components responsible for each, and the invariants that all implementations must satisfy. Every subsequent page in this section builds on this foundation.

The Four Networking Problems

Kubernetes networking addresses four distinct communication scenarios:

The Kubernetes Network Model

Address Spaces

A Kubernetes cluster uses three distinct, non-overlapping CIDR ranges:

Networking Layers and Responsible Components

Component Roles at a Glance

What Each Page in This Section Covers

Key Networking Invariants

These invariants hold regardless of which CNI, kube-proxy mode, or Ingress controller you choose:

1. No NAT between pods. Pod A reaching pod B's IP sees B's real IP. Pod B sees A's real pod IP as the source. NAT only applies at the node boundary for external-to-pod traffic (NodePort/LoadBalancer with externalTrafficPolicy: Cluster).
2. Pod IPs are ephemeral. A pod's IP is released when the pod is deleted. Services abstract this: they track healthy pod IPs via EndpointSlices and kube-proxy programs new rules within seconds.
3. ClusterIPs are virtual. A ClusterIP address does not exist on any network interface. It lives exclusively in iptables DNAT rules (or IPVS virtual server tables). Pinging a ClusterIP will time out unless the ping itself is intercepted by iptables and DNAT'd to a real pod IP.
4. DNS is the primary discovery mechanism. Kubernetes services are primarily discovered via DNS (<service>.<namespace>.svc.cluster.local), not by hard-coding ClusterIPs. Applications should always use DNS names; IPs change between reinstalls.
5. Network Policies are additive and default-allow. Without any NetworkPolicy, all pod-to-pod traffic is allowed. Adding a NetworkPolicy affects only the pods it selects. For real isolation, you need a default-deny base policy.

CIDR Planning Reference

# Common CIDR allocation example
--cluster-cidr=10.244.0.0/16         # pod CIDR (65536 pod IPs total)
--service-cluster-ip-range=10.96.0.0/12  # service CIDR (1M virtual IPs)
# Node IPs: 10.0.0.0/16 (cloud VPC)

# Per-node pod subnet (auto-assigned from cluster CIDR):
# node-1: 10.244.1.0/24  → 254 usable pod IPs
# node-2: 10.244.2.0/24  → 254 usable pod IPs
# (maxPods=110 default in kubelet limits actual pod count regardless of subnet size)

# Large cluster example:
--cluster-cidr=10.0.0.0/8            # 16M pod IPs
--node-cidr-mask-size=24             # /24 per node (254 pod IPs each)
# Supports: 65536 nodes × 254 pods = ~16M pods

# Tight cloud VPC example (avoid pod/VPC overlap):
# VPC: 172.31.0.0/16 (AWS default)
# Pod CIDR: 192.168.0.0/16    ← must not overlap with 172.31.0.0/16
# Service CIDR: 10.100.0.0/16 ← must not overlap with either

# Dual-stack:
--cluster-cidr=10.244.0.0/16,fd00::/48
--service-cluster-ip-range=10.96.0.0/12,fd01::/108

Packet Lifecycle: Pod-to-Pod Cross-Node

A brief end-to-end trace for a packet from Pod A (node 1) to Pod C (node 2):

Packet Lifecycle: Pod-to-Service

The ClusterIP is intercepted in the kernel's PREROUTING chain before any routing decision. The DNAT rule rewrites the destination to one of the backing pod IPs. The routing then proceeds exactly as a direct pod-to-pod packet. The reverse SNAT (connection tracking) rewrites the response source back to the ClusterIP before returning to the calling pod, so the caller always sees the service IP as the responder.

Quick Reference: Common kubectl Networking Commands

# List all services with ClusterIPs
kubectl get svc -A -o wide

# List all endpoints (backing pods for each service)
kubectl get endpointslices -A

# Check pod IPs
kubectl get pods -A -o wide | awk '{print $1, $2, $6, $7}'

# Inspect DNS for a service (from within a pod)
kubectl run dnstest --image=busybox:1.36 --rm -it -- \
  nslookup kubernetes.default.svc.cluster.local

# Test pod-to-pod connectivity
kubectl exec -it pod-a -- curl http://10.244.2.3:8080

# Test pod-to-service connectivity
kubectl exec -it pod-a -- curl http://my-service.my-namespace.svc.cluster.local

# Inspect node routes
kubectl get node -o jsonpath='{range .items[*]}{.metadata.name}: podCIDR={.spec.podCIDR}{"\n"}{end}'

# Watch endpoint changes for a service
kubectl get endpointslices -l kubernetes.io/service-name=my-service -w

# Debug: trace iptables rules for a ClusterIP
iptables-save | grep "10.96.0.100"
ipvsadm -Ln | grep -A3 "10.96.0.100"

CNI Plugin Selection Guide

Common Networking Pitfalls