Comparison of Flannel and Calico CNI Plugins for Kubernetes

Flannel

Flannel consists of two components flanneld and flannel-cni-plugin. It stores data via the Kubernetes API or etcd, provides IPAM for podCIDR allocation, and forwards packets using various backends such as VXLAN (overlay), host‑gw (L2 direct), WireGuard, UDP, etc.

Network Model – host‑gw

In host‑gw mode Flannel configures host routes using the github.com/vishvananda/netlink library, adding routes like

ip route add <destination> via <gateway> dev <device>

. This requires L2 connectivity between nodes; otherwise the mode cannot work.

ip route add <destination> via <gateway> dev <device>

Example routing tables for three nodes illustrate how each node learns routes to other pod CIDRs.

# node01 local route
10.244.1.0/24 dev flannel.1 proto kernel scope link

# node02 route
10.244.2.0/24 via 192.168.1.2 dev eth0

# node03 route
10.244.3.0/24 via 192.168.1.3 dev eth0

Calico

Calico has a richer architecture with components such as Calico API server, kube‑controllers, datastore plugin, Typha, Felix, BIRD, confd, Dikastes, CNI and IPAM plugins, and the calicoctl CLI. It stores state in the Kubernetes API or etcd and can use Typha to reduce load on the datastore.

Felix runs on each node, managing interfaces, routes, ACLs and policies, while BIRD provides BGP routing information to other nodes. Calico supports both overlay (VXLAN, IP‑in‑IP) and non‑overlay (host‑gw) modes, with BGP distributing routes for flexible topologies and external pod IP reachability.

ip link add <vxlan-name> type vxlan id <vxlan-id> dev <device> ...

Compared with Flannel, Calico adds dynamic IPAM, BGP‑based routing, eBPF support, monitoring and network‑policy features, making it suitable for larger clusters.

Summary

Flannel’s simple design works well for small clusters, while Calico’s more complex architecture offers additional network models, dynamic routing, and advanced features for larger, production‑grade environments.