# Flannel — Simple Overlay Network for Kubernetes

> A lightweight networking fabric for Kubernetes that gives each node a subnet for container-to-container communication. Supports VXLAN, host-gw, WireGuard, and other backends.

## Install

Save as a script file and run:

# Flannel — Simple Overlay Network for Kubernetes

## Quick Use
```bash
# Install on a Kubernetes cluster
kubectl apply -f https://github.com/flannel-io/flannel/releases/latest/download/kube-flannel.yml

# Verify flannel pods are running
kubectl get pods -n kube-flannel
```

## Introduction
Flannel is one of the simplest ways to set up a Layer 3 network for Kubernetes. It runs a small agent (flanneld) on each node that allocates subnets from a larger cluster CIDR and configures a backend to route traffic between nodes. Its focus on simplicity makes it a common default for K3s, kubeadm, and other Kubernetes installers.

## What Flannel Does
- Assigns a unique subnet to each node from a configurable cluster CIDR
- Encapsulates cross-node pod traffic using VXLAN, host-gw, or WireGuard backends
- Stores subnet lease data in the Kubernetes API or etcd
- Configures local routing tables so pods can reach pods on other nodes
- Runs as a DaemonSet with minimal resource overhead

## Architecture Overview
Each node runs a flanneld daemon that watches the Kubernetes Node API for subnet allocations. On startup, flanneld claims a /24 subnet from the cluster-wide /16 CIDR and writes it to a local file. The chosen backend (VXLAN by default) creates a virtual interface and sets up forwarding rules. Cross-node packets are encapsulated at the source node and decapsulated at the destination.

## Self-Hosting & Configuration
- Deploy via the official kube-flannel.yml manifest
- Set the pod CIDR with `--pod-network-cidr=10.244.0.0/16` during cluster init
- Change the backend in the ConfigMap: `"Backend": {"Type": "host-gw"}`
- WireGuard backend requires the wireguard kernel module on each node
- Flannel does not enforce NetworkPolicy; pair it with Calico or Cilium for policy support

## Key Features
- VXLAN backend works across any IP-routable infrastructure without special switch config
- host-gw backend avoids encapsulation overhead on L2-adjacent nodes
- WireGuard backend adds encryption with minimal performance cost
- Supports dual-stack IPv4/IPv6 networking
- Lightweight: each flanneld process uses under 20 MB of RAM

## Comparison with Similar Tools
- **Calico** — full-featured CNI with NetworkPolicy, BGP peering, and eBPF dataplane; more complex to operate
- **Cilium** — eBPF-based CNI with advanced observability and security; heavier resource footprint
- **Weave Net** — mesh overlay with built-in encryption; higher overhead than Flannel VXLAN
- **Canal** — combines Flannel networking with Calico NetworkPolicy enforcement

## FAQ
**Q: Does Flannel support NetworkPolicy?**
A: No. Flannel handles routing only. Use Canal (Flannel + Calico policy) or deploy a separate policy engine.

**Q: Which backend should I choose?**
A: VXLAN is the safe default. Use host-gw if all nodes share a Layer 2 segment for better performance. Use WireGuard if you need encrypted node-to-node traffic.

**Q: Can I migrate from Flannel to Calico or Cilium?**
A: Yes, but it requires draining nodes and replacing the CNI configuration. Plan for a maintenance window.

**Q: What Kubernetes versions does Flannel support?**
A: Flannel supports Kubernetes 1.22 and later. It is the default CNI for K3s.

## Sources
- https://github.com/flannel-io/flannel
- https://github.com/flannel-io/flannel/blob/master/Documentation/configuration.md

---
Source: https://tokrepo.com/en/workflows/asset-e14c4427
Author: Script Depot