Netzwerk-Grundlagen für DevOps & Kubernetes: die Fundamente, die jeder beherrschen muss

TL;DR

• Networking ist die am häufigsten übersprungene Grundlage in DevOps, Cloud und Kubernetes — und genau deshalb die Ursache der meisten Produktionsprobleme.
• Die gute Nachricht: Die Basics sind gleich geblieben, von der physischen Server-Ära bis zu Kubernetes:
  • Alles braucht eine Adresse (IP).
  • Regeln kontrollieren den Traffic (Firewalls, Security Groups, Network Policies).
  • Namen lösen sich zu Adressen auf (DNS, Service Discovery).
  • Traffic braucht Routen (Routing-Tabellen).
• Kubernetes-Networking hat vier Säulen: Pod + CNI, Service, DNS, Ingress — plus Network Policies als Sicherheitsguards.
• Ohne Network Policies ist Ihr Cluster per Default offen — jeder Pod kann jeden Pod erreichen.

Warum Networking die wichtigste Grundlage ist

Wer IP, DNS, Ports und Routing nicht versteht, troubleshootet stundenlang an Symptomen statt Ursachen. Das gilt für einen einzelnen Server genauso wie für einen Kubernetes-Cluster. Dieser Artikel zeigt die Networking-Evolution an einem praktischen Beispiel — einer E-Commerce-Plattform, die vom einzelnen Server zur modernen Cloud-Architektur wächst:

Jede Abstraktionsschicht fügt mächtige Fähigkeiten hinzu — aber auch Komplexität. Wer die Grundbausteine versteht, navigiert diese Komplexität souverän.

Phase 1: Die Grundbausteine (physischer Server)

Die Haus-Analogie

• IP-Adresse = Straßenadresse: Netzteil (Straße) + Hostteil (Hausnummer). Jedes Gerät braucht eine eindeutige Adresse.
• Router / Default Gateway = Postfiliale: leitet Daten zwischen Netzen weiter (anhand des Netz-Teils der IP).
• DNS = Telefonbuch des Internets: übersetzt shopeasy.com in die IP. Ändert sich die IP, bleibt der Name gleich.
• Netzwerk-Interface (eth0) = Haustür: der Eingang für allen Traffic.
• Ports = Räume im Haus: Web-App (80/443), Datenbank (3306/5432), etc. Das OS (Hausverwalter) verteilt die Pakete an die richtigen Räume.

Warum ein einzelner Server scheitert

• Kein Failover: Server-Crash = Business down.
• Keine Skalierung: Spitzenlast = Warteschlangen.
• Fixe Kosten: Teuer auch bei null Nutzung.
• Downtime bei Updates: Jede Änderung pausiert die ganze Anwendung.

Phase 2 & 3: VMs und Cloud-Networking

Virtualisierung (Apartment-Haus)

• VM = eigene Wohnung mit eigenem Eingang, eigener Adresse (interne IP wie 10.0.0.5), eigenem OS.
• Hypervisor = Hausverwalter: verteilt Ressourcen, leitet Traffic, hält alles getrennt.
• Vorteile: Isolation (Crash in einer VM trifft andere nicht), bessere Ressourcennutzung, Snapshot-Backups.
• NAT: interne IPs werden beim Verlassen des Hauses in die öffentliche IP übersetzt.
• Firewalls: Sicherheitsguards, die jeden Paketwechsel prüfen.

Cloud (gemietete Wolkenkratzer-Wohnung)

• VPC = privater Flügel im Gebäude, isoliert von anderen Unternehmen.
• Subnets: öffentliche (Storefront, Web-Server) vs. private (Büro, Datenbank) Zonen.
• Security Groups: Sicherheitsguards pro Raum mit strengen Gästelisten.
• Route Tables: das Navigationssystem des Gebäudes.
• NAT Gateway: vertrauenswürdiger Concierge — holt Updates von außen, ohne die private Adresse preiszugeben.

Cloud = einfacher Zugriff auf riesige, fremdverwaltete Server-Mengen. Die Eigentümer (AWS, GCP) betreiben Gebäude, Netzwerk, Security und Upgrades — Sie mieten genau das, was Sie brauchen.

Phase 4: Docker-Networking

• Container sind leichtgewichtige VMs, die den Host-Kernel teilen — nur die Anwendungsschicht wird isoliert (MB statt GB).
• Bridge-Network = privater Flur: Container reden per Namen (DNS) miteinander, ohne IP zu merken.
• Overlay-Network = versiegelte Gänge zwischen Gebäuden (mehreren VMs), für Microservices über Maschinen hinweg.
• Port-Mapping = Rezeptionist: VM-Port 80 → Container-Port 8080, damit die Außenwelt die App erreicht.

Das Problem bei Skalierung: Container manuell zu verwalten wird bei Hunderten unmöglich — das führt direkt zu Kubernetes.

Phase 5: Kubernetes-Networking (der Kern)

Die vier Säulen

Network Policies: Die Türen abschließen

Standardmäßig können sich alle Pods frei erreichen („alle Türen offen"). Network Policies sind die Sicherheitsguards:

• Regeln: „Nur Pods mit Label 'API' dürfen auf die Datenbank (Port 5432). Alle anderen werden blockiert."
• Incoming und Outgoing Traffic steuerbar, basierend auf Labels, Namespaces, Adressen.
• Durchgesetzt via iptables oder CNI-Plugins.

# Default-Deny für die Datenbank — nur API-Pods mit Label "role: api" dürfen rein
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: db-allow-api-only
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: database
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              role: api
      ports:
        - protocol: TCP
          port: 5432

Ohne Network Policies ist Ihr Cluster per Default offen. Genau hier setzt professioneller Betrieb an: Wer Kubernetes produktiv betreibt, definiert und pflegt diese Policies.

Lessons Learned & Risiken (ehrlich)

1. Networking wird übersprungen — und rächt sich: Wer IP, DNS, Ports und Routing nicht versteht, troubleshootet stundenlang an Symptomen.
2. Kubernetes-Networking ist kein Selbstläufer: CNI, Services, Ingress, Policies wollen konfiguriert und gepflegt sein.
3. Security ist Default-offen: Ohne Network Policies ist jeder Pod für jeden Pod erreichbar. Das ist in Produktion nicht akzeptabel.
4. Abstraktion = Komplexität: Jede Schicht (VM, Cloud, Docker, K8s) macht mehr möglich, aber auch mehr zu verstehen.
5. Fehler sind teuer: Ein falsch gerouteter Service oder eine offene Policy kostet Ausfallzeiten und Sicherheit — vermeidbar durch sauberen Betrieb.

Fazit

Networking ist die Grundlage jeder produktiven Plattform — und die häufigste Fehlerquelle:

1. Die vier Grundregeln: Adressen (IP), Regeln (Firewalls/Policies), Namen (DNS), Routen (Routing).
2. Fünf Phasen verstehen: Server → VM → Cloud → Docker → Kubernetes. Jede Schicht baut auf der vorherigen auf.
3. K8s-Networking beherrschen: Pod + CNI, Service, DNS, Ingress.
4. Default-offen schließen: Network Policies sind Pflicht, kein Extra.
5. Zuverlässigkeit statt „läuft irgendwie": Das Fundament entscheidet über die Produktionsreife.

FAQ

Muss ich Networking wirklich selbst tief verstehen? Ja — zumindest die Grundlagen. Sie können nichts reviewen oder troubleshooten, was Sie nicht verstehen. Managed Services nehmen den Betrieb ab, nicht das Verständnis.

Was ist der häufigste Fehler in K8s-Networking? Offene Default-Konfiguration ohne Network Policies und unklare Service-/Ingress-Routen. Beides führt zu Sicherheits- und Zuverlässigkeitsproblemen.

Ist Cloud-Networking anders als Kubernetes? Die Prinzipien sind gleich (Adressen, Regeln, Namen, Routen). Kubernetes abstrahiert sie auf Pod-/Service-Ebene — das Fundament bleibt.

Warum braucht jeder Pod eine eigene IP? Damit Pods direkt über ein virtuelles Netzwerk (CNI) miteinander kommunizieren können — ohne Port-Kollisionen und mit einfacher Netzwerk-Semantik.

Verwandte Artikel

• Nginx: Webserver, Reverse Proxy und Ingress Controller
• Proxy, Reverse Proxy & Load Balancer
• Zero-Trust Architektur für Kubernetes
• Kubernetes Service Discovery