Kubernetes ist längst kein Hype-Thema mehr. Die Plattform ist im Mittelstand angekommen, IT-Dienstleister bieten sie als Standard-Betriebsplattform an, und kaum eine Stellenausschreibung für DevOps-Engineers kommt ohne sie aus. Trotzdem lautet unsere Antwort auf die Frage aus der Überschrift erstaunlich oft: Nein – zumindest noch nicht.
Kubernetes spielt seine Stärken aus, sobald viele Anwendungen nach einem einheitlichen Schema gebaut, ausgerollt und betrieben werden. Fehlt diese Voraussetzung, erhöht Kubernetes vor allem eines: die Komplexität deiner IT-Landschaft.
Als CTO oder CIO solltest du deshalb drei Fragen beantworten, bevor du dich festlegst:
- Ist Kubernetes für unsere Anwendungen überhaupt notwendig?
- Passt Kubernetes zur strategischen IT-Ausrichtung unseres Unternehmens?
- Welche Änderungen, Kompetenzen und Kosten kommen auf uns zu?
Was kann auf Kubernetes laufen?
Theoretisch alles, was auch in einem Container läuft. Klassischerweise sind das Web- und Netzwerkanwendungen auf Basis von Linux, von der webbasierten Zeiterfassung bis zum Datenbankmanagementsystem. Auch moderne .NET-Anwendungen und der Microsoft SQL Server laufen inzwischen in Linux-Containern.
Klassische Windows-Anwendungen dagegen bleiben außen vor. Buchhaltungssoftware, Steuerungssoftware für Telefonanlagen oder Schließsysteme greifen oft auf native Funktionen des Windows-Betriebssystems zurück und lassen sich nicht sinnvoll containerisieren.
Kubernetes für interne Anwendungen
Für die interne IT und klassische Geschäftsanwendungen raten wir in den allermeisten Fällen vom Einsatz von Kubernetes ab. Die folgenden Fragen helfen bei der Entscheidung:
- Hast du genug Zeit, dich mit Kubernetes zu beschäftigen? Konzeptuell wie technisch nimmt die Komplexität zu. Dein Team muss sich intensiv mit Netzwerk, Storage, Zertifikaten, Upgrades und Monitoring im Cluster beschäftigen, und zwar dauerhaft, nicht nur während der Einführung.
- Sollen Datenbanken in Kubernetes laufen?
Möglich ist es mit MySQL, PostgreSQL, Microsoft SQL Server und Oracle. Dagegen spricht unter anderem:
- Speicherintensive und performancekritische Abfragen können durch die zusätzliche Abstraktionsschicht deutlich langsamer werden.
- Die Datensicherung lässt sich schwerer in die zentralen Backup-Mechanismen integrieren.
- Durch geänderte oder virtualisierte Hardware können neue Lizenzkosten entstehen. Das betrifft vor allem Oracle.
- Gibt es genug Anwendungen, die als Container laufen können? Ohne eine größere Zahl containerisierbarer Anwendungen rentiert sich der Aufwand für Betrieb und die Umstellung der Update- und Upgrade-Prozesse in den meisten Fällen nicht.
- Welche Systeme müssen ohnehin außerhalb laufen? Exchange, SharePoint oder Windows-Serverrollen wie Active Directory und Zertifikatsdienste bleiben auf den bestehenden Systemen.
- Gibt es Know-how in der Softwareentwicklung? Kubernetes ist eine API-getriebene Plattform. Ihr volles Potenzial entfaltet sie erst, wenn du Abläufe automatisierst: mit Infrastructure as Code, CI/CD und GitOps.
Daraus folgt: Klassische Infrastrukturdienste wie Domänenbetrieb, Mail, Storage und Datenbanken gehören in der Regel nicht in Kubernetes. Bei Geschäftsanwendungen musst du abwägen, ob der Aufwand dem Nutzen gerecht wird.
Kubernetes für Webanwendungen
Bei Webanwendungen spielt Kubernetes seine Stärken aus. Infrastrukturaufgaben wie die automatische Ausstellung von X.509-Zertifikaten über Let’s Encrypt lassen sich mit Werkzeugen wie cert-manager schnell und einheitlich lösen. Vorgaben zur Verschlüsselung setzt du zentral für alle Anwendungen um, etwa „nur TLS 1.2 und neuer“, wie sie Zertifizierungen wie TISAX fordern.
Bei größeren oder schwankenden Lasten reagiert Kubernetes mit Autoskalierung: Innerhalb kurzer Zeit stehen mehr Ressourcen für die Verarbeitung der Anfragen bereit.
Oberhalb der Infrastruktur lohnt sich Kubernetes aber erst, wenn die Anwendung kontinuierlich weiterentwickelt und häufig ausgerollt wird.
Einfache Webanwendungen
Für eine statische Website oder eine einfache PWA mit einigen hundert Seitenaufrufen pro Sekunde brauchst du kein Kubernetes-Cluster. Jeder größere Hoster stellt dafür die nötigen Ressourcen bereit.
Unsere Einschätzung: Für einfache Webanwendungen oder PHP-Skripte ist Kubernetes in den meisten Fällen unnötig.
Portale und Shops
Für Portale wie Onlineshops oder Foren mit hohem Traffic und relativ langer Verarbeitungszeit (etwa bei WooCommerce oder Magento) kann Kubernetes interessant sein. Läuft eine Marketingaktion, verteilt der Cluster die Anfragen auf mehr Ressourcen. Prüfe aber immer, ob die Autoskalierung deines Cloud-Providers nicht einfacher zu realisieren ist.
Mindestens diese Fragen solltest du vorher beantworten:
- Kann die Anwendung Bilder und andere Dateien zentral speichern und ansprechen?
- Kommt die Anwendung mit verteilten Sessions zurecht, oder braucht sie Session-Stickiness?
- Gibt es bereits einen Entwicklungsprozess, der kontinuierliches Bauen und Ausrollen ermöglicht?
Unsere Einschätzung: Die Entscheidung für oder gegen Kubernetes fällt bei einem Portal in aller Regel erst nach einer Analyse der bestehenden Anwendung und des Entwicklungsprozesses.
SaaS-Produkte
SaaS-Software folgt meist einem von drei Architekturkonzepten:
- Multi-Instance: Für jede:n Kund:in gibt es einen eigenen virtuellen oder physischen Server. Daten sind physisch und logisch getrennt.
- Multi-Host: Die Anwendung liegt mehrfach in verschiedenen Verzeichnissen auf demselben Server. Kund:innen teilen sich die Ressourcen.
- Multi-Tenant: Die Anwendung verwaltet selbst mehrere Mandanten. Sie wird einmal installiert und für viele Kund:innen bereitgestellt. Das spart Ressourcen, erhöht aber die Komplexität der Software.
Bei Multi-Instance und Multi-Host wächst der Aufwand für jedes Release ohne passenden CI/CD-Workflow linear mit der Zahl der Kund:innen. Genau hier reduziert Kubernetes den organisatorischen Overhead drastisch, weil jede Instanz nach demselben Schema ausgerollt wird. Bei Multi-Tenant-Anwendungen spielt Kubernetes vor allem seinen Vorteil bei der Autoskalierung aus.
Und heute: Managed Kubernetes und Platform Engineering
Seit dieser Artikel zum ersten Mal erschienen ist, hat sich einiges getan. Managed-Angebote wie Amazon EKS, Azure Kubernetes Service oder SUSE Rancher nehmen dir einen Teil des Betriebs ab. Die Grundfrage bleibt trotzdem dieselbe: Upgrades, Netzwerk, Sicherheit, Monitoring und das Know-how im Team bleiben deine Aufgabe.
Gleichzeitig ist Platform Engineering zum Leitbild geworden: Ein Plattform-Team stellt den Entwicklungsteams eine interne Plattform bereit, über die sie Anwendungen selbstständig und nach einheitlichen Regeln ausrollen. Kubernetes ist dafür oft das Fundament, aber eben nur dann sinnvoll, wenn es genug Teams und Anwendungen gibt, die diese Plattform auch nutzen.
Für viele Szenarien gibt es außerdem schlankere Alternativen:
| Szenario | Oft die bessere Wahl |
|---|---|
| Wenige Container, geringe Last | Virtuelle Maschine mit Docker Compose |
| Einzelne Services in der Cloud | Managed Container-Dienste wie AWS ECS oder Azure Container Apps |
| Klassische Webanwendung ohne Sonderanforderungen | Platform as a Service oder ein klassischer Hoster |
| Viele Teams, viele Services, häufige Releases | Kubernetes, idealerweise mit GitOps |
Fazit
Ob Kubernetes für deine Software-Produkte sinnvoll ist, musst du individuell bewerten. Kubernetes ist kein Allheilmittel für bestehende IT-Probleme: In vielen Fällen steigt vor allem die Komplexität. Seine Stärken zeigt es, wenn viele Anwendungen nach einem einheitlichen Schema gebaut und betrieben werden und dein Team die Plattform langfristig tragen kann.
Du stehst gerade vor genau dieser Entscheidung oder hast Kubernetes bereits eingeführt und bist dir unsicher, ob die bisherigen Entscheidungen tragen? Genau dafür gibt es unser Architektur-Review. Oder du stellst deine Fragen direkt im Advisory.
Ursprünglich veröffentlicht am 3. Oktober 2020.