Understanding Flannel: What It Does, How It Works, and How It Differs from Calico

What is Flannel? Flannel is a lightweight network plugin commonly used in Kubernetes clusters, belonging to the overlay network (tunnel) category of CNI solutions.

Purpose of Flannel Each pod in a Kubernetes cluster receives a unique IP, but pods on different nodes cannot communicate because their subnets differ and lack routing rules. Flannel assigns a unified pod CIDR to the cluster, maintains node‑to‑node routing, and enables cross‑node pod communication. It does not handle intra‑pod or pod‑to‑service traffic.

Flannel operating modes

vxlan – the default tunnel mode.

host-gw – a high‑performance mode without encapsulation.

udp – an early, high‑cost mode that is now deprecated.

How Flannel works

Flannel reads the cluster‑wide CIDR (e.g., 172.16.0.0/16) from etcd and allocates a distinct pod subnet to each node (e.g., node A: 172.16.1.0/24, node B: 172.16.2.0/24).

The flanneld daemon on each node continuously pulls the node‑to‑pod‑subnet mapping (node IP ↔ node pod CIDR) from etcd and updates the local routing table and associated network interfaces.

Each pod’s IP belongs to its node’s allocated subnet; pods connect to the host via the cni0 bridge (created by Flannel) using a veth pair.

vxlan mode – tunnel encapsulation

Encapsulates Layer‑2 pod packets inside UDP packets (default destination port 8472) so they can traverse any Layer‑3 network.

flanneld creates a VXLAN tunnel device (default name flannel.1, VNI = 1) on each node.

It maintains a local ARP table and FDB (forwarding database) that map pod IPs to target node physical IPs and the MAC of the remote flannel.1 device.

When a pod packet needs to reach a pod on another node, the kernel wraps it in a UDP packet, sends it via the node’s physical NIC, the remote node’s flannel.1 device decapsulates it, restores the original pod packet, and forwards it to the destination pod.

Host‑gw mode – high‑performance, no encapsulation

Each node acts as the gateway for other nodes’ pod subnets, adding static Layer‑3 routes locally.

Cross‑node pod traffic is forwarded directly to the target node’s physical IP without UDP encapsulation, yielding performance close to native networking.

Advantages: high performance, no encapsulation overhead, suitable for large‑scale, high‑throughput clusters.

Limitations: all nodes must reside in the same IP subnet; nodes in different subnets cannot use host‑gw mode (e.g., node 1 in 193.168.1.0/24 and node 2 in 193.168.2.0/24).

Core packet flow (example)

PodA → nodeA cni0 → nodeA flannel.1 (encapsulated) → nodeA eth0 → any network → nodeB eth0 → nodeB flannel.1 (decapsulated) → nodeB cni0 → PodB

Images illustrating the architecture and mode specifics are included in the original article.