Flannel
A simple layer 3 network fabric designed for Kubernetes that provides each pod with a unique, routable IP address.
What is Flannel?
Flannel is a network fabric for containers, specifically designed for Kubernetes. It creates a layer 3 IPv4 network between multiple nodes in a cluster, enabling containers to communicate across hosts with unique IP addresses, which eliminates port mapping complexities and simplifies container networking.
Kubernetes administrators and operators who need a simple, reliable networking solution for pod communication across cluster nodes, as well as Docker users requiring cross-host container networking without Kubernetes.
Developers choose Flannel for its simplicity, reliability, and minimal focus on core networking without policy enforcement, offering multiple backend mechanisms (like VXLAN and host-gw) and seamless integration with Kubernetes via CNI or Docker via etcd.
Overview
flannel is a network fabric for containers, designed for Kubernetes
Use Cases
Best For
- Setting up pod networking in Kubernetes clusters with minimal configuration.
- Providing cross-host container communication for Docker environments using etcd.
- Deploying network fabrics in distributions like K3s that default to Flannel.
- Avoiding port mapping complexities by assigning unique IPs to each container/pod.
- Using flexible backends such as VXLAN for overlay networks or host-gw for direct routing.
- Integrating with Kubernetes via the kube subnet manager to avoid a separate etcd cluster.
Not Ideal For
- Clusters requiring integrated network security policies and access controls out of the box.
- High-performance environments where overlay networks like VXLAN introduce unacceptable latency overhead.
- Teams wanting a fully automated, zero-configuration networking solution without manual backend or module setup.
- Projects that aim to avoid external dependencies like etcd when not using Kubernetes API storage.
Pros & Cons
Pros
Deployment is a one-liner with kubectl apply, and it integrates seamlessly using the Kubernetes API as a backing store to avoid a separate etcd cluster, as shown in the README.
Supports multiple backends like VXLAN for overlays and host-gw for direct routing, allowing adaptation to various infrastructure needs, detailed in the backends documentation.
Focuses solely on layer 3 networking, which simplifies maintenance and pairs well with specialized policy tools like Calico, as stated in the philosophy section.
Works with both Kubernetes via CNI and Docker using etcd, providing versatility across container environments, as mentioned in the getting started guides.
Cons
Requires manual steps like downloading and modifying manifests for custom podCIDR, installing CNI plugins separately, and ensuring br_netfilter module is loaded, with the README noting kubeadm no longer checks this in version 1.30.
Lacks native network policy enforcement, necessitating additional projects like Calico for security, which adds complexity and operational burden.
When used outside Kubernetes, Flannel always requires etcd as the datastore, introducing an extra component to deploy and maintain, as highlighted in the Docker setup section.
Frequently Asked Questions
Related Projects
KubernetesProduction-Grade Container Scheduling and Management
MobyThe Moby Project - a collaborative project for the container ecosystem to assemble container-based systems
traefikThe Cloud Native Application Proxy
GiteaGit with a cup of tea! Painless self-hosted all-in-one software development service, including Git hosting, code review, team collaboration, package registry and CI/CD
Found a gem we're missing?
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.