Kubernetes im Mittelstand funktioniert nur, wenn du es als Betriebsmodell verstehst und nicht als einmaliges Projekt. Ein Cluster, das nach dem Rollout niemand mehr pflegt, verliert innerhalb weniger Monate seinen Wert: Policies veralten, Zugänge wuchern, und das Wissen sitzt in einem Kopf statt im Team. Kubernetes-Betrieb heißt, Governance, Sicherheit und Übergabefähigkeit von Anfang an mitzudenken, nicht erst nach dem ersten Ausfall.
Ich berate mittelständische Unternehmen beim Kubernetes-Einsatz und betreibe selbst produktionsreife Cluster in einer deutschen Cloud, mit mehreren Control-Plane-Nodes in getrennten Rechenzentren für Hochverfügbarkeit. Alle meine Beiträge rund um Kubernetes findest du gesammelt auf der Seite Kubernetes.
Was für Konzerne selbstverständlich ist, eigene Betriebsteams, klare Zuständigkeiten, ein Vier-Augen-Prinzip bei Änderungen, wird im Mittelstand oft übersprungen. Dabei entscheidet genau dieser Unterbau darüber, ob Kubernetes am Ende eine Investition oder ein Risiko wird.
Warum Unternehmen überhaupt auf Kubernetes setzen
Kubernetes ist kein Selbstzweck. Wer ein Cluster aufbaut, weil es gerade Standard ist, verbrennt Budget ohne Gegenwert. In meinen Projekten lässt sich das eigentliche Motiv fast immer auf einen von drei Punkten zurückführen: schnellere Time-to-Market für neue Software, geringere Betriebskosten durch bessere Auslastung der vorhandenen Hardware, oder die Fähigkeit, mehrere Produkte auf derselben Plattform zu bedienen, ohne für jedes Projekt eine eigene Infrastruktur aufzubauen.
Kubernetes selbst verspricht dafür automatisierte Rollouts, Self-Healing und horizontale Skalierung. Das stimmt technisch, löst aber nicht automatisch das unternehmerische Problem. Ein Cluster mit perfekter Automatisierung bringt wenig, wenn niemand im Haus versteht, warum ein Pod gerade neu startet oder wer eine Berechtigung ändern darf. Genau da beginnt der Unterschied zwischen einem Kubernetes-Projekt und einem echten Kubernetes-Betrieb.
Vom Kubernetes-Pilotprojekt zum Betriebsmodell
Ein Pilotprojekt hat ein Enddatum: Ein Proof of Concept läuft einige Monate, dann wird entschieden, ob es weitergeht. Ein Betriebsmodell hat kein Enddatum. Sobald ein Cluster produktive Last trägt, brauchst du Antworten auf Fragen, die im Pilotprojekt niemand gestellt hat. Wer patcht die Nodes? Wer reagiert, wenn ein Control-Plane-Node ausfällt? Wer prüft, ob ein neues Deployment gegen eine Richtlinie verstößt, bevor es live geht?
In der Praxis sehe ich bei mittelständischen Kunden häufig denselben Übergang: Ein einzelner Entwickler baut das erste Cluster auf, meist aus Eigeninitiative, weil das Team schneller ausrollen wollte. Das funktioniert, solange diese eine Person verfügbar ist. Sobald sie im Urlaub, krank oder nicht mehr im Unternehmen ist, zeigt sich, ob aus dem Projekt tatsächlich ein Betriebsmodell geworden ist.
Wissen, das nicht an einer Person hängt
Der größte Risikofaktor, den ich bei Kubernetes im Mittelstand sehe, ist nicht die Technik, sondern die Verteilung von Wissen. Läuft ein Cluster über GitOps, steht der gewünschte Zustand des Systems im Git-Repository, jede Änderung hat einen Commit, einen Autor und im besten Fall eine Begründung. Läuft ein Cluster über manuelle kubectl-Kommandos einzelner Personen, existiert dieses Gedächtnis nirgendwo außer in deren Kopf.
Für die Übergabefähigkeit zählen aus meiner Sicht drei Dinge. Erstens die deklarative Konfiguration als einzige Wahrheit, damit ein neuer Kubernetes-Experte im Team den Zustand des Clusters aus dem Repository rekonstruieren kann, ohne den Vorgänger fragen zu müssen. Zweitens klar zugewiesene Rollen und Rechte, damit sichtbar ist, wer wofür zuständig ist, statt dass ein Administrator-Zugang für alle gilt. Drittens eine Dokumentation der Entscheidungen, nicht nur der Konfiguration: warum drei Nodes und nicht fünf, warum dieser Storage-Anbieter und kein anderer.
Dazu gehört auch, dass eine Wiederherstellung nicht nur einmal getestet, sondern von mehreren Personen im Team beherrscht wird. Wie du etcd und Volumes sauber sicherst und ein Restore übst, steht in Kubernetes Backup: etcd und Volumes sichern.
Governance und Sicherheit gehören von Anfang an dazu
Governance und Security werden in vielen Projekten getrennt behandelt, in der Praxis gehören sie zusammen. Security schützt den Cluster und die Anwendungen darin vor unautorisiertem Zugriff, Governance sorgt dafür, dass der Betrieb überhaupt nach nachvollziehbaren Regeln läuft.
Für den Mittelstand heißt das konkret: Rollen und Rechte über RBAC statt über geteilte Admin-Zugänge, Richtlinien, die automatisiert durchgesetzt werden, statt in einem Wiki zu verstauben, und ein Protokoll, das zeigt, wer wann was geändert hat. Nichts davon ist exotisch, alles ist Teil von Kubernetes selbst oder mit etablierten Werkzeugen umsetzbar. Die offizielle Dokumentation zu RBAC in Kubernetes beschreibt das zugrunde liegende Modell im Detail.
Ein kurzes Beispiel für eine Rolle, die einem Entwicklerteam Lesezugriff auf die Pods im eigenen Namespace gibt, ohne Schreibrechte auf andere Ressourcen:
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: team-shop
name: pod-reader
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list", "watch"]
Diese Rolle bindest du per RoleBinding an eine Gruppe oder eine Person, nie an das gesamte Team als Administrator. Klein anfangen und Rechte gezielt erweitern schützt vor dem häufigsten Fehler, den ich bei Bestandsaufnahmen sehe: ein Cluster-Admin-Zugang für alle, weil das anfangs bequemer war.
Was der eigene Betrieb wirklich bedeutet
Bevor du dich für ein Betriebsmodell entscheidest, lohnt ein ehrlicher Blick auf drei Kostenblöcke: die Infrastruktur selbst, den laufenden Betrieb und die Menschen, die ihn tragen. Infrastruktur ist meist der kleinste und am einfachsten zu vergleichende Posten. Der laufende Betrieb, Monitoring, Patches, Backups, Reaktion auf Störungen, wird regelmäßig unterschätzt, weil er nicht in einer Rechnung auftaucht, sondern in Arbeitszeit. Und die Menschen sind der Posten, der im Mittelstand am ehesten fehlt: Wer im Unternehmen kann im Ernstfall ein Cluster wiederherstellen, wenn die eine Person, die es aufgesetzt hat, gerade nicht erreichbar ist?
Genau deshalb lohnt sich der Vergleich zwischen einem selbst betriebenen und einem verwalteten Kubernetes-Angebot nicht nur über den Server-Preis, sondern über diese drei Blöcke gemeinsam. Eine ausführliche Aufschlüsselung der einzelnen Kostenblöcke findest du in Kubernetes Kosten: was ein Cluster kostet, die Grundsatzfrage Eigenbetrieb oder Cloud beantworte ich in Kubernetes on-premise oder Cloud?.
Für wen sich Kubernetes im Mittelstand lohnt, und für wen nicht
Kubernetes lohnt sich, wenn du mehrere Services oder Microservices betreibst, wenn Lastspitzen oder Wachstum eine automatische Skalierung brauchen, und wenn mehrere Teams oder Produkte dieselbe Plattform nutzen können. Je mehr eigenständige Anwendungen ein Unternehmen betreibt, desto mehr zahlt sich eine gemeinsame Plattform aus, die Standardaufgaben wie Rollout, Neustart und Lastverteilung automatisiert übernimmt.
Die Unternehmensgröße allein entscheidet dabei nichts. Zwei Fragen wiegen schwerer: Gibt es mindestens zwei Menschen, die einen Cluster verstehen und im Zweifel anfassen dürfen, und gibt es eine geregelte Erreichbarkeit außerhalb der Bürozeiten, wenn die Anwendung nachts ausfallen darf oder eben nicht. Ein Zwanzig-Personen-Unternehmen mit zwei erfahrenen Entwicklern und geregelter Bereitschaft betreibt Kubernetes leichter als ein Zweihundert-Personen-Unternehmen, in dem eine einzelne Person alles allein trägt.
Kubernetes lohnt sich dagegen selten für eine einzelne, überschaubare Anwendung mit wenig Betriebsaufwand. Ein einzelner Server mit Containern oder ein einfacher Cloud-Dienst reicht dann oft aus, und die zusätzliche Komplexität eines Clusters kostet mehr, als sie einspart. Auch Altanwendungen mit sehr speziellen Infrastrukturanforderungen, etwa einer festen IP-Adresse für eine Firewall-Freischaltung, passen manchmal einfach nicht zu Kubernetes, ohne dass sich eine Anpassung lohnt. Wer diese Fragen vor der Einführung ehrlich beantwortet, erspart sich ein Cluster, das nur Kosten produziert und nie den erhofften Nutzen bringt.
Häufige Fragen
Was unterscheidet ein Kubernetes-Projekt von einem Kubernetes-Betrieb?
Ein Projekt hat ein Enddatum und ein definiertes Ziel, danach ist es abgeschlossen. Ein Betrieb läuft dauerhaft weiter: Patches, Monitoring, Governance und die Übergabe von Wissen an neue Teammitglieder hören nie auf. Wer Kubernetes nur als Projekt plant, unterschätzt fast immer den laufenden Aufwand danach.
Wie viel Fachwissen braucht ein Unternehmen für den Kubernetes-Betrieb?
Genug, um Rollen, Rechte, Updates und Störungen ohne eine einzelne unersetzliche Person zu bewältigen. Das bedeutet nicht, dass jede Entwicklerin oder jeder Entwickler Kubernetes-Experte sein muss, aber mindestens zwei Personen sollten das Cluster im Ernstfall eigenständig betreiben können.
Ist Kubernetes für kleine und mittlere Unternehmen überhaupt geeignet?
Ja, wenn mehrere Services oder Produkte auf derselben Plattform laufen und Skalierung oder Hochverfügbarkeit tatsächlich gebraucht werden. Für eine einzelne, einfache Anwendung ist der Betriebsaufwand meist höher als der Nutzen.
Was bedeutet Hochverfügbarkeit bei Kubernetes konkret?
Mindestens mehrere Control-Plane-Nodes, idealerweise verteilt auf getrennte Rechenzentren, damit der Ausfall eines einzelnen Nodes den Cluster nicht lahmlegt. Die möglichen Topologien beschreibt die Kubernetes-Dokumentation zu Hochverfügbarkeits-Optionen im Detail.
Wie du den nächsten Schritt gehst
Der wichtigste Schritt vor der Einführung ist ehrlich zu klären, ob dein Unternehmen bereit ist, Kubernetes dauerhaft zu betreiben, nicht nur einmalig auszurollen. Das betrifft Rollen, Rechte, Backups und die Frage, wer im Ernstfall einspringt.
Wenn du dir nicht sicher bist, ob Kubernetes für dein Unternehmen der richtige Schritt ist oder wie sich ein bestehendes Cluster übergabefähig machen lässt, ist eine Bestandsaufnahme meist der schnellste Weg zur Klarheit. Auf meiner Seite Kubernetes findest du, wie ich dabei vorgehe.
Ausführlich mit allen Beispielen steht das in Kapitel 2 und Kapitel 7 meines Kubernetes-Praxisbuchs bei Rheinwerk.
