Flannel
By CoreOS / Flannel Project
Flannel is a simple overlay networking tool for Kubernetes that gives each node in a cluster a distinct range of IP addresses, allowing pods across different nodes to communicate as though they were on the same flat network. It focuses…
Definition
Flannel is a simple overlay networking tool for Kubernetes that gives each node in a cluster a distinct range of IP addresses, allowing pods across different nodes to communicate as though they were on the same flat network. It focuses narrowly on providing basic pod-to-pod connectivity rather than advanced network policy or security features, making it one of the simplest container network interface plugins to deploy.
Overview
Flannel was created by CoreOS in the early days of container orchestration to solve a specific, narrow problem: Kubernetes expects every pod to have its own IP address and to be able to reach every other pod's IP address directly, but the underlying physical or cloud network often has no idea these pod IP ranges exist. Flannel's job is to bridge that gap by giving each node a slice of a larger address space and establishing an overlay network that carries pod traffic between nodes regardless of what the underlying network looks like. Mechanically, Flannel typically operates by encapsulating pod traffic in VXLAN packets, wrapping each pod-to-pod packet inside a UDP packet that the underlying network can route between the hosts using their normal IP addresses. A small agent runs on each node, watching a shared data store, often the same etcd instance Kubernetes uses, to learn which node owns which address range, and configuring local routing rules accordingly. Some Flannel configurations can also use simpler, non-encapsulated backends when the underlying network permits direct routing, trading some flexibility for lower overhead. Compared to Calico or Cilium, which pair pod networking with a full network policy engine for controlling which workloads can talk to which, Flannel deliberately leaves policy enforcement out of scope, historically requiring it to be paired with a separate policy controller, such as Calico's policy-only mode, if fine-grained access control is needed. This narrower focus is exactly what makes Flannel simple to deploy and reason about: there are fewer moving parts and configuration options than in a full-featured CNI plugin. In practice, Flannel is commonly chosen for smaller clusters, development and testing environments, and situations where the operator wants pod networking to simply work without needing to design network policies or integrate with BGP-based physical networking. Its long history and wide adoption also mean it is well documented and supported across many Kubernetes distributions and installers as a default or easy-to-select networking option. The main trade-offs are the encapsulation overhead of its default VXLAN backend, which adds a small amount of latency and CPU cost compared to native routing approaches, and its lack of built-in network policy enforcement, which means security-conscious clusters typically need to add another tool alongside it. Teams that anticipate needing granular traffic control from the start often choose Calico or Cilium directly rather than starting with Flannel and adding policy enforcement later, since retrofitting policy onto an existing overlay can add operational complexity partway through a cluster's lifecycle.
Key Features
- Provides pod-to-pod connectivity across Kubernetes cluster nodes
- Uses VXLAN encapsulation as its default overlay networking backend
- Assigns each node a distinct range of pod IP addresses
- Runs a lightweight agent on each node to manage routing
- Supports alternative backends for direct, non-encapsulated routing
- Integrates with the same data store Kubernetes uses for coordination
- Focuses narrowly on connectivity without built-in policy enforcement
- Widely supported as a default networking option across distributions