Cloud & Infrastruktur
Kubernetes ist kein Ziel
Wann sich ein Cluster lohnt, wann eine einzelne VM die bessere Architektur ist – und woran man den Unterschied erkennt.
Kubernetes ist ein hervorragendes Werkzeug. Es ist auch das am häufigsten missverstandene. Wir sehen regelmässig Cluster, die drei Container betreiben, von zwei Personen gewartet werden und mehr kosten als die Anwendung, die darauf läuft.
Die ehrliche Frage vor jedem Cluster
Nicht „können wir Kubernetes?“, sondern: Was passiert, wenn dieser Dienst um 3 Uhr morgens ausfällt – und wer schaut hin?
Wenn die Antwort „ein Alarm, ein Runbook, ein Neustart“ ist, braucht es keinen Orchestrator. Wenn die Antwort „zwölf Dienste müssen in der richtigen Reihenfolge wieder hochkommen, mit Rolling Updates und Zero Downtime“ ist, dann schon.
Wann sich Kubernetes lohnt
- Mehrere Teams deployen unabhängig voneinander in dieselbe Umgebung.
- Lastspitzen sind unvorhersehbar und Skalierung muss automatisch passieren.
- Compliance verlangt reproduzierbare, deklarative Infrastruktur mit Audit-Trail.
- Es gibt Menschen, die den Cluster betreiben – nicht nur benutzen.
Wann nicht
- Eine Anwendung, eine Datenbank, ein Team.
- Der Traffic ist bekannt und passt auf eine gut dimensionierte Maschine.
- Niemand im Team hat Zeit, sich um Upgrades, Netzwerk-Policies und Zertifikate zu kümmern.
In diesen Fällen ist eine VM mit systemd, einem Reverse Proxy und einem sauberen Deploy-Skript nicht rückständig. Sie ist die richtige Grösse.
Was wir stattdessen zuerst bauen
Egal ob Cluster oder VM – drei Dinge kommen immer zuerst:
- Ein Deployment, das jeder auslösen kann. Ein Befehl, ein Ergebnis, kein Wissen im Kopf einer Person.
- Observability, die man liest. Wenige Metriken, klare Alarme, Logs mit Kontext.
- Ein Rollback, das schneller ist als die Analyse. Zurückrollen, dann verstehen.
Wer diese drei hat, kann jederzeit von der VM in den Cluster wachsen. Wer sie nicht hat, hat mit Kubernetes nur ein grösseres Problem.