Kubernetes on-premise bedeutet, dass du den kompletten Cluster selbst betreibst, von der Hardware oder den virtuellen Maschinen bis zur Control Plane. Bei Managed Kubernetes übernimmt ein Anbieter die Control Plane, und du kümmerst dich nur noch um deine Anwendungen. Dazwischen liegt ein dritter Weg, den viele Entscheider gar nicht auf dem Zettel haben: ein selbst betriebener Cluster auf gemieteter Infrastruktur, zum Beispiel k3s auf Hetzner Cloud. Welches Modell zu dir passt, hängt weniger von der reinen Technik ab als von deinem Anspruch an Kontrolle, Betriebsaufwand und Datenhoheit.
Ich betreibe produktionsreife k3s-Cluster auf Hetzner Cloud und berate mittelständische Unternehmen bei genau dieser Entscheidung. Alle meine Beiträge zum Betrieb von Kubernetes-Clustern findest du gesammelt auf der Seite Kubernetes. In diesem Beitrag ordne ich die drei Modelle ein, ohne dir eines davon zu verkaufen, denn für jedes davon gibt es gute Gründe und für jedes auch gute Gründe dagegen.
Drei Wege, einen Kubernetes-Cluster zu betreiben
Am einen Ende der Skala steht Managed Kubernetes bei einem großen Cloud-Anbieter: Du bekommst eine fertige Control Plane, meist gegen eine geringe monatliche Grundgebühr, und zahlst für die Nodes darunter. Am anderen Ende steht das eigene Rechenzentrum: eigene Server, eigenes Netzwerk, volle Verantwortung für jede Schicht. Dazwischen liegt der Mittelweg, den ich in meinen eigenen Projekten nutze: Du mietest Rechenleistung bei einem Cloud-Anbieter, installierst und betreibst Kubernetes aber selbst, mit einer schlanken Distribution wie k3s.
Diese drei Wege unterscheiden sich vor allem darin, wer welche Schicht verantwortet. Bei Managed Kubernetes trägt der Anbieter die Control Plane und oft auch einen Teil der Node-Wartung. Beim eigenen Rechenzentrum trägst du alles, von der Stromversorgung bis zum Kubernetes-Upgrade. Beim Mittelweg trägst du die Kubernetes-Ebene selbst, während der Cloud-Anbieter die physische Infrastruktur, das Rechenzentrum und die Netzanbindung stellt. Das ist kein akademischer Unterschied, sondern bestimmt, wie viel Personal du brauchst und wie schnell du im Ernstfall reagieren kannst.
Managed Kubernetes bei Hyperscalern: was du dafür abgibst
Managed Kubernetes ist der einfachste Einstieg. Du legst einen Cluster über die Weboberfläche oder per API an, die Control Plane läuft hochverfügbar, und Upgrades der Steuerungsebene übernimmt der Anbieter. Für Teams ohne eigenes Plattform-Team ist das ein enormer Vorteil, weil ein großer Teil der Kubernetes-Betriebslast einfach entfällt.
Der Preis dafür ist weniger Kontrolle. Du bekommst die Control Plane so, wie der Anbieter sie konfiguriert hat, mit seinem Update-Rhythmus und seinen Voreinstellungen. Wartungsfenster legt der Anbieter fest, nicht du. Und je nach Anbieter liegen deine Daten und deine Cluster-Metadaten außerhalb Europas oder bei einem Unternehmen, das nicht dem europäischen Recht unterliegt, selbst wenn die Rechenzentren physisch in Europa stehen. Für viele Anwendungen ist das unkritisch. Für mittelständische Unternehmen mit sensiblen Kundendaten, etwa aus dem Gesundheits- oder Finanzbereich, ist die Frage nach der Datenhoheit dagegen oft der entscheidende Punkt in der Auswahl, noch vor der reinen Kostenfrage.
Kubernetes on-premise im eigenen Rechenzentrum: volle Kontrolle, voller Aufwand
Am anderen Ende steht der komplette Eigenbetrieb: eigene Server, eigenes Netzwerk, eigene Racks. Der Vorteil liegt auf der Hand, du bestimmst jede Konfiguration selbst, von der Hardware über das Betriebssystem bis zur Kubernetes-Version, und deine Daten verlassen dein Haus nie. Für Unternehmen mit sehr strengen Auflagen oder mit bereits vorhandener Rechenzentrums-Infrastruktur kann das die richtige Wahl sein.
Der Preis dafür ist hoch, und er wird oft unterschätzt. Ein Cluster braucht redundante Hardware, eine belastbare Stromversorgung, Netzwerktechnik und Personal, das Server, Storage und Kubernetes selbst versteht. Dazu kommt die Wartezeit: Neue Hardware zu beschaffen und einzubauen, dauert Wochen bis Monate, während ein zusätzlicher Node in der Cloud in wenigen Minuten steht. Für ein Startup mit überschaubarem Technologie-Stack und wenigen Kunden ist ein eigenes Rechenzentrum fast immer überdimensioniert. Für etablierte Unternehmen mit vorhandenem Betriebsteam und klaren Compliance-Vorgaben kann es sich dagegen rechnen.
Der Mittelweg: k3s auf gemieteter Infrastruktur in deutscher Cloud
Genau zwischen diesen beiden Polen betreibe ich meine eigenen Cluster: mit k3s, einer schlanken Kubernetes-Distribution, auf gemieteten virtuellen Servern bei Hetzner, einem deutschen Cloud-Anbieter. Ich miete Rechenleistung, verzichte also auf eigene Hardware und die damit verbundene Beschaffungszeit, installiere und betreibe die Kubernetes-Ebene aber komplett selbst. Meine produktiven Cluster laufen mit drei Control-Plane-Nodes, verteilt über drei getrennte Rechenzentren, auf einem gehärteten Betriebssystem, das für genau diesen Zweck gebaut ist. Aufgesetzt und verwaltet wird die Infrastruktur mit Werkzeugen zur deklarativen Infrastrukturbeschreibung, sodass jeder Server reproduzierbar aus Code entsteht.
Dieser Weg gibt dir zwei Dinge gleichzeitig, die sich bei den beiden reinen Modellen ausschließen: volle Kontrolle über die Kubernetes-Konfiguration, ohne die Wartezeiten und den Personalbedarf eines eigenen Rechenzentrums. Ausgerollt wird bei mir alles per GitOps, sodass jede Änderung am Cluster nachvollziehbar in einem Git-Repository steht, statt manuell auf der Kommandozeile zu passieren. So sieht ein einfacher erster Blick auf einen frisch aufgesetzten Cluster aus:
kubectl get nodes -o wide
kubectl get nodes -L topology.kubernetes.io/region,topology.kubernetes.io/zone
Der erste Befehl zeigt dir alle Nodes mit ihrer internen und externen IP-Adresse und dem Betriebssystem-Image. Der zweite Befehl blendet zusätzlich die Region und die Verfügbarkeitszone jedes Nodes ein, sofern dein Cloud-Anbieter diese Labels setzt. Genau daran erkennst du, ob deine Control-Plane-Nodes wirklich über mehrere Rechenzentren verteilt sind oder alle im selben Gebäude stehen, was für die Ausfallsicherheit einen erheblichen Unterschied macht.
Der Nachteil dieses Modells ist ehrlich zu benennen: Du brauchst selbst Kubernetes-Wissen im Team, denn Upgrades, Sicherheitspatches und die Fehlersuche in der Control Plane liegen bei dir, nicht beim Anbieter. Wer dieses Wissen nicht hat und auch nicht aufbauen will, ist mit Managed Kubernetes besser bedient. Best Practices für Kubernetes on-premise oder auf gemieteter Infrastruktur beginnen deshalb nicht bei der Technik, sondern bei der ehrlichen Einschätzung, ob genug Betriebswissen im Team vorhanden ist oder aufgebaut werden kann.
Datenhoheit als eigenständiges Entscheidungskriterium
Datenhoheit wird in Kostenvergleichen oft übersehen, obwohl sie für viele mittelständische Unternehmen den Ausschlag gibt. Die Frage ist nicht nur, wo ein Rechenzentrum physisch steht, sondern welchem Recht der Betreiber unterliegt und wer im Zweifel Zugriff auf deine Daten und Konfigurationen erhalten könnte. Ein deutscher Cloud-Anbieter mit deutschem Firmensitz unterliegt anderen Rahmenbedingungen als ein internationaler Hyperscaler mit einer Niederlassung in Europa. Vier Fragen gehören dabei zusammen, und der Standort ist nur die erste: Wer kann technisch auf die Daten zugreifen, wer verwaltet die Schlüssel für Verschlüsselung im Ruhezustand, welche Unterauftragnehmer sind eingebunden, und was passiert im Betriebsmodell bei einer behördlichen Anfrage. Ein Cluster in einem deutschen Rechenzentrum, dessen Schlüssel beim Anbieter liegen, hat weniger Datenhoheit als einer im Ausland, dessen Schlüssel du selbst hältst. Das ist keine Aussage darüber, welches Modell technisch besser ist, sondern eine zusätzliche Dimension, die du neben Kosten und Betriebsaufwand einordnen solltest, besonders wenn du mit personenbezogenen oder vertraulichen Daten arbeitest.
Die drei Modelle im Vergleich
Die folgende Übersicht fasst zusammen, wie sich die drei Betriebsmodelle entlang der wichtigsten Kriterien unterscheiden. Sie ersetzt keine Einzelfallprüfung, hilft aber, das eigene Anforderungsprofil einzuordnen.
| Kriterium |
Managed Kubernetes |
Eigenes Rechenzentrum |
k3s auf gemieteter Cloud |
| Kontrolle über Control Plane |
gering, Anbieter bestimmt |
vollständig |
vollständig |
| Betriebsaufwand für Kubernetes |
gering |
hoch |
mittel bis hoch |
| Aufwand für physische Infrastruktur |
keiner |
hoch |
keiner |
| Zeit bis zusätzliche Kapazität steht |
Minuten |
Wochen bis Monate |
Minuten |
| Nötiges Kubernetes-Wissen im Team |
gering |
hoch |
hoch |
| Einfluss auf Datenhoheit |
abhängig vom Anbieter |
vollständig |
abhängig vom Anbieter, gut steuerbar bei deutschem Anbieter |
Häufige Fragen
Was ist der Unterschied zwischen Kubernetes on-premise und Managed Kubernetes?
Bei Kubernetes on-premise betreibst du jede Schicht selbst, von der Control Plane bis zur Hardware. Bei Managed Kubernetes übernimmt der Anbieter die Control Plane und meist auch deren Updates, du bringst nur deine Anwendungen ein. Dazwischen gibt es Mischformen wie einen selbst betriebenen Cluster auf gemieteter Cloud-Infrastruktur.
Ist Hetzner für einen produktiven Kubernetes-Cluster geeignet?
In meiner eigenen Praxis ja, ich betreibe darauf produktionsreife Cluster mit mehreren Control-Plane-Nodes über getrennte Rechenzentren hinweg. Hetzner selbst bietet allerdings keine fertige Managed-Kubernetes-Lösung an, du musst Kubernetes wie bei jedem anderen Infrastruktur-Anbieter selbst installieren und betreiben, etwa mit k3s.
Was kostet Managed Kubernetes im Vergleich zum Eigenbetrieb?
Das lässt sich ohne konkretes Szenario nicht seriös in Zahlen fassen, weil beide Modelle unterschiedliche Kostenarten haben: Managed Kubernetes verschiebt Personalkosten in laufende Gebühren, der Eigenbetrieb verschiebt laufende Gebühren in Personalaufwand. Eine ausführliche Einordnung der einzelnen Kostenblöcke findest du in Kubernetes Kosten: was ein Cluster kostet.
Welche Best Practices gelten für Kubernetes on-premise oder auf gemieteter Infrastruktur?
Am wichtigsten ist ehrliches Wissen im Team über Kubernetes-Interna, weil Upgrades und Fehlersuche in der Control Plane bei dir liegen. Dazu gehören eine deklarative, versionierte Konfiguration statt manueller Eingriffe, ein Backup-Konzept für den Cluster-Zustand und eine Verteilung der Control-Plane-Nodes über mehrere physisch getrennte Standorte, damit ein einzelner Ausfall nicht den ganzen Cluster mitreißt.
Wie du weitermachst
Welches Modell zu dir passt, hängt stark davon ab, wie dein Unternehmen aufgestellt ist. Einen ausführlicheren Blick auf typische Betriebsmodelle im deutschen Mittelstand findest du in Kubernetes im Mittelstand: Betriebsmodell, die konkreten Kostenblöcke rechne ich in Kubernetes Kosten: was ein Cluster kostet durch. Und wenn du dich für den Eigenbetrieb entscheidest, solltest du dir früh Gedanken über Backups machen, dazu mehr in Kubernetes Backup: etcd und Volumes sichern.
Mein Vorschlag: Schreibe für dein eigenes Unternehmen die drei Kriterien Kontrolle, Betriebsaufwand und Datenhoheit untereinander und gewichte sie ehrlich. Meistens ergibt sich die Antwort dann fast von selbst, lange bevor die erste Preisliste eines Anbieters überhaupt eine Rolle spielt.
Ausführlich mit allen Beispielen steht das in Kapitel 2 meines Kubernetes-Praxisbuchs bei Rheinwerk, wo ich unter anderem darauf eingehe, für welche Unternehmen Kubernetes überhaupt sinnvoll ist. Die offizielle Kubernetes-Dokumentation vergleicht Werkzeuge und Betriebsmodelle für Produktionsumgebungen, und den Quellcode der von mir genutzten Distribution findest du im k3s-Projekt auf GitHub.
