Zum Inhalt

Container-Netzwerke & CNI-Architektur: Docker, Rootless Podman, Flannel & Cilium

Erstellt: 08.11.2026  ·  Zuletzt aktualisiert: 08.11.2026  ·  Nejat Hakan

Management Summary: Moderne Cloud-Native-Architekturen basieren auf Containern, die tausende Microservices über verteilte Linux-Cluster hinweg ausführen. Unterhalb von Container-Runtimes (Docker, Podman) und Orchestrierern (Kubernetes) wird das Netzwerk jedoch nicht von monolithischen Daemons verwaltet, sondern von modularen Container Network Interface (CNI) Plugins. Dieser Leitfaden schlägt die Brücke zwischen Linux-Kernel-Virtualisierung und moderner Cloud-Welt: Vom Docker-Bridge DNAT-Port-Publishing über Rootless Podman (pasta vs. slirp4netns) bis hin zum CNI-Ausführungsmodell und Kubernetes-Multi-Host-Overlays (Flannel VXLAN vs. Cilium eBPF).

  • Docker Bridge & DNAT

    docker0 entmystifizieren: Wie Port-Mappings (-p 8080:80) in Netfilter-DNAT-Regeln und docker-proxy-Prozesse übersetzt werden.

  • Rootless Podman: pasta

    Unprivilegierte Container verstehen: Der Umstieg vom alten, CPU-lastigen slirp4netns auf das moderne Zero-Copy pasta-User-Mode-Networking.

  • Die CNI-Spezifikation

    Wie Kubernetes und Podman standardisierte CNI-Binärdateien über Umgebungsvariablen (ADD, DEL) und JSON-Pipes aufrufen.

  • Flannel VXLAN vs. Cilium eBPF

    Flache Kubernetes-Netzwerke im Vergleich: Klassische 50-Byte VXLAN-Overlay-Kapselung versus Netfilter-Bypass mit eBPF im Kernel.

1. Single-Host Container-Netzwerke: Das Docker-Bridge-Modell

Beim Start von Docker auf einem Debian-Host wird automatisch eine virtuelle Bridge namens docker0 mit einem privaten Subnetz angelegt (meist 172.17.0.1/16).

%%{init: {'flowchart': {'wrappingWidth': 350}}}%%
flowchart TB
    WAN["Externer Client<br/>198.51.100.25"] -->|"Anfrage an Host :8080"| ETH0["Host Physische NIC: eth0"]
    ETH0 --> PREROUTING["Netfilter PREROUTING<br/>DNAT-Regel"]
    PREROUTING -->|"Ziel wird 172.17.0.2:80"| BR["Bridge: docker0<br/>Gateway: 172.17.0.1/16"]
    BR --> VETH["veth-Paar Patchkabel"]
    VETH --> CONT["Container NetNS<br/>172.17.0.2:80"]

Die Funktionsweise von Port-Mappings (-p 8080:80)

Wird ein Container mit docker run -p 8080:80 nginx gestartet, greifen zwei Mechanismen: 1. Netfilter / iptables DNAT-Regel: In der PREROUTING-Kette wird eine Regel hinterlegt, die eingehende Pakete auf Port 8080 an die interne IP des Containers (172.17.0.2:80) umschreibt. 2. docker-proxy User-Space Prozess: Ein kleiner Hilfsprozess lauscht auf 0.0.0.0:8080, um Anfragen von localhost:8080 weiterzuleiten (da lokaler Loopback-Verkehr die PREROUTING-NAT-Kette des Kernels umgeht).

2. Rootless Container: Von slirp4netns zu pasta

Container ohne Root-Rechte auszuführen (Rootless Podman) ist eine fundamentale Sicherheitsbest practice. Bricht ein Angreifer aus dem Container aus, besitzt er auf dem Host lediglich unprivilegierte Benutzerrechte.

Das Problem: Ein normaler Benutzer darf im Linux-Kernel weder Bridges noch veth-Paare anlegen oder Routing-Tabellen verändern.

%%{init: {'flowchart': {'wrappingWidth': 350}}}%%
flowchart TB
    subgraph SLIRP ["Veraltet: slirp4netns (Hohe CPU)"]
        direction TB
        S_APP["Container"] <-->|"TAP-Device"| S_DAEMON["slirp4netns Prozess<br/>User-Space TCP/IP"]
        S_DAEMON <-->|"POSIX Sockets"| S_HOST["Host Netzwerk"]
    end
    subgraph PASTA ["Modern: pasta (passt Projekt)"]
        direction TB
        P_APP["Container NetNS"] <-->|"Speicherzuordnung"| P_DAEMON["pasta Prozess<br/>Zero-Copy Forwarding"]
        P_DAEMON <-->|"Host Interface"| P_HOST["Host Netzwerk"]
    end

    SLIRP -->|"Ersetzt durch"| PASTA

Die Treiber im Vergleich

  • slirp4netns (Alt): Emuliert einen kompletten TCP/IP-Stack im User-Space. Jedes Paket muss entpackt, geprüft und in neue Socket-Aufrufe gewandelt werden – das kostet CPU-Leistung und erhöht die Latenz.
  • pasta (Pack A Subtle Tap Abstraction – Neuer Standard): Entwickelt im Rahmen des passt-Projekts. Statt einen Netzwerkstack zu emulieren, mappt pasta Layer-4-TCP/UDP-Sockets zwischen dem Container-Namespace und dem Host direkt über Shared Memory und UNIX-Sockets – fast ohne Latenzverlust.
# Aktiven Rootless-Netzwerktreiber in Podman prüfen
podman info | grep -i networkBackend

3. Die CNI-Spezifikation (Container Network Interface)

Das von der Cloud Native Computing Foundation (CNCF) gepflegte CNI ist eine minimalistische, programmiersprachen-unabhängige Spezifikation zwischen Container-Orchestrierern (Kubernetes kubelet, Podman, CRI-O) und Netzwerk-Treibern.

Wie ein Orchestrierer CNI aufruft

Ein CNI-Plugin ist kein dauerhaft laufender Daemon, sondern eine ausführbare Binärdatei (üblicherweise unter /opt/cni/bin/). Wenn ein Pod startet, ruft der Orchestrierer das Plugin direkt auf:

%%{init: {'flowchart': {'wrappingWidth': 350}}}%%
flowchart TB
    KUBELET["Orchestrator<br/>kubelet / Podman"] -->|"1. Startet Binärdatei mit ENV:<br/>CNI_COMMAND=ADD"| CNI_BIN["CNI-Plugin<br/>bridge / flannel"]
    KUBELET -->|"2. JSON-Config via STDIN"| CNI_BIN
    CNI_BIN -->|"3. veth, Bridge, IP"| KERNEL["Linux Kernel"]
    CNI_BIN -->|"4. JSON-Ergebnis STDOUT"| KUBELET

Die 4 zentralen CNI-Befehle

  • ADD: Weist dem Container eine Schnittstelle zu, vergibt eine IP und setzt Standardrouten.
  • DEL: Gibt IPs frei und baut Schnittstellen ab, wenn der Container gestoppt wird.
  • CHECK: Überprüft, ob das Netzwerk dem Soll-Zustand entspricht.
  • VERSION: Meldet unterstützte CNI-Spezifikationsversionen.

Beispiel einer CNI-Konfigurationsdatei (/etc/cni/net.d/10-mynet.conflist)

{
  "cniVersion": "1.0.0",
  "name": "produktion-bridge",
  "plugins": [
    {
      "type": "bridge",
      "bridge": "cni0",
      "isGateway": true,
      "ipMasq": true,
      "ipam": {
        "type": "host-local",
        "subnet": "10.244.1.0/24",
        "routes": [{ "dst": "0.0.0.0/0" }]
      }
    },
    {
      "type": "portmap",
      "capabilities": { "portMappings": true }
    }
  ]
}

4. Die Grundgesetze des Kubernetes-Netzwerks

Jeder Kubernetes-Cluster muss drei elementare Vorgaben erfüllen: 1. Jeder Pod kann mit jedem anderen Pod kommunizieren – über alle Node-Grenzen hinweg, vollständig ohne Network Address Translation (NAT). 2. Jeder Node kann mit allen Pods kommunizieren (und umgekehrt), ebenfalls ohne NAT. 3. Die IP-Adresse, die ein Pod an sich selbst sieht, ist exakt dieselbe IP, unter der alle anderen Pods ihn erreichen.

5. Overlay-Netzwerke (Flannel) vs. Direct eBPF Routing (Cilium)

Um Pods über mehrere physische Hosts hinweg zu vernetzen, ohne die Hardware-Router des Rechenzentrums per BGP umkonfigurieren zu müssen, verfolgen CNI-Plugins zwei Ansätze:

%%{init: {'flowchart': {'wrappingWidth': 350}}}%%
flowchart TB
    subgraph OVERLAY ["Ansatz A: VXLAN Overlay (Flannel)"]
        direction TB
        P1["Pod A (10.244.1.15)"] -->|"Innerer Ethernet-Frame"| V1["veth-Device"]
        V1 -->|"UDP-Port 4789"| VXLAN["Host eth0 (Netz)"]
        VXLAN -->|"Entkapselt auf Node B"| P2["Pod B (10.244.2.20)"]
    end

    subgraph EBPF ["Ansatz B: In-Kernel eBPF (Cilium)"]
        direction TB
        CP1["Pod A (10.244.1.15)"] -->|"Direkte eBPF XDP/tc Steuerung"| CP2["Pod B (10.244.2.20)"]
        CP2 --- NOTE["Keine Header-Kapselung<br/>Umgeht conntrack"]
    end

    OVERLAY -->|"eBPF-Revolution"| EBPF

1. Flannel (Der klassische VXLAN-Overlay)

  • Funktionsweise: Nutzt das VXLAN-Modul (Virtual Extensible LAN) des Linux-Kernels. Sendet Pod A auf Node 1 Daten an Pod B auf Node 2, verpackt der Kernel den inneren Ethernet-Frame in ein äußeres UDP-Paket auf Port 4789.
  • Vorteile: Läuft überall sofort ohne Konfiguration der physischen Switche.
  • Nachteile: 50 Byte Header-Overhead senken die effektive MTU (auf 1450 statt 1500), und die CPU muss Pakete ver- und entpacken.

2. Cilium (Der moderne eBPF-Hochleistungs-Standard)

  • Funktionsweise: Ersetzt iptables und kube-proxy vollständig durch Extended Berkeley Packet Filter (eBPF) Programme direkt an den tc- und XDP-Hooks des Kernels.
  • Vorteile:
  • Line-Rate Performance: Pakete werden direkt zwischen Netzwerkkarten und Sockets geroutet, ohne Netfilter-Ketten zu durchlaufen.
  • Skalierbarkeit: Bewältigt problemlos 100.000+ Services, an denen iptables-Regeltabellen scheitern.
  • Transparente Sicherheit: Integriertes Layer-7-API-Filtering, Hubble-Netzwerktopologie-Monitoring und automatische WireGuard-Verschlüsselung im Transit.

6. Diagnose von Container-Netzwerken

Prüfe die von Container-Engines angelegten virtuellen Schnittstellen:

# 1. Netzwerk-Namespace eines laufenden Containers ermitteln
podman inspect my-web-container -f '{{.NetworkSettings.SandboxKey}}'

# 2. Aktive CNI-Bridges und verbundene veth-Interfaces anzeigen
ip -br link show type bridge
bridge link show

# 3. Automatische Container-NAT-Regeln inspizieren
sudo iptables -t nat -S DOCKER 2>/dev/null || sudo nft list table ip container_nat

7. Nächste Schritte: Wechsel zu Cluster 4

Herzlichen Glückwunsch! Du hast Cluster 3: Enterprise Routing & Virtualisierung vollständig abgeschlossen. Du beherrschst alle Kernel-Bausteine vom L3-Routing und VLANs bis hin zu Container-Fabrics und modernen CNI-Overlays.

Nun führen wir all dieses Wissen in einem großen, praxiserprobten Capstone-Projekt zusammen:

  • Cluster 4: KVM/QEMU Enterprise Netzwerk-Simulationslabor

    Baue eine komplette Multi-Zonen-Unternehmensinfrastruktur auf Debian auf: KVM/libvirt, pfSense Perimeter-Firewalls, BIND9 DNS und DMZ Nginx Server.

    Zum KVM/QEMU Labor-Leitfaden