# Kubernetes Networking: Architektur, CNI & Service-Kommunikation

TL;DR / Management Summary Kubernetes (K8s) Networking basiert auf dem Prinzip der flachen Konnektivität: Jeder Pod hat eine eigene IP und muss jeden anderen Pod im Cluster erreichen können, ohne NAT. In Proxmox-Umgebungen betreiben wir K8s meist in VMs und nutzen CNI (Container Network Interface) Plugins wie Calico oder Cilium, um die Kommunikation zu isolieren. Ein Senior Admin beherrscht die Konzepte von Services (ClusterIP/NodePort) und Ingress, um Dienste sicher ins LAN oder Internet zu publizieren.

# 1. Die Hierarchie des K8s Networking

Vom Pod zur Welt.

  1. Container-to-Container: Kommunikation via localhost (teilen sich den Network-Namespace im gleichen Pod).
  2. Pod-to-Pod: Kommunikation über das Cluster-Netzwerk (z.B. Overlay-Netz).
  3. Pod-to-Service: Abstraktion einer Gruppe von Pods über eine stabile VIP.
  4. External-to-Service: Zugriff von außerhalb des Clusters (via Loadbalancer oder Ingress).

# 2. CNI (Container Network Interface) Plugins

Der Kleber zwischen den Containern.

Das CNI-Plugin ist verantwortlich für die Vergabe von IPs und das Routing.

# 3. Deep Dive: Services & Load Balancing

Wie man Pods findet.

Da Pods kurzlebig sind, brauchen wir stabile Endpunkte:

# 4. Day-2 Operations: Ingress Controller

Der Layer-7 Türsteher.

Anstatt für jeden Dienst eine IP zu verbrauchen, nutzen wir einen Ingress Controller (z.B. Nginx oder Traefik).

# 5. Troubleshooting & “War Stories”

Wenn die Pods sich nicht finden.

# Top 3 Fehlerbilder

  1. Symptom: “Connection Timeout” zwischen Pods auf verschiedenen Knoten.

    • Ursache: Das CNI-Overlay (VXLAN) wird von der physischen OPNsense oder Proxmox Firewall blockiert.
    • Lösung: Port UDP 4789 (VXLAN) am Host erlauben.

  2. Symptom: DNS-Auflösung (my-service.default.svc.cluster.local) schlägt fehl.

    • Ursache: CoreDNS-Pod ist abgestürzt oder überlastet.
    • Fix: CPU-Limits für den CoreDNS-Deployment anpassen.

  3. Symptom: Loadbalancer-Service bleibt im Status <pending>.

    • Fix: Installieren Sie MetalLB und definieren Sie einen IP-Adresspool aus Ihrem LAN (Artikel 725).

# “War Story”: Der “ARP-Sturm” durch MetalLB

Ein Admin konfigurierte MetalLB im Layer-2 Modus auf einem Proxmox-Cluster. Das Ereignis: Plötzlich war der gesamte Core-Switch blockiert. Die Ursache: Da MetalLB die IP-Übernahme via ARP-Spoofing (Gratuitous ARP) simuliert, lösten 50 neue Services gleichzeitig tausende ARP-Pakete aus. Der Switch sah dies als Angriff und schaltete die Ports in den Error-Disabled State. Lehre: Nutzen Sie für produktive K8s-Cluster im LAN den BGP-Modus von MetalLB. Es ist deutlich stabiler und wird von Enterprise-Switchen (und OPNsense FRR) nativ unterstützt.

# 6. Monitoring & Reporting

Cluster-Observability.

# Prometheus & Metrics Server

Installieren Sie den kube-state-metrics Agenten.

# 7. Fazit & Empfehlung

Kubernetes Networking ist komplex, aber logisch aufgebaut.

# Anhang: Cheatsheet (kubectl net)

Aufgabe Befehl
Pod IPs sehen kubectl get pods -o wide
Services listen kubectl get svc
Network Policies kubectl describe netpol
DNS Test kubectl run -it --rm debug --image=busybox -- nslookup google.com

# Referenzen