K3s-Distributionen im Vergleich: Flannel, Calico, Cilium — CNI-Performance und die Realität der NetworkPolicy

K3s ist die beliebteste leichtgewichtige Kubernetes-Distribution für Edge, IoT, ARM und ressourcenbeschränkte Umgebungen – doch „k3s“ umfasst ein breites Ökosystem aus Installer-Tools, CNI-Plugins und Deployment-Mustern, die sich in der Produktion sehr unterschiedlich verhalten.

Dieser Artikel vergleicht die Landschaft anhand von vier Dimensionen: Distributionsoptionen, CNI-Plugin-Performance und NetworkPolicy-Unterstützung, Ingress und Storage sowie Produktionsaspekte wie HA, Scaling-Limits und bekannte Fallstricke.

Wenn Sie auf die harte Tour herausgefunden haben, dass NetworkPolicies bei Flannel stillschweigend ignoriert werden, ist dieser Artikel genau richtig für Sie.

K3s Distributionsoptionen

Es gibt vier Hauptwege, um k3s zu betreiben. Jeder zielt auf einen anderen Anwendungsfall ab:

Feature	k3s Official	k3sup	k3d	AutoK3s
Installationsmethode	Shell-Script auf dem Node	SSH von lokaler Maschine	Docker-Container	CLI/UI + Provider-APIs
Zielumgebung	Jeder Linux-Host	Remote-VMs via SSH	Lokale Entwicklung / CI	Multi-Cloud
HA-Unterstützung	Embedded etcd / externe DB	k3sup-pro plan/apply	Multi-Server Docker-Container	Provider-native HA-Configs
Airgap-Unterstützung	Manuell	Pro-Feature	N/A	Integriert
GUI	Keine	Keine	Keine	Integriertes Dashboard
ARM-Unterstützung	Ja	Ja	Ja	Ja
Bestens geeignet für	Production Edge	VM-Provisioning	Entwicklung / CI	Multi-Cloud-Management

k3s Official (Rancher / SUSE)

Die Referenz-Distribution: ein einziges <100 MB Binary, das alles bündelt. Server-Nodes führen k3s server aus (Control-Plane + Datastore), Agent-Nodes führen k3s agent ohne Control-Plane-Overhead aus.

curl -sfL https://get.k3s.io | sh -

Der Single-Server-Modus nutzt embedded SQLite; HA nutzt embedded etcd (3+ Server) oder einen externen Datastore (PostgreSQL, MySQL, externes etcd). Zu den gebündelten Standardkomponenten gehören Flannel (VXLAN), Traefik, CoreDNS, ServiceLB (Klipper), Local Path Provisioner und ein kube-router-basierter NetworkPolicy-Controller.

k3sup (ketchup)

Ein clientseitiges SSH-Tool von Alex Ellis, das k3s von Ihrer lokalen Maschine aus auf jeder VM bootstrappt. Es loggt sich nie direkt in das Remote-System ein, sondern nutzt SSH-Key-Forwarding.

k3sup install --ip 192.168.1.100 --user root

# Join an agent
k3sup join --ip 192.168.1.101 --server-ip 192.168.1.100 --user root

Die Pro-Version (25 $+/Monat) ergänzt paralleles HA-Deployment aus JSON-Konfigurationen, uninstall, exec, get-config. Bestens geeignet für IaC-style Provisioning von Bare-Metal-, EC2- oder Raspberry Pi-Nodes.

k3d

k3s in Docker – erstellt containerisierte Cluster für die lokale Entwicklung und CI/CD.

k3d cluster create mycluster --servers 3 --agents 2 --port "8080:80@loadbalancer"

Führt ein automatisches Merge der kubeconfig durch, unterstützt --k3s-arg für beliebige k3s-Flags, Port-Mappings, Registry-Mounts und GPU-Passthrough. Bestens geeignet, um Multi-Node-Verhalten auf einer einzigen Maschine zu testen, ohne echte VMs provisionieren zu müssen.

AutoK3s

Eine Management-Plattform (CLI + UI) für das Deployment von k3s über verschiedene Cloud-Provider hinweg (AWS, GCP, Alibaba, Tencent). Unterstützt Airgap-Installationen und Helm-basiertes Add-on-Management. Bestens geeignet für Multi-Cloud-Deployments mit einem einheitlichen Dashboard.

CNI Plugin Deep Dive

Die Wahl des Container Network Interface (CNI) Plugins ist die einflussreichste Entscheidung für die Performance, die Sicherheitsisolation und die operative Komplexität Ihres k3s-Clusters.

Flannel (Standard)

Flannel ist das Standard-CNI in k3s. Es bietet einfaches Overlay-Networking mittels VXLAN, host-gw oder WireGuard-Backends. Minimaler Overhead, minimale Features.

Performance (10GbE Testbed, keine Policies):

• Durchsatz: ~6,8 Gbps
• Latenz: ~75 μs
• Speicher: ~50 MB pro Node

NetworkPolicy-Unterstützung: ✅ Mit k3s' integriertem Controller, ❌ Flannel allein

Dies ist die kritische Unterscheidung, die die meisten Nutzer überrascht.

Calico

Calico ist das ausgereifteste CNI für policy-gesteuertes Networking. Es unterstützt iptables, eBPF und VPP Dataplanes. Volle Kubernetes NetworkPolicy + globale Network Policy CRDs.

Performance (10GbE Testbed):

Data plane	Durchsatz	Latenz	Policy-Auswirkung
iptables	~7,5 Gbps	~68 μs	15-20% Overhead
eBPF (Kernel ≥5.8)	~9,0 Gbps	~45 μs	3-5% Overhead

Speicher: ~120-180 MB pro Node.

Cilium

Cilium ist eBPF-native. Dies ist keine Option – Cilium erfordert einen Kernel ≥5.8 und läuft vollständig im eBPF-Subsystem. Das Ergebnis ist die beste Performance bei tiefster Observability.

Performance (10GbE Testbed):

• Durchsatz: ~9,2 Gbps
• Latenz: ~42 μs
• Policy-Auswirkung: 2-3%

CiliumNetworkPolicy CRDs erweitern L3/L4-Policies auf L7 (HTTP, gRPC, Kafka, DNS). Hubble bietet eBPF-native Flow-Observability – keine Sidecars, keine iptables, kein Overhead.

Speicher: ~200 MB pro Node (höher als Calico, gerechtfertigt durch die eBPF-Dataplane).

Canal (Flannel + Calico Policy)

Canal kombiniert die VXLAN-Dataplane von Flannel mit der Felix-Policy-Engine von Calico. Sie erhalten das einfache Overlay von Flannel zusammen mit der NetworkPolicy-Durchsetzung von Calico – jedoch ohne die eBPF- oder BGP-Fähigkeiten von Calico.

Die Performance spiegelt die von Flannel wider (~6,8 Gbps, ~75 μs) mit einem Policy-Overhead von ~15% durch iptables.

Vergleichsmatrix

Dimension	Flannel	Calico (iptables)	Calico (eBPF)	Cilium	Canal
Durchsatz	~6,8 Gbps	~7,5 Gbps	~9,0 Gbps	~9,2 Gbps	~6,8 Gbps
Latenz (Mittel)	~75 μs	~68 μs	~45 μs	~42 μs	~75 μs
NetworkPolicy	❌ nativ / ✅ k3s bundle	✅ Voll + Global	✅ Voll + Global	✅ L3-L7	✅ Via Calico
eBPF-Support	❌	❌	✅	✅ (erforderlich)	❌
Policy-Overhead	N/A	15-20%	3-5%	2-3%	~15%
Speicher/Node	~50 MB	~120-180 MB	~120-180 MB	~200 MB	~170 MB
Observability	Nur Logs	Basic / Tigera	Basic / Tigera	✅ Hubble	Basic
Kernel-Anforderung	Beliebig	Beliebig	≥5.8	≥5.8	Beliebig
K3s-Integration	Standard	Benutzerdefiniert	Benutzerdefiniert	Benutzerdefiniert	Dokumentiert

NetworkPolicy Reality Check

Flannel erzwingt KEINE NetworkPolicies

Dies ist die häufigste Stolperfalle bei k3s. Flannel ist lediglich ein Networking-Plugin – es stellt die Overlay-Konnektivität bereit und sonst nichts. Das offizielle Flannel README besagt:

"Flannel konzentriert sich auf das Networking. Für Network Policies können andere Projekte wie Calico verwendet werden."

Wenn Sie eine NetworkPolicy in einem Cluster mit Flannel ohne einen Policy-Controller erstellen, wird das Objekt vom API-Server akzeptiert, aber niemals erzwungen. Ihre "deny all ingress"-Policy verweigert somit gar nichts.

Was k3s zur Behebung mitliefert

K3s bündelt einen eigenen NetworkPolicy-Controller, der die netpol-Bibliothek von kube-router verwendet. Dieser Controller ist standardmäßig aktiviert und bietet eine grundlegende Durchsetzung von Kubernetes NetworkPolicies auf Basis von Flannel.

Um zu prüfen, ob er läuft:

# Check if the kube-router netpol controller is active
kubectl -n kube-system get pods -l k8s-app=kube-router

# Or check k3s startup flags
journalctl -u k3s | grep disable-network-policy

Um ihn zu deaktivieren (notwendig bei der Verwendung von Calico oder Cilium, die eigene Policy-Engines mitbringen):

curl -sfL https://get.k3s.io | sh -s - --disable-network-policy

Oder in der Konfigurationsdatei:

# /etc/rancher/k3s/config.yaml
disable-network-policy: true

Die drei Szenarien

Szenario	NetworkPolicy erzwungen?	Notizen
k3s Standard (Flannel + integriertes netpol)	✅ Ja	kube-router netpol Controller erzwingt Basis-Policies
Flannel allein, kein Controller	❌ Nein	Objekte werden akzeptiert, aber nicht erzwungen – stiller Fehler
Calico / Cilium mit --disable-network-policy	✅ Ja	CNI-eigene Policy-Engine, funktionsreich

So prüfen Sie, ob die NetworkPolicy funktioniert

Vertrauen Sie nicht auf Konfigurationen – verifizieren Sie es:

# Deploy a test pod and a deny-all policy
kubectl run test-pod --image=nginx
kubectl run test-client --image=busybox -- sleep 3600

# Apply a policy that denies all ingress
kubectl create networkpolicy deny-all --pod-selector=app=test-pod \
  --policy-type=Ingress

# This should FAIL if NetworkPolicy is enforced
kubectl exec test-client -- wget -qO- http://test-pod:80
# ❌ If connection succeeds: NetworkPolicy is NOT working
# ✅ If connection times out: NetworkPolicy is enforced

Performance-Auswirkungen von NetworkPolicies

Wenn Policies erzwungen werden, hängt die Performance von der CNI-Data-Plane ab:

• Cilium (eBPF): 2-3 % Durchsatzreduzierung – vernachlässigbar
• Calico (eBPF): 3-5 % – sehr gut
• Calico (iptables): 15-20 % – spürbar; skaliert linear mit der Anzahl der Regeln
• Flannel + kube-router netpol: moderater Overhead bei Basis-Policies

CNIs in k3s ändern

K3s macht den Austausch von CNIs unkompliziert. Aus der offiziellen Dokumentation:

Starten Sie K3s mit --flannel-backend=none und installieren Sie die CNI Ihrer Wahl. Die meisten CNI-Plugins bringen ihre eigene Network-Policy-Engine mit, daher wird empfohlen, auch --disable-network-policy zu setzen, um Konflikte zu vermeiden.

Wechsel zu Calico

# 1. Install k3s without flannel and built-in netpol
curl -sfL https://get.k3s.io | sh -s - \
  --flannel-backend=none \
  --disable-network-policy

# 2. Install Calico
kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/master/manifests/calico.yaml

Für k3s benötigt Calico containerIPForwarding: Enabled:

# calico-installation.yaml
apiVersion: operator.tigera.io/v1
kind: Installation
metadata:
  name: default
spec:
  calicoNetwork:
    containerIPForwarding: Enabled

Wechsel zu Cilium

# 1. Install k3s without flannel and netpol
curl -sfL https://get.k3s.io | sh -s - \
  --flannel-backend=none \
  --disable-network-policy

# 2. Install Cilium via Helm
helm repo add cilium https://helm.cilium.io/
helm install cilium cilium/cilium --namespace kube-system

Wichtig: Bevor Sie k3s-killall.sh ausführen, entfernen Sie manuell die Cilium-virtuellen Schnittstellen, da Sie sonst Gefahr laufen, die Netzwerkverbindung zu verlieren:

ip link delete cilium_host
ip link delete cilium_net
ip link delete cilium_vxlan

Ingress-Optionen

Traefik (k3s Standard)

Traefik wird von k3s automatisch auf den Ports 80/443 als LoadBalancer-Service bereitgestellt. Anpassbar über HelmChartConfig:

# /var/lib/rancher/k3s/server/manifests/k3s-traefik-config.yaml
apiVersion: helm.cattle.io/v1
kind: HelmChartConfig
metadata:
  name: traefik
  namespace: kube-system
spec:
  valuesContent: |-
    service:
      type: LoadBalancer
    ports:
      web:
        port: 80
    logs:
      general:
        level: INFO

Traefik v3 unterstützt die Gateway API, verfügt über eine integrierte ACME (Let's Encrypt)-Integration und ein Diagnose-Dashboard. Arbeitsspeicher: ~120 MB für 3 Replicas.

Um Traefik während der Installation zu deaktivieren: --disable=traefik.

Nginx Ingress

Das Community-Projekt ingress-nginx erreichte im März 2026 das EOL (End of Life). F5 pflegt die Nachfolger: NGINX Ingress Controller (NIC) und NGINX Gateway Fabric (Gateway API-native). RKE2 v1.36 wechselte zu Traefik als Standard; v1.37 entfernt ingress-nginx vollständig.

Wenn Sie Nginx benötigen, verwenden Sie den von F5 gepflegten NIC und nicht das archivierte Community-Projekt.

Ingress-Vergleich

Feature	Traefik v3	Nginx NIC	HAProxy Ingress
TLS-Automatisierung	Integriertes ACME	cert-manager	cert-manager
Config-Reload	Zero-Downtime	Hot reload	Zero-Downtime
Dashboard	✅ Integriert	❌	❌
CRD-Routing	✅ IngressRoute CRD	❌ (Annotations)	❌ (Annotations)
Speicher (3 Replicas)	~120 MB	~180 MB	~90 MB
RPS	~60-70% von Nginx	Höchste (C-Engine)	Nahe an Nginx

Storage-Optionen mit k3s

Local Path Provisioner (Standard)

Provisioner: rancher.io/local-path. Access-Modus: Nur ReadWriteOnce. Volume-Binding: WaitForFirstConsumer. Keine Replikation, kein gemeinsamer Zugriff, Node-Affinität erforderlich. Bestens geeignet für Dev, Single-Node oder ephemere Daten.

Longhorn

CNCF Incubating (graduated 2026). Distribuierter Block-Storage mit synchroner Replikation, Snapshots, S3-Backups und einer integrierten Web-UI. Arbeitsspeicher: ~300 MB pro Storage-Node. Minimum 3 Nodes für HA. Bestens geeignet für Produktions-Block-Storage und Datenbanken.

Rook-Ceph

CNCF Graduated. Block (RBD), Filesystem (CephFS) und Object (RGW) in einem. Auf k3s ist ein Override des kubelet-Pfads erforderlich:

helm install rook-ceph rook-release/rook-ceph \
  --set csi.kubeletDirPath=/var/lib/rancher/k3s/agent/kubelet

Arbeitsspeicher: 1,5-3 GB pro Storage-Node (signifikant höher als bei Longhorn). Minimum 3 Nodes mit dedizierten Raw-Disks. Bestens geeignet für Enterprise-Storage mit RWX-Anforderungen.

Storage-Entscheidungshilfe

Anwendungsfall	Empfehlung
Dev / Single-Node	Local Path Provisioner
Produktion Block (<20 Nodes)	Longhorn
Enterprise Storage, RWX	Rook-Ceph (CephFS)
Object Storage im Cluster	Rook-Ceph (RGW)
Max. Performance, App-Level HA	OpenEBS LocalPV

Überlegungen für die Produktion

HA: Embedded etcd vs. Externer Datastore

Option	Bestens geeignet für	Komplexität
Embedded SQLite	Single-Node, Edge	Minimal
Embedded etcd (3+ Server)	Kleine HA-Cluster	Niedrig
PostgreSQL	Cloud-native, Managed DB	Mittel
MySQL / MariaDB	Bestehende MySQL-Infra	Mittel
Externes etcd	Große Cluster, strikte Perf.	Hoch

Ressourcen-Profiling

Offizielle k3s-Benchmarks (Intel 8375C):

Rolle	Min. CPU	Min. RAM (SQLite)	Min. RAM (etcd)
Server + Workload	6% Core	1596 MB	1606 MB
Server + 1 Agent	5% Core	1428 MB	1450 MB
Nur Agent	3% Core	275 MB	275 MB

Auf einem Raspberry Pi 4: Server + Workload verbraucht ~30% Core, ~1600 MB RAM. Nur Agent: ~10% Core, ~268 MB.

Die IOPS-Anforderungen an den Datastore sind moderat — SQLite benötigt 10 IOPS / <10ms Latenz; embedded etcd benötigt 50 IOPS / <5ms Latenz.

Bekannte Probleme & Fallstricke

1. etcd Startup-Loop bei Skalierung (k3s#14130): Bei ~2500 Nodes wird clearAlarms() durch etcd unter Schreibdruck (>83 Writes/Sek) rate-limited, was zu unendlichen Neustart-Schleifen führt.

2. kubelet Sandbox Regression (k3s#14078): In v1.36.0 läuft RunPodSandbox aufgrund eines gRPC-Modul-Versions-Updates in einen Timeout. Workaround: Fixierung auf v1.35.x.

3. Crash-Loop bei fehlender Default-Route (k3s#13895): Wenn k3s startet, bevor eine Standard-Netzwerkroute existiert, tritt es in eine 5-sekündige Neustart-Schleife bei 100% CPU-Last ein. Lösung: systemd Drop-in mit StartLimitBurst=3 und RestartSec=30s.

4. Pod-to-apiserver Timeout auf demselben Node (k3s#13721): Traffic zu 10.43.0.1 (kubernetes service) läuft intermittierend in einen Timeout aufgrund der Load-Balancer-Logik von k3s — SYN erreicht cni0, aber es erfolgt kein ACK.

5. SD-Karten-Verschleiß auf ARM: etcd ist schreibintensiv. Verwenden Sie für Raspberry Pi-Cluster immer eine externe SSD.

Best Practices für die Produktion

1. Mindestens 3 Server-Nodes für das HA-Quorum
2. Schnelle SSDs verwenden (NVMe bevorzugt) für /var/lib/rancher/k3s/server/
3. Datastore-IOPS vom Workload-Speicher isolieren
4. Einen Load Balancer (HAProxy) vor die Server-Nodes schalten
5. Externen Datastore verwenden für Cluster mit mehr als 50 Nodes
6. etcd-Latenz überwachen — kritisch für die Gesundheit der Control Plane
7. --disable-network-policy setzen, wenn Calico oder Cilium verwendet werden
8. Für Cilium: virtuelle Interfaces vor der k3s-Deinstallation bereinigen
9. Für Rook-Ceph: csi.kubeletDirPath immer mit /var/lib/rancher/k3s/agent/kubelet überschreiben

Weave Net ist tot

Weave Net war die vierte große Option, ist aber faktisch archiviert. Weaveworks hat den Betrieb eingestellt, Kubespray hat die Weave-Unterstützung im Jahr 2025 entfernt und die Wartung wurde an einen Community-Fork übergeben. Verwenden Sie Weave nicht für neue Cluster.

Entscheidungsrahmen

Anforderung	Beste Wahl
Schneller Dev-Cluster	k3d (lokal) oder k3sup (remote)
Edge / IoT Produktion	k3s official + Flannel + Longhorn
HA Produktion (<50 Nodes)	k3s + embedded etcd + Cilium (oder Calico eBPF)
Große Produktion (>50 Nodes)	k3s + external PostgreSQL + Cilium
NetworkPolicy-Erzwingung nötig	Cilium (eBPF, beste Perf.) oder Calico (reif, stabil)
Maximaler Durchsatz	Cilium (9,2 Gbps, eBPF-native)
Einfacher Ingress	Traefik (Standard, integriertes ACME)
Bewährter Ingress bei Scale	Nginx NIC (F5, Migration von community ingress-nginx)
Block-Speicher (<20 Nodes)	Longhorn
Enterprise-Speicher (RWX, groß)	Rook-Ceph
Multi-Cloud-Management	AutoK3s

Zusammenfassung

Das k3s-Ökosystem bietet auf jeder Ebene Auswahlmöglichkeiten. Das Standard-Setup (Flannel + Traefik + Local Path) funktioniert gut für Single-Node- und Edge-Deployments, aber sobald Sie NetworkPolicy-Erzwingung, HA oder Produktionsperformance benötigen, müssen Sie Komponenten austauschen.

Wichtige Erkenntnisse:

• Flannel erzwingt keine NetworkPolicies — k3s liefert einen kube-router-basierten Controller mit, um diese Lücke zu schließen, aber wenn Sie diesen deaktivieren, werden Policies stillschweigend ignoriert
• Cilium bietet die beste Performance und die tiefste Policy-Unterstützung (L3-L7) auf Kosten von Kernel-Anforderungen und Speicher
• Calico ist das am meisten praxiserprobte CNI mit Optionen für sowohl iptables als auch eBPF Data Planes
• Embedded etcd ist für Cluster bis zu ca. 50 Nodes ausreichend; darüber hinaus sollte ein externer Datastore verwendet werden
• Traefik ist für die meisten k3s-Deployments angemessen und erspart die Wartung eines zweiten Ingress-Controllers

Die richtige Wahl hängt von Ihrer Skalierung, Ihren Performance-Anforderungen und davon ab, wie viel Kontrolle auf Kernel-Ebene Sie benötigen — aber in jedem Fall sollten Sie die NetworkPolicy-Erzwingung explizit überprüfen. Gehen Sie nicht davon aus, dass sie funktioniert, nur weil Sie ein NetworkPolicy-Objekt erstellt haben.

Querverweise

• Kubernetes GitOps mit ArgoCD — deklaratives Management von k3s-Clustern
• Container-Orchestrierung — Vergleich von Orchestrierungsansätzen jenseits von k3s
• Leitfaden zum Erstellen und Härten von Containern — sichere Images für Ihre Cluster-Workloads
• Kubernetes Gateway API Migration — Next-Generation Ingress für Kubernetes
• CNCF Cloud Native Landscape — wo k3s im Ökosystem angesiedelt ist