Kubernetes Netzwerk in der Praxis

1. Das Netzwerkmodell von Kubernetes

Kubernetes wirkt auf den ersten Blick simpel: Pods reden miteinander, Services verteilen Last und ein Ingress macht Anwendungen von außen erreichbar. In der Praxis steckt dahinter aber ein klares Modell, das verstanden werden muss, bevor man CNIs, Policies oder Load Balancer sinnvoll auswählt.

  • Jeder Pod erhält eine eigene IP-Adresse.
  • Pods sollen ohne NAT direkt miteinander kommunizieren können.
  • Nodes müssen den Pod-Adressraum der anderen Nodes erreichen können.
  • Services abstrahieren wechselnde Pod-Endpunkte über virtuelle Adressen oder DNS-Namen.

Genau an diesen Punkten entscheidet sich, ob ein Cluster stabil wirkt oder sich wie eine Sammlung zufälliger Overlay-Tunnel anfühlt. Wer das Netzwerkmodell ignoriert, wird spätestens bei Debugging, Policies oder Multi-Node-Problemen unnötig Zeit verlieren.

2. CNI-Auswahl: Calico, Flannel, Cilium und Co.

Die Container Network Interface (CNI) ist nicht bloß "das Paket für Netzwerk". Sie bestimmt, wie Pod-Adressen verteilt werden, ob ein Overlay zum Einsatz kommt, wie Policies funktionieren und welche Diagnosewerkzeuge sinnvoll sind.

  • Flannel: einfach, robust und gut für kleine Labs. Fokus auf Konnektivität, nicht auf feine Policies.
  • Calico: sehr verbreitet, unterstützt Routing ohne Overlay oder mit Overlay und bietet starke Network-Policy-Funktionen.
  • Cilium: eBPF-basiert, leistungsfähig und modern, aber konzeptionell anspruchsvoller.

Für ein kleines Homelab ist Flannel ein guter Start, wenn man erst einmal Multi-Node-Konnektivität verstehen will. Sobald Policy, tiefere Segmentierung oder spätere Erweiterungen wichtig werden, ist Calico oft der pragmatischste Mittelweg.

Unabhängig vom Produkt müssen drei CIDR-Räume sauber geplant werden:

  • Node-Netz: physisches oder virtuelles Netz der Cluster-Nodes.
  • Pod-CIDR: Adressraum für Workloads, zum Beispiel 10.244.0.0/16.
  • Service-CIDR: virtuelle Service-Adressen, zum Beispiel 10.96.0.0/12.

3. Services, kube-proxy und externer Zugriff

Ein Pod ist flüchtig. Services schaffen Stabilität, indem sie Anfragen an eine Gruppe wechselnder Pods verteilen. Ohne sauberes Verständnis der Service-Typen wirkt das Verhalten oft widersprüchlich.

  • ClusterIP: nur intern im Cluster erreichbar; Standard für die meisten Backend-Dienste.
  • NodePort: öffnet einen Port auf jedem Node; hilfreich für Labs, aber selten die eleganteste Dauerlösung.
  • LoadBalancer: integriert Kubernetes mit einem externen Load Balancer oder mit Projekten wie MetalLB.
  • Headless Service: kein virtuelles VIP, sondern direkte DNS-Auflösung auf Pod-Endpunkte.

In kleineren Bare-Metal- oder Homelab-Setups ist MetalLB oft der einfachste Weg, um echte LoadBalancer-IPs im LAN zu erhalten. Ein typischer Layer-2-Pool sieht so aus: 

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: lan-pool
  namespace: metallb-system
spec:
  addresses:
    - 192.168.10.240-192.168.10.250

Danach kann ein Service vom Typ LoadBalancer eine Adresse aus diesem Pool erhalten. Das ist für interne Anwendungen meist sauberer als eine Sammlung willkürlicher NodePorts.

4. Ingress, LoadBalancer und Gateway-Muster

Externer Zugriff auf HTTP- und HTTPS-Anwendungen sollte nicht pro App neu erfunden werden. Besser ist ein gemeinsamer Einstiegspunkt mit TLS, Logging und klaren Hostnamen. Dafür wird meist ein Ingress Controller wie NGINX Ingress oder Traefik eingesetzt.

Ein einfaches Ingress-Beispiel: 

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
spec:
  ingressClassName: nginx
  rules:
    - host: app.lab.example
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: app-service
                port:
                  number: 80

Für TLS und Zertifikate wird häufig cert-manager ergänzt. Wer nur intern arbeitet, kann interne ACME- oder PKI-Workflows nutzen. Für neue Designs lohnt auch ein Blick auf die Gateway API, die klarere Rollen zwischen Infrastruktur und Anwendung schafft. Im Alltag dominiert aber Ingress weiterhin viele Cluster, gerade in kleinen Umgebungen.

5. Network Policies und Segmentierung

Ohne Policies können Pods in vielen Clustern standardmäßig frei miteinander sprechen. Das ist bequem für den Start, aber schlecht für Sicherheit, Fehlersuche und Mandantentrennung. Ein realistischer Standard lautet: Default Deny pro Namespace, dann gezielte Freigaben.

Beispiel für eine einfache Default-Deny-Policy: 

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

Danach müssen DNS, Ingress, Metriken oder Datenbankpfade explizit erlaubt werden. Das klingt aufwendiger, verhindert aber viele Überraschungen. Entscheidend ist, dass die verwendete CNI Policies wirklich durchsetzt. Flannel allein reicht dafür beispielsweise nicht aus.

6. Betrieb im Homelab und in kleinen Clustern

Kleine Cluster haben andere Prioritäten als große Plattformen: einfache Diagnose, wenig bewegliche Teile und klare Verantwortlichkeiten. Ein solides Setup für Homelab oder KMU kann so aussehen:

  • 3 Control-Plane- oder gemischte Nodes, falls Hochverfügbarkeit relevant ist,
  • Calico oder Flannel als verständliche CNI,
  • MetalLB für Bare-Metal-LoadBalancer,
  • ein Ingress Controller für alle HTTP/S-Anwendungen,
  • Prometheus und Loki oder ein anderes Logging/Monitoring-Setup von Anfang an.

Besonders wichtig ist die Abgrenzung zwischen Cluster-Netz und Heimnetz. Wer Nodes, Hypervisor und Applikations-VIPs unkontrolliert in dasselbe Segment wirft, erschwert spätere Sicherheitsregeln und verliert schnell den Überblick über echte Verkehrsflüsse.

7. Troubleshooting

Kubernetes-Netzwerkprobleme lassen sich fast immer auf eine von vier Ebenen eingrenzen: Pod zu Pod, Pod zu Service, Service zu Backend oder externer Zugriff über Ingress/LoadBalancer. Wer diese Ebenen getrennt testet, findet Fehler deutlich schneller.

  1. Pod-IP und Node-Zuordnung prüfen.
  2. Service, Endpoints und EndpointSlices kontrollieren.
  3. DNS im Cluster testen.
  4. CNI- oder Policy-spezifische Logs ansehen.
  5. Erst danach Ingress, TLS oder externe Firewalls prüfen.
kubectl get pods -A -o wide
kubectl get svc -A
kubectl get endpointslices -A
kubectl describe networkpolicy -A
kubectl exec -it deploy/app -- sh
kubectl logs -n kube-system ds/calico-node
sudo tcpdump -ni any host 10.244.1.7

Typische Fehlerbilder:

  • Pod läuft, Service antwortet nicht: Selector falsch oder keine Endpoints vorhanden.
  • DNS im Pod kaputt: CoreDNS, egress-Policy oder CNI-Fehler.
  • Ingress existiert, aber keine externe Antwort: Ingress Controller, TLS-Secret oder LoadBalancer-IP prüfen.
  • Nur manche Namespaces betroffen: meist Policy oder Namespace-spezifische DNS/Service-Fehler.

8. Zusammenfassung

Kubernetes-Netzwerk wird beherrschbar, wenn man es nicht als Black Box behandelt: Pod-CIDR, Service-CIDR, CNI, Service-Typen und Policies müssen als zusammenhängendes System verstanden werden.

Für kleine Cluster ist weniger oft mehr. Eine verständliche CNI, ein sauberer Ingress-Pfad, echte Segmentierung per Policy und reproduzierbares Troubleshooting bringen mehr Stabilität als ein zu früh maximal komplexes Setup.