Build or Buy Kubernetes? Teil 1

Warum die eigentliche Entscheidung lange vor dem ersten Cluster beginnt

Teil 1 unserer Serie „Build or Buy Kubernetes"

Wer heute über den Einsatz von Kubernetes diskutiert, spricht häufig über [Container]-Orchestrierung, Skalierbarkeit oder Cloud-native Architekturen. Die eigentliche Fragestellung beginnt jedoch an einer völlig anderen Stelle. Nicht die Einführung von Kubernetes entscheidet über den Erfolg einer Plattformstrategie, sondern die Entscheidung darüber, wer dauerhaft Verantwortung für ihren Betrieb übernimmt.

Diese Unterscheidung klingt zunächst banal. In der Praxis ist sie jedoch der Ursprung vieler Fehleinschätzungen.

Nahezu jedes Unternehmen kann heute innerhalb weniger Stunden einen funktionsfähigen Kubernetes-Cluster bereitstellen. Managed-Angebote der Hyperscaler, Distributionen wie RKE2 oder Talos Linux sowie Automatisierungswerkzeuge wie Terraform und Cluster API haben die technische Einstiegshürde erheblich reduziert. Was früher Spezialwissen erforderte, lässt sich heute mit wenigen Infrastrukturdefinitionen reproduzierbar automatisieren.

Diese Entwicklung führt allerdings zu einer gefährlichen Wahrnehmung: Weil sich Kubernetes vergleichsweise einfach bereitstellen lässt, entsteht der Eindruck, dass sich auch sein langfristiger Betrieb entsprechend unkompliziert gestaltet.

Genau an dieser Stelle beginnt die eigentliche Herausforderung.

Ein Kubernetes-Cluster ist noch keine Plattform

Zwischen einem funktionierenden Cluster und einer produktionsreifen Plattform liegen Welten.

Ein Cluster stellt zunächst lediglich die Laufzeitumgebung bereit, in der containerisierte Anwendungen ausgeführt werden können. Er beantwortet jedoch kaum eine der Fragen, die im produktiven Betrieb tatsächlich relevant werden.

Wie werden neue Kubernetes-Versionen eingeführt, ohne produktive Workloads zu gefährden? Welche Sicherheitsrichtlinien gelten für Deployments? Wie werden Secrets verwaltet, Zertifikate automatisiert erneuert oder [Container]-Images auf Schwachstellen geprüft? Welche Prozesse greifen bei einem Ausfall der Control Plane? Wie wird nachgewiesen, dass regulatorische Anforderungen wie NIS2, DORA oder der Cyber Resilience Act eingehalten werden? Und wer trägt letztlich die Verantwortung, wenn all diese Mechanismen unter realen Betriebsbedingungen funktionieren müssen?

Die Antworten auf diese Fragen entstehen nicht durch Kubernetes selbst. Sie entstehen durch Plattformengineering.

Genau deshalb wird in vielen Unternehmen der Aufwand systematisch unterschätzt. Während sich die technische Diskussion häufig um Distributionen, CNI-Plugins oder Ingress-Controller dreht, verschiebt sich die eigentliche Komplexität zunehmend in organisatorische, sicherheitsrelevante und betriebliche Prozesse. Kubernetes bildet dabei lediglich das Fundament einer Plattform, deren Qualität sich nicht an der Anzahl laufender Pods, sondern an ihrer langfristigen Betriebsfähigkeit messen lässt.

Die Build-or-Buy-Frage wird häufig falsch gestellt

Die klassische Diskussion reduziert sich meist auf drei Betriebsmodelle.

Soll die Plattform vollständig selbst betrieben werden?

Soll ein Managed-Kubernetes-Angebot eines Cloud-Anbieters genutzt werden?

Oder übernimmt ein spezialisierter Dienstleister den Betrieb?

Diese Betrachtung greift jedoch zu kurz, weil sie Kubernetes implizit als Produkt behandelt.

Tatsächlich handelt es sich bei Kubernetes um eine Plattformtechnologie, deren wirtschaftlicher Nutzen erst durch die umgebenden Prozesse entsteht. Die eigentliche Entscheidung lautet deshalb nicht, wer den Cluster installiert, sondern wer die Verantwortung für dessen gesamten Lebenszyklus übernimmt.

Diese Verantwortung umfasst weit mehr als regelmäßige Updates oder das Einspielen von Sicherheitspatches.

Sie beginnt bei Architekturentscheidungen und reicht über Netzwerkdesign, Identitätsmanagement, Backup-Strategien, Software Supply Chain Security, Observability, Incident Response, Compliance, Dokumentation und organisatorische Betriebsprozesse bis hin zur kontinuierlichen Weiterentwicklung der Plattform selbst.

Mit anderen Worten: Wer sich für Kubernetes entscheidet, entscheidet sich nicht für eine Software. Er entscheidet sich für den Aufbau oder die Nutzung einer Plattformorganisation.

Die Illusion des Eigenbaus

Viele Unternehmen beginnen ihre Kubernetes-Reise mit einem Self-Managed-Ansatz, und auf den ersten Blick ist diese Entscheidung keineswegs irrational. Wer Kubernetes selbst betreibt, behält die volle Kontrolle über Architektur, Infrastruktur, Sicherheitsmodell, Release-Zyklen und Integrationsentscheidungen. Gerade für technisch starke Organisationen wirkt der Eigenbetrieb deshalb zunächst wie der konsequenteste Weg: Open Source statt proprietärer Plattform, eigene Standards statt Vorgaben eines Anbieters, maximale Anpassbarkeit statt produktisierter Einschränkungen.

Diese Argumente sind nicht falsch. Sie werden nur häufig unvollständig bewertet.

Denn der Eigenbetrieb eines Kubernetes-Clusters bedeutet nicht lediglich, dass ein Unternehmen eine technische Plattform selbst installiert, konfiguriert und nach eigenen Anforderungen erweitert. Er bedeutet, dass dieses Unternehmen dauerhaft die vollständige Verantwortung für den Lebenszyklus einer komplexen, verteilten Betriebsumgebung übernimmt, deren Stabilität nicht aus einer einzelnen Komponente entsteht, sondern aus dem Zusammenspiel von Netzwerk, Storage, Identity, Security, Observability, Automatisierung, Governance und operativer Erfahrung.

Genau an dieser Stelle entsteht die eigentliche Fehleinschätzung: Viele Organisationen verwechseln die Fähigkeit, Kubernetes aufzusetzen, mit der Fähigkeit, Kubernetes über Jahre zuverlässig, sicher, auditierbar und wirtschaftlich zu betreiben.

Ein Cluster ist schnell erstellt. Eine Plattform entsteht erst durch die konsequente Standardisierung der Betriebsrealität.

Dazu gehört, Kubernetes-Versionen nicht nur einzuspielen, sondern ihre Auswirkungen auf APIs, Controller, Admission Policies, Custom Resource Definitions, Ingress-Verhalten, Netzwerkkomponenten und abhängige Workloads systematisch zu bewerten. Dazu gehört, CNI- und CSI-Komponenten nicht als austauschbare Add-ons zu betrachten, sondern als kritische Bestandteile der Laufzeitumgebung, deren Fehlverhalten unmittelbare Auswirkungen auf Erreichbarkeit, Datenkonsistenz und Wiederherstellbarkeit haben kann. Dazu gehört, Sicherheitslücken nicht nur zu registrieren, sondern ihre Relevanz für die eigene Plattform unter Zeitdruck zu bewerten, Wartungsfenster zu planen und Änderungen so auszurollen, dass Produktionssysteme stabil bleiben.

Je länger ein Cluster produktiv betrieben wird, desto deutlicher zeigt sich, dass Kubernetes kein abgeschlossenes Infrastrukturprojekt ist. Es entwickelt sich zu einem langlebigen Betriebsprodukt mit einem kontinuierlichen Lebenszyklus.

Plattformen verändern Organisationen

Eine der am häufigsten unterschätzten Konsequenzen von Kubernetes besteht darin, dass sich nicht nur die technische Architektur verändert, sondern auch die Organisationsstruktur.

Sobald mehrere Entwicklungsteams dieselbe Plattform nutzen, entstehen automatisch interne Kunden. Entwickler erwarten reproduzierbare Entwicklungsumgebungen, standardisierte Deployment-Prozesse, Self-Service, verständliche Dokumentation und kurze Bereitstellungszeiten. Sicherheitsverantwortliche erwarten nachvollziehbare Richtlinien und revisionssichere Prozesse. Auditoren verlangen belastbare Nachweise, während das Management Verfügbarkeit, Planbarkeit und kalkulierbare Risiken fordert.

Damit verändert sich zwangsläufig die Rolle des Infrastrukturteams.

Aus Administratoren werden Plattformingenieure. Aus Infrastruktur entsteht ein internes Produkt. Und aus einer ursprünglich technischen Entscheidung wird eine organisatorische Verantwortung, die dauerhaft personelle Ressourcen, Governance-Strukturen und klare Produktverantwortung erfordert.

Genau aus diesem Grund hat sich in den vergangenen Jahren der Begriff Platform Engineering etabliert. Er beschreibt keine neue Technologie, sondern einen Perspektivwechsel. Die Plattform wird nicht mehr als Sammlung technischer Komponenten verstanden, sondern als Produkt, das den internen Entwicklungsteams einen standardisierten, sicheren und effizienten Arbeitsrahmen bereitstellt.

Wer Kubernetes einführt, führt daher fast zwangsläufig auch Platform Engineering ein – unabhängig davon, ob diese Entscheidung bewusst getroffen wurde.

Fazit

Die Diskussion um Build or Buy Kubernetes beginnt häufig mit technischen Fragestellungen. Welche Distribution soll eingesetzt werden? Welche Cloud ist die richtige? Welche Add-ons werden benötigt?

Diese Fragen sind wichtig, aber sie sind nicht entscheidend.

Die eigentliche Entscheidung lautet, ob ein Unternehmen bereit ist, die organisatorische Verantwortung für eine Plattform zu übernehmen, deren Lebenszyklus sich über viele Jahre erstreckt und deren Komplexität weit über den Betrieb eines Clusters hinausgeht.

Kubernetes ist heute keine Infrastrukturtechnologie mehr, sondern die Grundlage moderner Softwareplattformen. Wer diese Grundlage selbst aufbauen möchte, entscheidet sich nicht nur für eine technische Architektur, sondern für den langfristigen Aufbau einer Plattformorganisation.

Im zweiten Teil dieser Serie verlassen wir die technische Perspektive und betrachten die wirtschaftliche Realität des Plattformbetriebs. Wir analysieren, warum Hardware und Cloud-Ressourcen häufig den kleinsten Teil der Gesamtkosten ausmachen, welche Rolle Cognitive Load, Platform Teams und organisatorische Komplexität spielen und weshalb die teuerste Komponente einer Kubernetes-Plattform fast immer die Menschen sind, die sie betreiben.