Cette page est affichée en anglais. Une traduction française est en cours.
ScriptsMay 15, 2026·3 min de lecture

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.

Prêt pour agents

Cet actif peut être lu et installé directement par les agents

TokRepo expose une commande CLI universelle, un contrat d'installation, le metadata JSON, un plan selon l'adaptateur et le contenu raw pour aider les agents à juger l'adaptation, le risque et les prochaines actions.

Native · 98/100Policy : autoriser
Surface agent
Tout agent MCP/CLI
Type
Skill
Installation
Single
Confiance
Confiance : Established
Point d'entrée
Flannel Overview
Commande CLI universelle
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

Fil de discussion

Connectez-vous pour rejoindre la discussion.
Aucun commentaire pour l'instant. Soyez le premier à partager votre avis.

Actifs similaires