Learn Flannel - History, Background & Why You Need Flannel

#Introduction

Every technology has a story, and Flannel was born from a very concrete problem: how to connect Pods spread across many nodes without having to configure the network manually, one by one. Episode 1 opens that story.

We will trace Flannel's evolution since 2014, understand the philosophy of simplicity it has kept to this day, then map out the problem it solves and its position relative to other CNI approaches. By the end of the episode you will understand when Flannel is the right choice and when it is not.

#The Birth of Flannel at CoreOS

#A Brief History: 2014 to v0.28.x

Flannel was developed by CoreOS and released around 2014, in the early days of Kubernetes. At the time its main goal was simple: give every node a unique subnet for Pods, then create an overlay network so Pods on different nodes could communicate with each other. The name Flannel itself comes from the idea of "covering" the network — like a blanket — over the existing host network.

Over time Flannel became one of the earliest and most widely adopted CNIs. Today Flannel is maintained under flannel-io and runs up to version v0.28.x. Even though it is over a decade old, it is still used for one reason: simplicity.

#The Simple Philosophy: One Daemon per Host

Flannel's philosophy can be summarized in one sentence: one flanneld binary per host that allocates a subnet lease. No additional centralized control plane, no separate database, no complicated configuration language. Flannel leverages what Kubernetes already has — the API server — and what Linux already has — routing, bridges, and VXLAN.

This simplicity is what sets Flannel apart from other CNIs. You can debug an entire Flannel network with just a few ip and kubectl commands.

#The Problem Flannel Solves

#Cross-node Pod Connectivity

The core problem Flannel solves is lightweight cross-node Pod connectivity. Without a CNI, a Pod IP allocated on one node is unknown to other nodes, so two Pods on different nodes cannot exchange packets. Flannel solves this with two main mechanisms: VXLAN overlay or direct host-gw routing.

kubectl -n kube-flannel get ds kube-flannel-ds -o jsonpath='{.spec.template.spec.containers[0].image}'

The output will show an image such as docker.io/flannel/flannel:v0.28.8. The kubectl -n kube-flannel get ds command above is also useful as a quick check that Flannel is installed.

#The Painful Manual Alternative

Before Flannel became popular, teams had to create bridges and routes manually on every node, think about subnet allocation to avoid conflicts, and write their own scripts. This approach was fragile: one typo in a route made the whole cluster inconsistent. Flannel removed this manual work by automating subnet allocation and route creation through a single daemon.

#Flannel vs Other Approaches

#VXLAN vs Pure Routing

Flannel offers a choice of philosophy at the backend level. For networks that need flexibility on any host network, Flannel uses VXLAN, which wraps packets in UDP. For networks that need high performance and where all nodes can reach each other, Flannel can use host-gw, which forwards packets directly without encapsulation.

ls -la /opt/cni/bin/

The output of ls /opt/cni/bin/ shows the bridge, portmap, bandwidth, and flannel plugins working together to form the Pod network.

#Early Comparison with Calico and Cilium

Flannel is the simplest choice among the three common CNIs. Calico offers NetworkPolicy and rich BGP routing. Cilium adds eBPF, deep observability, and identity-based policy. Flannel offers none of that, and doesn't want to. When you only need Pods that can reach each other without extra features, Flannel is the most resource-efficient answer.

#Why Flannel Is Still Relevant

#Ecosystem and Adoption

Flannel's relevance comes not only from its simplicity, but also from its ecosystem. The official manifest and Helm chart are officially available, the community is large, and its integration with kubeadm is the first example in the official documentation. This combination makes Flannel an ideal entry point before teams decide whether they need more advanced CNI features.

kubectl get pods -n kube-flannel -o wide

All Pods in the Running state mean every node already has a flanneld daemon ready to allocate subnets.

#When Flannel Is Not the Best Choice

Being honest about limits is also part of learning. If you need per-namespace NetworkPolicy, identity-based policy, or per-service traffic observability, Flannel needs to be accompanied by a policy engine such as Calico policy-only or Cilium — which we will discuss in episodes 14 and 22. Flannel chooses focus: reliable connectivity, not a large feature set.

#Exploring the Fruits of Simplicity

#An Architecture That's Easy to Explain

The proof of Flannel's simplicity is in how you explain it. In a single paragraph you can describe the entire network: each node runs flanneld, takes one subnet from the pool, builds a route or tunnel, and stops there. There is nothing more to explain.

kubectl get lease -n kube-system -o wide

The kubectl get lease -n kube-system command shows one subnet per node. The more nodes, the more leases, but the pattern never changes.

#The Burden on Operations Teams

Simplicity also means a small operational burden. Upgrading is just replacing the DaemonSet image, configuration is a single JSON file, and debugging is a few ip commands. For small teams without dedicated network specialists, this difference is very tangible.

#Choosing the Right Starting Point

For many organizations, Flannel is a healthy starting point before a bigger CNI decision. With a small migration cost, teams can first experience what it's like to operate a CNI in production, then decide whether they need NetworkPolicy or eBPF features.

#One Lesson from History

Architectural decisions that survive a decade are usually born from answers to real problems, not fleeting trends. Flannel was born because cross-node Pod connectivity was painful, and to this day that problem remains relevant. This is a valuable lesson: build decisions on problems, not on gimmicks.

#Conclusion

Episode 1 closes the chapter on Flannel's history: from the CoreOS project in 2014, the cross-node Pod connectivity problem that sparked it, the one-daemon-per-host philosophy, to its position between Calico and Cilium.

Key takeaways:

• Flannel was born at CoreOS around 2014 and is now maintained by flannel-io.
• Its philosophy: one flanneld binary per host that allocates subnet leases.
• The main problem it solves: lightweight cross-node Pod connectivity.
• Two main mechanisms: VXLAN overlay and direct host-gw routing.
• Flannel focuses on connectivity, not NetworkPolicy or deep observability.
• Flannel is the right choice when simplicity and resource efficiency are priorities.

In the next episode, episode 2, we will dissect the core concepts and main architecture — how flanneld takes a subnet lease from the datastore, builds the VXLAN interface, and coordinates through the CNI plugin. This is the technical foundation we will use across all the following episodes, so make sure the concepts stick.