Kubernetes Networking: CNI, kube-proxy & eBPF

In one line

Kubernetes requires every pod to reach every other pod without NAT; a CNI plugin implements that across nodes, kube-proxy (or eBPF) implements Services, and NetworkPolicies filter it.

0/3 · 0%

Key ideas

01
The Kubernetes network model: every pod gets its own IP; pods can reach each other across nodes WITHOUT NAT; agents on a node can reach all pods on it. How that's achieved is left to the CNI plugin.
02
CNI (Container Network Interface) plugins: the AWS VPC CNI gives pods real VPC IPs (which is why subnet sizing matters: Terraform course, Mission 2.1); Calico can route pod networks with BGP (Topic 4.4) or use overlays; Flannel uses a VXLAN overlay (Topic 0.3's MTU lesson); Cilium uses eBPF for routing, Services, and policy.
03
SERVICES: a Service's ClusterIP is virtual; nothing listens on it. kube-proxy programs iptables or IPVS rules on every node that DNAT traffic for the ClusterIP to one of the pod IPs (Topic 4.3; Kubernetes course, Topic 3.1). With thousands of Services, iptables rule chains get long and slow to update, which is one reason for eBPF.
04
eBPF lets small, verified programs run inside the Linux kernel at hook points (network devices, sockets, system calls). Cilium uses it to replace kube-proxy with efficient hash-table lookups, enforce NetworkPolicies (including L7-aware policies), and provide deep visibility with Hubble, which shows every flow with its verdict (forwarded or dropped, and why). Falco (DevSecOps course, Lab 3.4) uses the same technology for security.
05
Debugging pod networking uses the same method (Topic 6.1) from inside the pod: DNS via CoreDNS, the route to the other pod's IP, NetworkPolicies that may drop traffic (timeout!), and the Service's endpoints (kubectl get endpointslices). An empty endpoint list is the classic 'Service has no pods' problem: a selector mismatch or failing readiness probes.

Code & diagrams

k8s-net.shbash

kubectl get pods -o wide                              # pod IPs and nodes
kubectl get svc shoplite -o wide                      # ClusterIP and selector
kubectl get endpointslices -l kubernetes.io/service-name=shoplite   # the pod IPs behind it
kubectl exec -it deploy/shoplite -- nc -vz payments 8081             # test from inside a pod
sudo iptables -t nat -L KUBE-SERVICES -n | head      # kube-proxy's DNAT rules (iptables mode)
cilium status && hubble observe --namespace shop --verdict DROPPED   # Cilium clusters: who is being dropped?

ServicePathdiagram

Rendering diagram…

Explain it without notes

A Service exists and DNS resolves its name, but every connection to it times out. Name two likely causes.

Practice

Why would a large cluster move from kube-proxy's iptables mode to eBPF-based Service handling?

Trade-offs

↔
Overlays work anywhere but add encapsulation overhead and MTU issues; routed or VPC-native CNIs perform better but consume real network addresses and need network integration. eBPF brings performance and visibility at the cost of kernel-version requirements and a steeper learning curve.

Done when you can

I can state the Kubernetes network model.
I know what CNI plugins, kube-proxy, and eBPF each do.
I can debug a Service with endpoints, NetworkPolicies, and in-pod tests.