Flannel | kubernetes-under-the-hood
A technical deep-dive into Flannel's VXLAN implementation that uses a hotel room analogy to explain how Kubernetes pods actually communicate across network namespaces, bridges, and overlay networks.
Read Original Summary used for search
TLDR
• Each pod gets its own network namespace with isolated networking—connected to the host via veth pairs (virtual ethernet tunnels) that plug into a cni0 bridge for same-node communication
• Flannel allocates /24 subnets from 10.244.0.0/16 to each node, giving you max 254 pods per node, with the flanneld daemon maintaining routing tables
• Cross-node traffic uses VXLAN overlay networking (flannel.1 interface) to encapsulate Layer 2 Ethernet frames in UDP packets, making separate physical networks operate as one logical network
• The hotel analogy: pods are rooms with guest phones (eth interfaces), cni0 is the building's internal phone system, and VXLAN is the phone lines connecting different hotel buildings
In Detail
The Kubernetes Network Model requires three things: pods communicate without NAT, nodes reach pods without NAT, and pods see themselves with the same IP others see them as having. Flannel implements this by giving each pod its own network namespace (netns) with a dedicated eth interface. Virtual ethernet pairs (veth) act as tunnels connecting each pod's namespace to the root namespace, where a Linux bridge called cni0 enables pod-to-pod communication on the same node—like an internal phone system in a hotel building.
For cross-node communication, Flannel uses VXLAN to create an overlay network. The flannel.1 interface encapsulates Layer 2 Ethernet frames inside Layer 4 UDP packets (port 4789), allowing pods on different physical nodes to communicate as if they're on the same network. Flannel allocates subnets from the default 10.244.0.0/16 CIDR, giving each node a /24 subnet (10.244.X.0/24), which limits you to 254 active pods per node. The flanneld daemon runs on each host to maintain routing information and keep the network topology synchronized.
The packet flow for cross-node communication goes: pod netns → veth → cni0 → eth0 → gateway → destination node's eth0 → cni0 → veth → destination pod netns. VXLAN is recommended over host-gw (which requires Layer 2 adjacency) and UDP (deprecated, debugging only). Understanding these primitives—network namespaces, veth pairs, bridges, and VXLAN—is essential for debugging Kubernetes networking issues and making informed CNI plugin decisions.