Host Network

Docker: docker run --network host nginx Versuche mal, zwei davon zu starten. Der zweite wird crashen: "Address already in use". Warum? Weil Port 80 auf dem Host nur einmal existiert. Bei Bridge-Netzwerken ginge das (jeder Container hat eigene IP).

Kubernetes:

spec:
  hostNetwork: true

Oft genutzt für Ingress Controller (Nginx), die direkten Zugriff auf "echtes" Internet brauchen für Performance.

1. Performance (Zero NAT)

Im normalen Bridge-Mode muss jedes Paket durch NAT (Network Address Translation) und iptables ("Masquerading"). Das kostet CPU und Latenz (wenige Mikrosekunden, aber messbar). Bei High-Frequency-Trading oder VoIP (RTP) zählt jedes Bit. Host Network = 0% Overhead. Das Paket geht von der Netzwerkkarte direkt in den Prozess. Daher nutzen Loadbalancers (HAProxy, Traefik) oft Host Network.

2. Security Risiken

Wenn hostNetwork: true gesetzt ist, kann der Container den gesamten Traffic des Hosts mitschneiden (tcpdump). Er sieht auch Traffic von anderen Containern. Zusätzlich: Wenn der Container als Root läuft, kann er Netzwerkeinstellungen des Hosts ändern (Firewall löschen!). In Kubernetes Standards (Pod Security Standards) ist HostNetwork oft verboten ("Baseline/Restricted Policy").

3. CNI Bypass

In Kubernetes umgeht HostNetwork das CNI-Plugin (Calico/Flannel). Das heißt: Network Policies ("DB darf nur von App erreicht werden") greifen NICHT mehr! Der Pod ist "nackt" im Node-Netzwerk. Das wird oft von Angreifern genutzt, um aus einem gehackten Pod auszubrechen und das Cluster-Netzwerk zu scannen.

Net-Namespace Injection & pause Container

Technisch gesehen löst --network host den Container nicht auf, sondern teilt den Linux "Network Namespace" des Hosts. Dieses Prinzip ist in Kubernetes die absolute Basis-Architektur, nur minimal abgewandelt. In Kubernetes teilt nicht der Docker-Host seinen Namespace, sondern ein Pod erschafft einen Master-Namespace (den sogenannten dummen Pause Container), und alle anderen App-Container in diesem Pod injizieren sich in diesen einen "Host-Namespace" des Pods. Deshalb können zwei Container im selben Pod per localhost direkt miteinander reden, genau wie zwei Prozesse auf einem Server, die --network host nutzen.

The Port Exhaustion Threat (Ephermal Ports)

Wenn Loadbalancer (wie Nginx Ingress) auf Bare-Metal-Kubernetes Nodes im HostNetwork Modus gestartet werden, um NAT-Overhead abzuschütteln, lauern TCP-Fallen. Der Linux Kernel hat nur ~65.000 Ports zur Verfügung. Für abgehende Verbindungen zum Upstream-Backend-Pod nutzt der Ingress einen zufälligen hohen Port (Ephemeral Port). Bei 20.000 Requests/Sekunde und TIME_WAIT-Sockets, die 60 Sekunden blockiert bleiben, geht dem Linux-Host das Port-Kontingent physisch aus (Cannot assign requested address). Wäre der Controller im Bridge-Routing, hätte jeder Pod seine isolierten 65k Ports. Im Host-Network teilen sich alle Instanzen die Limits des einzigen Host-Kernels. Es muss extremes Kernel-Tuning (sysctl net.ipv4.tcp_tw_reuse) vorgenommen werden.

eBPF, Cilium und Host-Routing (Das Ende von HostNetwork?)

In hochmodernen K8s-Umgebungen (Cilium) ist --network host aus Performance-Sicht oft veraltet. Früher war der Overhead durch iptables/NAT massiv (da lineare Abarbeitung der Firewall-Rules den O(n) Algorithmus blockierte). Heute lädt Cilium via eBPF (Extended Berkeley Packet Filter) winzige Go/C-Programme direkt in den Highspeed-Pfad (XDP) des Kernels. Cilium fängt Pakete von der physikalischen Netzwerkkarte ab und schleust sie ohne jegliches iptables-Routing in die Memory-Strukturen der Pod-Isolations-Namespaces. Man behält exzellente Isolation (Sicherheit) bei praktisch Bare-Metal Latenzen, was die Gefahr von hostNetwork obsolet macht.