Skip to content

Networking Concepts

Assumes: you know what a Pod and a Deployment are - see Pods and Deployments.

Kubernetes networking is built on a simple model with strict expectations for connectivity and service discovery.

Terms used on this page

Infrastructure networking has its own vocabulary. Four terms carry most of the weight here:

  • NAT (Network Address Translation): rewriting the source or destination IP of a packet as it passes through. The Kubernetes model deliberately avoids it between pods.
  • CIDR: a way of writing a range of IP addresses, like 10.244.0.0/16. The number after the slash says how many leading bits are fixed - smaller number, bigger range.
  • CNI (Container Network Interface): the plugin standard Kubernetes uses to hand pod networking to an implementation such as Cilium, Calico, or Flannel.
  • Overlay network: pod traffic wrapped inside another packet so it can cross a network that knows nothing about pod IPs. The alternative is direct routing, where the underlying network is taught the pod routes.

Core Model

  1. Every pod gets its own IP address.
  2. Pods can communicate with other pods without user-managed NAT between pods.
  3. Services provide stable virtual endpoints in front of changing pod backends.

Containers in the same pod share one network namespace and communicate over localhost.

Traffic Types

graph TB
    EXT([External Client]) -->|north-south| ING[Ingress / Gateway]
    ING --> SVC[Service]
    SVC --> P1[Pod A]

    P1 -->|east-west| SVC2[Service B]
    SVC2 --> P2[Pod B]
    SVC2 --> P3[Pod B replica]
  • East-west: traffic between workloads inside the cluster. Uses Services and DNS for discovery.
  • North-south: traffic entering or leaving the cluster. Uses Ingress or Gateway API on top of Service backends.

IP address spaces

Kubernetes uses three distinct CIDR ranges that must not overlap:

  • Node CIDR: IP addresses assigned to nodes (from your infrastructure).
  • Pod CIDR: IP addresses assigned to pods (e.g. 10.244.0.0/16). The CNI plugin manages these.
  • Service CIDR: virtual IPs assigned to Services (e.g. 10.96.0.0/12). These exist only in iptables/eBPF rules, not routed in your network.

Data Plane Components

Networking behavior depends on your implementation stack:

  • CNI plugin: implements the pod network, assigns pod IPs, and handles routing between nodes. Common choices include Cilium (eBPF-based, policy-rich), Calico (BGP routing, NetworkPolicy), and Flannel (simple overlay). The CNI must support NetworkPolicy if you want policy enforcement.
  • kube-proxy: installs iptables or IPVS rules on each node to translate Service virtual IPs to pod IPs. In eBPF-based stacks (Cilium with kube-proxy replacement), this is handled in the kernel without iptables.
  • CoreDNS: in-cluster DNS resolver. Every Service and (when using headless services) individual pods get DNS records.

Service Discovery

Service DNS format:

<service>.<namespace>.svc.cluster.local

Example:

nslookup api.backend.svc.cluster.local

Security and Segmentation

By default, many CNIs allow broad pod-to-pod communication.

Use NetworkPolicies to explicitly control allowed ingress and egress paths between workloads.

Anatomy of one in-cluster request

Tie the pieces together by tracing curl http://api.backend:8080 from a pod:

  1. DNS: the pod's resolver (configured by the kubelet to point at CoreDNS) resolves api.backend via its search path to api.backend.svc.cluster.local, returning the Service's ClusterIP.
  2. Virtual IP translation: the packet leaves the pod toward the ClusterIP. Rules programmed by kube-proxy (or the CNI's eBPF datapath) on the sender's node rewrite the destination to a specific backend pod IP chosen from the EndpointSlice.
  3. Pod network delivery: the CNI routes the packet to the target pod's node and network namespace - via direct routing, BGP, or an overlay depending on the plugin.
  4. Return path: connection tracking reverses the rewrite so the reply appears to come from the ClusterIP.

Each stage fails differently, which gives you a clean diagnostic order: name resolution (nslookup), endpoint membership (kubectl get endpointslices), then pod-to-pod connectivity (direct pod IP curl). If direct pod IP works but the Service name doesn't, the problem is DNS or endpoints - never the CNI.

Practical Troubleshooting Checks

kubectl get pods -A -o wide
kubectl get svc -A
kubectl get endpointslices -A
kubectl get netpol -A

If DNS fails, check CoreDNS pods in kube-system.

Key Takeaways

  • Every pod gets its own IP, and pods reach each other without user-managed NAT.
  • Three CIDR ranges (node, pod, service) must not overlap - most "weird networking" incidents trace back to one that does.
  • A Service ClusterIP is a virtual IP: it exists only in iptables or eBPF rules on each node, and nothing ever answers on it directly.
  • The diagnostic order is fixed: DNS first, then endpoints, then pod-to-pod connectivity. If a pod IP works and the Service name does not, the CNI is not your problem.

Check Yourself

You curl a Service's ClusterIP from a node and it works, but ping on the same IP gets nothing. Why?

Nothing is listening on that address - there is no interface and no host owning it. The ClusterIP only exists as a rule that rewrites the destination of matching traffic to a backend pod IP. curl hits TCP port 80 and matches the rule; ICMP does not, so there is nothing to answer it.

Your pod CIDR is 10.244.0.0/16 and your company VPN also routes 10.244.0.0/16. What is likely to break, and why is it hard to diagnose?

Traffic to the overlapping range becomes ambiguous: some destinations resolve to pods, some to corporate hosts, depending on which route wins on which node. It presents as intermittent, host-dependent failures rather than a clean outage, which is why the three ranges being non-overlapping is a hard requirement, not a recommendation.

A pod cannot reach api.backend. You curl the backend pod's IP directly and it responds. Where is the fault?

In DNS or endpoints, not the pod network. Direct pod IP connectivity proves the CNI is routing correctly. Check name resolution (nslookup api.backend) and then whether the Service actually has backends (kubectl get endpointslices) - an empty endpoint list usually means a selector mismatch or failing readiness probes.

You add your first NetworkPolicy and nothing changes - all traffic still flows. Give two plausible explanations.

Either your CNI does not implement NetworkPolicy (the objects are accepted by the API server and simply ignored), or the policy does not select the pods you think it does. Isolation is opt-in: a pod no policy selects accepts everything.

Further Reading

Beginner track - step 5 of 12. Next: Services. Back to the track overview.