K3s-Distributionen im Vergleich: Flannel, Calico, Cilium â CNI-Performance und die RealitĂ€t der NetworkPolicy
đŹđ§ Read in English~12 min read
DevOpsKubernetesk3skubernetescniflannelcalicociliumnetworkpolicyedge-computing
Back openDesk Edu for a sovereign, open-source education â every vote counts.
Vote nowSave products you love by clicking the heart icon.
A deep technical comparison of NetworkPolicy enforcement between eBPF-based CNIs (Cilium) and iptables-based CNIs (Calico). Covers implementation internals, real performance benchmarks at scale, L7 policy trade-offs, migration strategies, and production debugging patterns.
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.
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 |
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.
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.
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.
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.
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 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):
NetworkPolicy-UnterstĂŒtzung: â Mit k3s' integriertem Controller, â Flannel allein
Dies ist die kritische Unterscheidung, die die meisten Nutzer ĂŒberrascht.
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 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):
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 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.
| 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 |
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.
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
| 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 |
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
Wenn Policies erzwungen werden, hÀngt die Performance von der CNI-Data-Plane ab:
K3s macht den Austausch von CNIs unkompliziert. Aus der offiziellen Dokumentation:
Starten Sie K3s mit
--flannel-backend=noneund installieren Sie die CNI Ihrer Wahl. Die meisten CNI-Plugins bringen ihre eigene Network-Policy-Engine mit, daher wird empfohlen, auch--disable-network-policyzu setzen, um Konflikte zu vermeiden.
# 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
# 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
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.
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.
| 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 |
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.
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.
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.
| 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 |
| 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 |
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.
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.
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.
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.
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.
SD-Karten-VerschleiĂ auf ARM: etcd ist schreibintensiv. Verwenden Sie fĂŒr Raspberry Pi-Cluster immer eine externe SSD.
/var/lib/rancher/k3s/server/--disable-network-policy setzen, wenn Calico oder Cilium verwendet werdencsi.kubeletDirPath immer mit /var/lib/rancher/k3s/agent/kubelet ĂŒberschreibenWeave 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.
| 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 |
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:
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.