Kubernetes – Die ehrliche Perspektive

Kubernetes löst echte Probleme – aber nicht kostenlos

Der vorherige Post beschreibt wo Docker an seine Grenzen stößt: Rolling Updates, Skalierung, Health Management, Konfigurationsdrift. Kubernetes hat für jedes dieser Probleme eine durchdachte Antwort. Das ist keine Marketingaussage – es stimmt technisch.

Aber Kubernetes ist kein Zauberwort. Die Komplexität verschwindet nicht. Sie wird verschoben – von der Entwicklung auf die Infrastruktur. Und dieser Shift hat einen Preis.

Wie Kubernetes die Probleme technisch löst

Rolling Updates – deklarativ statt manuell

In Kubernetes beschreibt man nicht wie ein Update passiert, sondern was das Ergebnis sein soll:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: meine-app
spec:
  replicas: 5
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1    # höchstens 1 Instanz gleichzeitig down
      maxSurge: 1          # höchstens 1 zusätzliche Instanz gleichzeitig
  template:
    spec:
      containers:
        - name: app
          image: meine-app:v2

kubectl apply -f deployment.yaml – fertig. Kubernetes übernimmt: neue Pods starten, warten bis sie bereit sind, alte Pods stoppen, nächster Pod. Kein Bash-Script, kein manuelles Proxy-Update, kein Warten und Hoffen.

Rollback bei Fehlern:

kubectl rollout undo deployment/meine-app

Der vorherige Zustand ist bekannt – Kubernetes hat ihn gespeichert.

Health Management – mit Konsequenz

Kubernetes kennt zwei Arten von Health Checks und reagiert automatisch auf beide:

readinessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 5

livenessProbe:
  httpGet:
    path: /health
    port: 8080
  failureThreshold: 3
  periodSeconds: 10

Readiness Probe: Solange ein Pod nicht “ready” ist, bekommt er keinen Traffic. Kein Request geht an eine Instanz die noch hochfährt oder gerade überlastet ist.

Liveness Probe: Schlägt sie dreimal fehl, wird der Pod automatisch neu gestartet. Kein menschlicher Eingriff nötig.

Docker hat diese Information auch – aber keine automatische Konsequenz daraus. Kubernetes hat beides.

Skalierung – automatisch

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: meine-app-hpa
spec:
  scaleTargetRef:
    kind: Deployment
    name: meine-app
  minReplicas: 2
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

CPU über 70%? Kubernetes startet neue Pods, verteilt sie im Cluster, updated den internen Load Balancer – automatisch. Last geht zurück? Pods werden wieder abgebaut. Kein manueller Eingriff, kein Proxy-Update, keine Nachtschicht.

Konfigurationsdrift – Desired State

Das ist konzeptuell der größte Unterschied. Kubernetes erzwingt den gewünschten Zustand:

replicas: 5
image: meine-app:v2

Wenn ein Pod abstürzt, startet Kubernetes automatisch einen neuen. Wenn jemand manuell einen Pod löscht, startet Kubernetes automatisch einen neuen. Der deklarierte Zustand ist das Gesetz – Abweichungen werden automatisch korrigiert.

Mit Docker gibt es keinen Mechanismus der prüft ob der tatsächliche Zustand dem gewünschten entspricht. Mit Kubernetes ist das der Kern des Systems.

Storage – abstrahiert

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: app-storage
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

Der Pod fragt nach 10 GiB Storage – wo der physisch liegt, welcher NFS-Server dahintersteckt, welcher Pfad gemountet wird, ist dem Pod egal. Der Storage-Administrator konfiguriert das einmal als StorageClass. Entwickler konsumieren Storage wie eine Ressource, ohne Infrastruktur-Details zu kennen.

Was Kubernetes nicht löst: die Komplexität verschwindet nicht

Hier ist die ehrliche Wahrheit: Kubernetes verschiebt Komplexität. Es eliminiert sie nicht.

Mit Docker liegt die Komplexität beim Entwickler oder Systemadministrator der den Stack aufbaut. Mit Kubernetes liegt sie bei dem Team das Kubernetes selbst betreibt.

Docker-Stack:
Entwickler → Docker Compose → fertig
Komplexität: mittel, beim Entwickler

Kubernetes on-premises:
Entwickler → Kubernetes-Manifeste
Infrastruktur-Team → Cluster-Setup, etcd, Networking, Storage, Updates
Komplexität: hoch, aufgeteilt – aber nicht kleiner

Ein produktionsreifer Kubernetes-Cluster on-premises ist kein Wochenendprojekt. Es braucht: Cluster-Planung (Nodes, Netzwerk, Hochverfügbarkeit), etcd-Management (die Zustandsdatenbank des Clusters), CNI-Konfiguration (Container Network Interface), Ingress-Controller, Storage-Provisioning, Monitoring des Clusters selbst, regelmäßige Kubernetes-Versionsupgrades, Sicherheitshärtung, und Backup-Strategie.

Das erfordert erfahrene Administratoren – keine Einsteiger-Aufgabe, keine Nebenbei-Tätigkeit. Und erfahrene Kubernetes-Administratoren sind auf dem Arbeitsmarkt gesucht und entsprechend teuer.

On-Premises Kubernetes: der echte Aufwand

Ein Beispiel für eine minimale hochverfügbare On-Premises-Installation:

Control Plane (3 Nodes, für HA):
- etcd Cluster
- kube-apiserver
- kube-scheduler
- kube-controller-manager

Worker Nodes (je nach Last):
- kubelet
- kube-proxy
- Container Runtime (containerd)

Zusätzlich nötig:
- CNI Plugin (Calico, Flannel, Cilium...)
- Ingress Controller (NGINX, Traefik...)
- Storage Provisioner
- Certificate Management
- Monitoring (Prometheus + Grafana – aber für den Cluster selbst)
- Log Aggregation
- Registry (für Container Images)

Und das ist nur der Betrieb. Dazu kommt das initiale Setup, die Dokumentation, die Schulung des Teams, und die laufende Pflege. Kubernetes-Versionsupgrades sind keine Kleinigkeit – sie erfordern geplante Wartungsfenster und tiefes Verständnis der Changelog-Inhalte.

Kurz gesagt: On-Premises Kubernetes rechtfertigt ein eigenes Infrastruktur-Team. Ohne dieses Team wird es früher oder später zu einem unkontrollierten Risiko.

Managed Kubernetes – die pragmatische Alternative

Die großen Cloud-Anbieter nehmen den Cluster-Betrieb ab:

Der Control Plane – also das Herzstück des Clusters – wird vom Anbieter betrieben, gepatcht und hochverfügbar gehalten. Das Team muss sich nur um die Worker Nodes und die Applikationen kümmern.

Das reduziert den Aufwand erheblich. Aber es eliminiert ihn nicht:

• Kubernetes-Manifeste müssen geschrieben und gepflegt werden
• Networking und Storage müssen verstanden werden
• Sicherheit und RBAC bleiben Aufgabe des Teams
• Kosten steigen mit der Clustergröße

Managed Kubernetes ist der richtige Einstieg für Teams die Kubernetes einsetzen wollen ohne einen spezialisierten Cluster-Administrator einzustellen. Aber auch hier: die Kubernetes-Konzepte müssen verstanden sein – Managed bedeutet betriebener Control Plane, nicht betriebene Applikationen.

Wann lohnt sich die Investition wirklich?

Die ehrliche Antwort lautet: erst bei einer bestimmten Größenordnung.

Kleine Umgebung (< 20 Dienste, 1–3 Server):
→ Docker Compose
→ Overhead von Kubernetes überwiegt den Nutzen bei weitem

Mittlere Umgebung (20–100 Dienste, mehrere Server):
→ Managed Kubernetes prüfen
→ Investition beginnt sich zu rechnen wenn manuelle Verwaltung
  mehr Zeit kostet als Kubernetes-Betrieb

Große Umgebung (100+ Dienste, viele Teams, hohe Verfügbarkeitsanforderungen):
→ Kubernetes ist die richtige Wahl
→ Dediziertes Infrastruktur-Team rechtfertigt sich durch Skaleneffekte

Der entscheidende Skalierungseffekt: Ein Infrastruktur-Team das Kubernetes betreibt, ermöglicht es zehn Entwicklungsteams Dienste zu deployen ohne sich um Infrastruktur zu kümmern. Dieser Hebel lohnt sich erst wenn tatsächlich zehn Teams da sind.

Für ein Team von fünf Entwicklern das zwanzig Dienste betreibt, ist Kubernetes in den meisten Fällen überdimensioniert – und die Investition in Kubernetes-Expertise nimmt Kapazität weg die im Produkt besser aufgehoben wäre.

Die eigentliche Frage

Vor der Entscheidung für Kubernetes stehen zwei ehrliche Fragen:

Haben wir das Problem das Kubernetes löst? Mehrere Hosts, automatische Skalierung, kritische Verfügbarkeitsanforderungen, viele Teams – wenn keines dieser Szenarien zutrifft, löst Kubernetes kein reales Problem.

Haben wir die Kapazität Kubernetes zu betreiben? On-Premises braucht einen erfahrenen Administrator. Managed Cloud braucht immer noch Kubernetes-Kenntnisse im Team. Wenn beides nicht vorhanden ist, schiebt Kubernetes das Problem nur von “Docker ist komplex” zu “unser Kubernetes-Cluster ist instabil”.

Kubernetes ist nicht die Zukunft von Docker – es ist ein anderes Werkzeug für andere Probleme. Docker Compose für den Homelab, den kleinen Firmenserver, den überschaubaren Stack: das ist keine Schande, das ist die richtige Entscheidung.

Kurz zusammengefasst