Pod networking

Exam tasks: 3.1 (connectivity between Pods), with groundwork for 3.3 and 5.5

The decision: when a Pod can't reach another Pod, is the problem inside the Pod (ports, localhost), in the Pod network the CNI plugin builds, or in the Service layer that kube-proxy programs?

The model in four rulesCopy Anchor Link

Kubernetes doesn't ship a Pod network. It sets the rules, and a CNI plugin implements them:

1. Every Pod gets its own IP, unique across the cluster.
2. Any Pod can reach any other Pod, on any node, without NAT. The source IP the receiver sees is the sender's Pod IP.
3. Agents on a node (the kubelet, for probes) can reach every Pod on that node.
4. Containers in the same Pod share that one IP and talk over localhost.

Inside one PodCopy Anchor Link

• The Pod's network namespace is created first and held by the sandbox (pause) container. App containers join it, so they share the IP, the port space, the routing table and localhost.
• Two containers in one Pod can't both bind port 8080. The second one fails with "address already in use".
• containerPort is informational. A process listening on a port you didn't declare still receives traffic. Declaring it matters for named ports that Services and probes reference.
• hostNetwork: true skips the Pod namespace and puts the Pod on the node's IP. You'll see it on CNI agents, kube-proxy and static control-plane Pods. It also makes the Pod compete for host ports.

Across nodes: the CNI pluginCopy Anchor Link

• The container runtime calls the CNI plugin when the kubelet creates a Pod sandbox. The plugin creates the interface, assigns an IP (IPAM) and sets routes.
• Plugins differ in how packets cross nodes (overlay, BGP routing, eBPF) and in features. Flannel gives you connectivity only; Calico and Cilium also enforce NetworkPolicy.
• Until a plugin is installed, nodes stay NotReady with a message such as network plugin not ready / cni plugin not initialized, and CoreDNS stays Pending.

kube-proxy: the Service layer, not the Pod layerCopy Anchor Link

Pod-to-Pod traffic doesn't touch kube-proxy. kube-proxy only turns Service virtual IPs into Pod IPs:

• Runs as a DaemonSet in kube-system, configured by the kube-proxy ConfigMap (mode: field).
• Watches Services and EndpointSlices and writes packet rules on each node.
• Some CNI plugins (Cilium in kube-proxy replacement mode) do this job themselves, so you may find no kube-proxy at all.

Checking connectivity fastCopy Anchor Link

k get pods -o wide -n shop                 # Pod IPs and the node each runs on
k get nodes -o custom-columns=NAME:.metadata.name,CIDR:.spec.podCIDR
k exec -n shop checkout -c metrics-agent -- wget -qO- -T 2 localhost:8080/healthz
k run probe --rm -it --restart=Never --image=busybox:1.36 -- wget -qO- -T 2 http://10.42.2.9:8080
k -n kube-system get ds                    # is the CNI agent and kube-proxy running everywhere?

ScenariosCopy Anchor Link

DrillCopy Anchor Link

kubectl config use-context lab-net

In namespace relay, create a Pod named twin with two containers: web (image nginx:1.27) and poller (image busybox:1.36) that runs wget -qO- localhost:80 every 5 seconds and writes to stdout. Then write the IP of twin and the name of the node it runs on, separated by a space, to /opt/answers/twin.txt.

apiVersion: v1
kind: Pod
metadata:
  name: twin
  namespace: relay
spec:
  containers:
  - name: web
    image: nginx:1.27
    ports:
    - containerPort: 80
  - name: poller
    image: busybox:1.36
    command: ["sh", "-c", "while true; do wget -qO- localhost:80 | head -n 4; sleep 5; done"]

k create ns relay --dry-run=client -o yaml | k apply -f -
k apply -f twin.yaml
k -n relay wait --for=condition=Ready pod/twin --timeout=60s
k -n relay get pod twin -o jsonpath='{.status.podIP} {.spec.nodeName}{"\n"}' > /opt/answers/twin.txt

# verify
k -n relay logs twin -c poller --tail=4      # HTML from nginx means localhost works
cat /opt/answers/twin.txt

Further readingCopy Anchor Link

• Cluster networking
• Services, load balancing and networking overview
• Virtual IPs and service proxies
• Network plugins