Learn Flannel - Performance & Troubleshooting

#Introduction

Flannel is easy to operate while healthy, and that is precisely its strength: because the architecture is simple, troubleshooting is simple too. All you need is the right sequence of checks.

Episode 19 sharpens that skill. You will learn a set of diagnostic commands and how to solve the five most common problems Flannel users encounter.

#The Diagnostic Command Set

#Inspecting Routes, Interfaces, and Neighbors

Before overthinking, gather the facts from the node. The commands below give you a complete picture of the network condition on a single node:

ip route | grep flannel
ip -d link show flannel.1
ip neigh show dev flannel.1
journalctl -u kube-flannel -n 50

The ip route | grep flannel command shows the subnets the node knows, ip -d link show flannel.1 shows the status of the VXLAN interface, and journalctl -u kube-flannel shows the daemon logs on the node.

#Diagnostics from the Kubernetes Side

Complete the picture with data from the cluster side:

kubectl get pods -n kube-flannel -o wide
kubectl get lease -n kube-system
kubectl logs -n kube-flannel -l k8s-app=flannel

The kubectl get pods -n kube-flannel command shows the status of the flanneld Pods, and kubectl get lease -n kube-system shows the subnet allocation.

#Common Troubleshooting

#Pods Cannot Connect Across Nodes

Symptom: Pods on the same node connect, but cross-node they don't. Check in order: the lease status, the route to the other node's subnet, then the VXLAN interface. If the route is missing, synchronization is broken; if the route exists but ping fails, check the firewall for port 4789.

kubectl run nettest --image=busybox --restart=Never --command -- sleep 3600
kubectl exec -it nettest -- ping -c 3 <ip-pod-node-lain>

#VXLAN Not Coming Up

A flannel.1 interface that is not up usually means flanneld failed to create it at startup. Check the flanneld logs for error messages, and make sure UDP port 4789 is open. After fixing it, restart the DaemonSet:

kubectl -n kube-flannel rollout restart ds/kube-flannel-ds
kubectl -n kube-flannel rollout status ds/kube-flannel-ds

#br_netfilter Not Active

A confusing symptom: Pods can ping each other, but TCP connections to Services keep dropping. The cause is br_netfilter being inactive, so bridged traffic is not filtered. Check and fix it:

sysctl net.bridge.bridge-nf-call-iptables
sudo modprobe br_netfilter

#MTU Mismatch

Symptom: small packets succeed, large transfers fail. This is a hallmark of MTU mismatch. Compare the host and flannel.1 MTUs, then adjust as discussed in episode 16:

ip link show eth0
ip link show flannel.1

The difference must be 50 for VXLAN. If it is larger, there is an inconsistent setting somewhere on the path.

#Subnet Lease Conflict

Symptom: two nodes claim the same subnet, routes overlap. Check the leases and delete the conflicting one after making sure the node is dead:

kubectl get lease -n kube-system -o wide
kubectl delete lease -n kube-system <node-mati>

#A Systematic Troubleshooting Flow

#The Order of Checks

For any problem, use a consistent order: start with the Pod, then the node, then the cluster. First, make sure the target Pod is healthy. Second, make sure the route on the target node is correct. Third, make sure the lease is synchronized in the cluster. Fourth, make sure the firewall opens the backend port.

kubectl get pods -A -o wide | grep -E "Running|flannel"

The output of kubectl get pods -A gives you a quick overview of healthy Pods and running flanneld Pods. From there you can decide where to go next.

#Note-taking as a Habit

Record every incident: the symptoms, the commands used, and the root cause. This habit turns troubleshooting from a guessing game into a directed process, and your incident documentation becomes a team asset.

#Conclusion

Episode 19 sharpened your ability to handle Flannel in the field: the right diagnostic commands, five common problems with their solutions, and a systematic order of checks.

Key takeaways:

• Gather the facts first: routes, interfaces, neighbors, and logs.
• Cross-node Pod failures: check leases, routes, interfaces, then the firewall.
• A VXLAN interface that won't come up usually means flanneld failed at startup.
• Dead br_netfilter causes mysterious TCP disconnects.
• MTU mismatch shows up as failing large transfers.
• Lease conflicts are cleaned up by deleting the conflicting Lease object.

In the next episode, episode 20, we will look at the latest: the newest stable features v0.28.x — backend refinements, the iptables and nftables traffic managers, build security, plus an in-depth look at CVE-2026-32241 and the importance of patch upgrades.