ScriptsMay 15, 2026·3 min read

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.

Agent ready

This asset can be read and installed directly by agents

TokRepo exposes a universal CLI command, install contract, metadata JSON, adapter-aware plan, and raw content links so agents can judge fit, risk, and next actions.

Native · 98/100Policy: allow
Agent surface
Any MCP/CLI agent
Kind
Skill
Install
Single
Trust
Trust: Established
Entrypoint
Flannel Overview
Universal CLI install command
npx tokrepo install e14c4427-5036-11f1-9bc6-00163e2b0d79

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

Discussion

Sign in to join the discussion.
No comments yet. Be the first to share your thoughts.

Related Assets