Tagged: Container Networking
10 posts · browse all tags
-
Container Networking Deep Dive Part 1: From Namespaces to a Container Network by Hand
Before Docker automates any of it, build a container network by hand: two network namespaces, a veth pair each, a Linux bridge, and one iptables NAT rule. Everything Docker does later is this, generated for you.
-
Container Networking Deep Dive Part 10: A Full Walkthrough, Chasing a Cross-Node Connectivity Bug
A checkout service scales out, starts failing calls to a payment gateway on a different node, and the failure turns out to be two separate problems stacked on top of each other. A start-to-finish walkthrough using every technique from this series.
-
Container Networking Deep Dive Part 2: Docker's Default Bridge Model, Unpacked
Install Docker and run the same two-container topology from Part 1 with docker run instead of ip netns. Then read the actual iptables rules and docker0 bridge Docker generated, line for line, against the ones written by hand.
-
Container Networking Deep Dive Part 3: Docker Network Drivers Compared
bridge, host, macvlan, ipvlan, and none are not five ways to do the same thing. Each one trades away a specific piece of isolation, performance, or addressing flexibility. A driver-by-driver comparison with the actual tradeoff each makes.
-
Container Networking Deep Dive Part 4: Multi-Host Overlay Networking and the VXLAN Underneath It
A Docker Swarm overlay network makes containers on different hosts look like they share a bridge. VXLAN encapsulation is how, and it costs 50 bytes of every packet's MTU budget, the same overhead this series already covered from the tunneling side.
-
Container Networking Deep Dive Part 5: What CNI Actually Is
Kubernetes doesn't use Docker's networking model. It defines a plugin interface instead, CNI, with a lifecycle of exactly two verbs. Why one-IP-per-pod forced that split, and what a CNI plugin actually does when a pod starts.
-
Container Networking Deep Dive Part 6: CNI Plugins Compared, Flannel, Calico, and Cilium
Three CNI plugins solve the same ADD-verb reachability problem three different ways: VXLAN encapsulation, BGP-distributed routes, and an eBPF datapath. The architecture and datapath differences, not a feature-checklist bake-off.
-
Container Networking Deep Dive Part 7: eBPF-Native Networking and the End of kube-proxy
kube-proxy's default iptables mode chain-walks a rule per backend, per packet. Cilium's kube-proxy replacement skips that entirely, at the socket layer, before a packet is even built. What kube-proxy actually does, and what changes when eBPF replaces it.
-
Container Networking Deep Dive Part 8: Network Policy Enforcement Compared, iptables vs eBPF
The same Kubernetes NetworkPolicy resource gets enforced completely differently depending on the CNI plugin underneath it. Calico's default path turns it into iptables rule chains; Cilium turns it into eBPF map lookups keyed on pod identity. Same intent, different mechanism, different failure modes.
-
Container Networking Deep Dive Part 9: Troubleshooting Container Networking
A vendor-neutral methodology for the five failure modes that account for most container networking outages: conntrack exhaustion, VXLAN MTU fragmentation, DNS-in-pod failures, cross-node connectivity breaks, and tcpdump inside a network namespace.