Learn Flannel - Multi-node Deployment & Scaling

#Introduction

So far you've been playing in a small cluster. Now it's time to scale: build a three-node kubeadm cluster and observe how Flannel behaves in a more realistic environment.

Episode 10 tests Flannel at real scale. You will build a three-node cluster, verify routing and the overlay, simulate node failure, and assess how far Flannel can be used before your team needs a more advanced CNI.

#Building a Three-Node Cluster

#Init the Control Plane and Join Workers

Start with one control plane node and two workers. Initialize the control plane with Flannel's default CIDR:

sudo kubeadm init --pod-network-cidr=10.244.0.0/16

After init finishes, kubeadm shows the join command. Run it on each worker node:

sudo kubeadm join 192.168.1.10:6443 --token <token> --discovery-token-ca-cert-hash sha256:<hash>

The kubeadm join command above connects a worker to the control plane. After all nodes join, install Flannel as in episode 3 and wait for all kube-flannel Pods to be Running.

#Verify Node Status

kubectl get nodes -o wide
kubectl get pods -n kube-flannel -o wide

Three nodes Ready and three kube-flannel Pods Running mean every node has a flanneld with its own subnet lease.

#Verifying Routing and the Overlay

#Routes on Every Node

Go into one of the nodes and inspect the route table:

ip route | grep flannel

The output of ip route | grep flannel shows routes to other nodes' subnets: 10.244.1.0/24 via node-2's IP, and 10.244.2.0/24 via node-3's IP. This is proof that lease synchronization is working perfectly.

#Testing Cross-node Pods

Deploy a workload with anti-affinity so the Pods are spread out, then test the connection:

kubectl create deployment nginx --image=nginx --replicas=3
kubectl get pods -o wide
kubectl exec -it <pod-node-1> -- ping -c 3 <ip-pod-node-2>

When a ping from a Pod on node-1 to a Pod on node-2 succeeds, the VXLAN overlay works across the whole cluster.

#Failure Domains

#Simulating a Node Down

Test Flannel's resilience by taking down one worker node in a planned manner:

kubectl cordon worker-2
kubectl drain worker-2 --ignore-daemonsets
kubectl get nodes

When node-2 is in the cordoned state, its Pods move to other nodes. Flannel needs no extra configuration because node-2's subnet lease remains as long as it hasn't expired.

#Lease Behavior When a Node Dies for a Long Time

If worker-2 is down longer than the lease validity period, its subnet can be reallocated to a new node. This is automatic and safe, but needs to be understood: the IP addresses of restarted Pods can differ. Applications must always use a Service, not a raw Pod IP.

kubectl get lease -n kube-system

The kubectl get lease -n kube-system command shows the still-active leases. The lease of a dead node will disappear after it expires.

#Scale and Flannel's Limits

#Control Plane Bottleneck

All lease and route updates go through the API server. In very large clusters, for example hundreds of nodes with high Pod churn, the API server can become a bottleneck because every subnet update must pass through kubelet and the CNI. Flannel also doesn't distribute routes globally like BGP; every node stores all routes on its own.

#When to Switch to a More Advanced CNI

There are clear signs: the need for per-namespace NetworkPolicy, thousands of nodes, or Pod traffic that must follow an optimal path without an overlay. When those appear, consider a CNI with richer features. A thorough comparison between Flannel, Calico, and Cilium is in episode 22.

#Conclusion

Episode 10 proved Flannel works at three-node scale: routes are synchronized, the overlay is healthy, and node failure can be simulated safely. You also now know the scale limits to watch out for.

Key takeaways:

• A three-node cluster shows lease and route synchronization between nodes in practice.
• The 10.244.x.0/24 routes on each node prove the overlay works.
• Cordon and drain simulate node failure without damaging the network.
• An expired lease returns its subnet to the pool.
• Flannel depends on the API server as the coordination center for leases.
• Very large scale or policy needs signal that it's time to move CNIs.

In the next episode, episode 11, we will dissect Flannel's integration with CNI plugins — the roles of bridge, portmap, and bandwidth in /opt/cni/bin, the contents of 10-flannel.conflist, and Flannel's integration with Multus for multiple network interfaces.