Welche Zielplattform passt zu Ihren Anwendungen? WZ-IT analysiert Anwendung, Team und Betriebsziele und entwickelt daraus eine passende Architektur - von Compose oder Coolify bis zum Kubernetes-Cluster auf eigener oder europäischer Infrastruktur. Kubernetes und Anwendungsmodernisierung
Nicht jedes Unternehmen und nicht jede Anwendung benötigt Kubernetes. Kubernetes passt, wenn die Plattform vorhandene Komplexität bei Deployment, Skalierung und Betrieb standardisiert. Es passt nicht, wenn der zusätzliche Cluster-Lifecycle mehr Aufwand erzeugt als die Anwendungen erfordern oder dauerhaft verantwortet werden kann.
Die Frage sollte deshalb nicht lauten: „Sind wir groß genug für Kubernetes?“ Besser ist: Welche Probleme müssen wir im Betrieb lösen, welche Entwicklung erwarten wir und welche Plattform kann unser Team zuverlässig beherrschen? Nutzerzahl und Serveranzahl allein liefern darauf keine Antwort.
Inhaltsverzeichnis
- Die kurze Entscheidung
- Starke Signale für Kubernetes
- Warnsignale gegen Kubernetes
- Entscheidungsmatrix
- Fünf typische Ausgangslagen
- Die oft übersehene Teamfrage
- Betriebskosten statt nur Infrastrukturkosten
- Ein belastbarer Kubernetes-Pilot
- Kubernetes als Ziel einer Modernisierung
Die kurze Entscheidung
Als Leitlinie gilt:
- Wenige stabile Anwendungen, ein kleines Team, geringe Änderungsfrequenz: meist VM, Docker Compose oder Coolify.
- Viele Dienste, mehrere Teams, häufige Deployments und gemeinsame Plattformstandards: Kubernetes wird interessant.
- Dynamische Last, hohe Automatisierung und belastbare Resilienzanforderungen: Kubernetes kann seinen Aufwand klar rechtfertigen.
- Keine benannte Betriebsverantwortung: zunächst nicht Kubernetes, unabhängig von der Technik.
Kubernetes ist nicht automatisch „professioneller“ als eine kleinere Plattform. Eine gut dokumentierte Compose-Umgebung mit Monitoring, Backups, getesteten Restores und sauberer Delivery ist professioneller als ein ungepflegter Kubernetes-Cluster ohne Verantwortlichen.
Starke Signale für Kubernetes
Kubernetes schafft typischerweise Mehrwert, wenn mehrere der folgenden Punkte gleichzeitig gelten.
Viele Workloads mit wiederkehrenden Betriebsanforderungen
Wenn zahlreiche APIs, Webanwendungen, Worker und geplante Jobs nach ähnlichen Regeln betrieben werden sollen, lohnt eine gemeinsame Abstraktion. Deployment, Health Checks, Ressourcen, Secrets, Netzwerk und Observability lassen sich standardisieren.
Mehrere Teams oder Produkte
Kubernetes kann eine interne Plattform bilden, auf der Teams Anwendungen nach definierten Regeln selbst ausliefern. Namespaces, RBAC, Quotas, Policies und GitOps schaffen ein gemeinsames Betriebsmodell, ohne jedem Team vollständigen Infrastrukturzugriff zu geben.
Häufige, automatisierte Deployments
Rolling Updates, deklarative Zustände und GitOps spielen ihre Stärke aus, wenn Änderungen oft und reproduzierbar ausgerollt werden. Bei zwei manuellen Releases pro Jahr ist der Nutzen deutlich kleiner.
Horizontale Skalierung und wechselnde Last
Workloads, die mehrere Instanzen parallel ausführen können, lassen sich anhand von Metriken skalieren. Das setzt allerdings eine dafür geeignete Anwendung, korrekte Resource Requests und verfügbare Clusterkapazität voraus.
Wartung und Ausfälle ohne lange Unterbrechung
Mehrere Replikate, Pod Disruption Budgets, verteilte Nodes und kontrollierte Rollouts können Wartung und Teilausfälle abfangen. Kubernetes kann diese Mechanismen orchestrieren, beseitigt aber keine gemeinsamen Ausfallpunkte in Hypervisor, Storage oder Netzwerk.
Souveräne Plattform statt einzelner Providerdienste
Eine portable Kubernetes-Plattform kann auf Proxmox, Bare Metal, bei europäischen Anbietern oder auf EKS, AKS und GKE laufen. Das reduziert nicht automatisch jeden Lock-in, schafft aber eine einheitlichere Anwendungsebene über unterschiedliche Infrastrukturmodelle.
Warnsignale gegen Kubernetes
Folgende Ausgangslagen sprechen für eine einfachere Lösung oder zumindest gegen einen sofortigen Produktionsstart:
- Es gibt nur eine oder zwei stabile Anwendungen und kaum Deployments.
- Das Team hat weder Zeit noch Partner für Cluster-Upgrades, Security und Störungen.
- Der Hauptgrund lautet „Kubernetes ist Industriestandard“ statt eines konkreten Problems.
- Die Anwendung ist noch nicht sauber containerisiert und besitzt unbekannte Abhängigkeiten.
- Backups, Restore-Ziele und Monitoring sind bereits heute ungeklärt.
- Ein einzelner physischer Server bleibt die gesamte Infrastruktur. Ein Cluster darauf erzeugt keine physische Hochverfügbarkeit.
- Das Budget bewertet nur Serverkosten, nicht Plattformpflege und Lernkurve.
Kubernetes kann eine gewachsene Anwendung nicht durch das Verschieben von Containern automatisch modernisieren. Vorher müssen Datenhaltung, Konfiguration, Sessions, Dateisystemzugriffe, Jobs und externe Abhängigkeiten verstanden werden.
Entscheidungsmatrix
| Kriterium | Compose / Coolify eher passend | Kubernetes eher passend |
|---|---|---|
| Anwendungen | wenige, überschaubare Stacks | viele Dienste oder mehrere Produkte |
| Teams | ein kleines Team | mehrere Teams mit gemeinsamen Standards |
| Deployments | selten, einfach | häufig, automatisiert, mehrere Umgebungen |
| Skalierung | vertikal oder wenige feste Instanzen | horizontal, dynamisch oder stark verteilt |
| Verfügbarkeit | kurze Wartungsfenster akzeptabel | Teilausfälle und Wartung sollen abgefangen werden |
| Governance | einfache Rollen reichen | Namespaces, Policies, Quotas, Admission Controls |
| Infrastruktur | ein oder wenige Systeme | mehrere Failure Domains, hybrid oder Multi-Cluster |
| Betriebsfähigkeit | begrenzte Plattformkapazität | internes oder externes Plattform-Ownership vorhanden |
Die Tabelle ist kein Punktesystem. Ein regulatorisch kritischer Zugriff oder eine extreme Skalierungsanforderung kann schwerer wiegen als mehrere kleinere Gegenargumente. Entscheidend ist das Zielbild als Ganzes.
Fünf typische Ausgangslagen
1. Eine klassische Businessanwendung
Eine Webanwendung, eine API und eine PostgreSQL-Datenbank auf einem Server brauchen meistens kein Kubernetes. Docker Compose oder Coolify liefern eine deutlich kleinere Betriebsfläche. Monitoring, Backup und Restore bleiben trotzdem Pflicht.
2. Bestehende Software soll übernommen und containerisiert werden
Hier ist Kubernetes nicht automatisch der erste Schritt. Zunächst werden Anwendung, Datenflüsse, Persistenz, Deployment und Abhängigkeiten stabilisiert. Danach kann bewusst zwischen VM, Compose, Coolify und Kubernetes entschieden werden. Genau diese Trennung ist Kern eines Refit: erst ein belastbares Betriebsmodell, dann die passende Orchestrierung.
3. Eine wachsende SaaS-Plattform mit mehreren Diensten
Mehrere APIs, Worker, Events, getrennte Umgebungen und häufige Releases sind eine typische Kubernetes-Ausgangslage. Die Plattform kann Delivery, Ressourcen und Policies standardisieren. Datenbanken können dabei im Cluster, auf einer separaten Infrastruktur oder als Managed Service laufen, abhängig von Betriebsmodell und Risiko.
4. Verteilte Edge- oder Standortsysteme
Für zentrale Plattformdienste kann Kubernetes gut passen, während kleine Standorte mit K3s, Containern oder spezialisierten Edge-Komponenten laufen. Nicht jeder Standort braucht einen vollwertigen Cluster. Netzwerk, Offline-Fähigkeit und zentrales Lifecycle-Management sind hier wichtiger als ein einheitliches Schlagwort.
5. Regulierte oder souveräne Infrastruktur
Kubernetes auf Proxmox oder europäischen Bare-Metal-Anbietern kann eine kontrollierbare Plattform bilden. Entscheidend sind dann Mandantentrennung, Identity, private Zugriffe, Audit, Verschlüsselung, Backup-Standorte und nachvollziehbare Updates. Die Open-Source-Basis allein erfüllt noch keine Compliance-Anforderung.
Die oft übersehene Teamfrage
Kubernetes verschiebt Arbeit. Entwickler erhalten eine standardisierte Plattform, dafür entsteht eine eigene Plattformebene. Jemand muss verantwortlich sein für:
- Cluster- und Node-Upgrades,
- CNI, Ingress/Gateway, DNS und Zertifikate,
- Storage-Klassen und Datenwiederherstellung,
- RBAC, Policies, Secrets und Schwachstellen,
- GitOps-Controller und Deployment-Prozesse,
- Monitoring, Logging, Alerting und Incident Response,
- Kapazität, Kosten und Lebenszyklus der Add-ons.
Die offizielle Produktionsdokumentation unterscheidet bewusst zwischen Lernumgebungen und dauerhaft verfügbaren Produktionsclustern. Ein Installer reduziert den Aufbau, aber nicht die langfristige Verantwortung.
Diese Verantwortung kann ein internes Plattformteam tragen, ein bestehendes DevOps-Team gemeinsam mit einem Partner oder ein Managed-Operations-Modell. Sie darf nur nicht implizit zwischen Entwicklung und Administration liegen bleiben.
Betriebskosten statt nur Infrastrukturkosten
Kubernetes selbst kostet keine Lizenzgebühr. Der Cluster verursacht dennoch Kosten durch:
- zusätzliche Nodes und Reserven für Ausfälle und Wartung,
- Load Balancer, Storage, Backup und Observability,
- Aufbau und Pflege der Plattformautomatisierung,
- regelmäßige Versions- und Add-on-Upgrades,
- Security-Arbeit und Bereitschaft für Störungen,
- Schulung und technische Dokumentation.
Ein Managed Kubernetes nimmt Teile davon ab, beseitigt sie aber nicht. EKS, AKS oder GKE betreiben wesentliche Control-Plane-Komponenten; Anwendung, Workload-Security, Rechte, Netzwerk, Daten und Kostensteuerung bleiben geteilt oder beim Kunden.
Die wirtschaftliche Frage lautet daher: Spart die standardisierte Plattform über Anwendungen und Teams mehr wiederkehrende Arbeit und Risiko ein, als sie selbst erzeugt?
Ein belastbarer Kubernetes-Pilot
Ein guter Pilot ist kein „Hello World“, sondern ein kleiner Test des späteren Betriebsmodells:
- Eine repräsentative, aber nicht geschäftskritische Anwendung auswählen.
- Zielarchitektur und Verantwortungsgrenzen dokumentieren.
- Deployment über Git und CI/CD oder GitOps aufbauen.
- Ressourcen, Health Checks, Secrets und Netzwerkzugriffe definieren.
- Monitoring, Logs und Alarme anschließen.
- Node-Ausfall und kontrolliertes Upgrade testen.
- Backup erstellen und Restore tatsächlich durchführen.
- Aufwand, Liefergeschwindigkeit und Fehlerbilder mit der bisherigen Plattform vergleichen.
Erst dieser Test zeigt, ob Kubernetes für das eigene Team einen operativen Vorteil schafft. Ein erfolgreich laufender Demo-Pod beweist das nicht.
Kubernetes als Ziel einer Modernisierung
Bei einer Migration muss Kubernetes nicht der Ausgangspunkt sein. WZ-IT trennt den Weg in vier Entscheidungen:
- Ist-System verstehen: Prozesse, Abhängigkeiten, Daten, Netzwerk, Deployments und Betriebsprobleme erfassen.
- Anwendung modernisieren: containerisieren, Konfiguration externalisieren, Health Checks schaffen und Datenpfade ordnen.
- Zielplattform wählen: VM, LXC, Docker Compose, Coolify oder Kubernetes anhand realer Anforderungen bestimmen.
- Betrieb aufbauen: Delivery, Zugriffe, Observability, Backup, Security und Verantwortlichkeiten zusammenführen.
Wenn Kubernetes passt, lässt es sich auf Proxmox und souveräner Infrastruktur betreiben. Interne Services und die Cluster-API können über NetBird privat und identitätsbasiert erreichbar bleiben.
Fazit
Sie brauchen Kubernetes nicht, weil Sie Container einsetzen. Sie brauchen es dann, wenn eine verteilte, deklarative Plattform konkrete Probleme bei Delivery, Skalierung, Ausfallsicherheit und Governance besser löst als eine kleinere Alternative.
Die richtige Architektur ist die einfachste, die Ihre Anforderungen zuverlässig erfüllt und dauerhaft betrieben werden kann. Das kann Kubernetes sein. Es kann ebenso bewusst Docker Compose, Coolify oder eine solide VM-Architektur sein.
Die Migration von Compose zu Kubernetes trennt Konvertierung, Datenübernahme und Abnahme.
Quellen
- Kubernetes-Dokumentation: Produktionsumgebungen
- Kubernetes-Dokumentation: Cluster-Administration
- Kubernetes-Dokumentation: Workloads
- Docker-Dokumentation: Compose
- Coolify-Dokumentation
Weiterlesen: Compose, Kubernetes und Coolify im Vergleich.
