Kubernetes ist Open Source, und der Betrieb eines eigenen Clusters ist eine legitime Wahl. Genauer betrachtet werden sollte, was ein Produktionscluster Ihnen laufend abverlangt – anhand der eigenen Dokumentation und der Release-Policy des Kubernetes-Projekts als Quelle, nicht anhand von Marketingaussagen.
Jede Kubernetes-Version hat ein Ablaufdatum
Das Kubernetes-Projekt pflegt Release-Branches für die drei neuesten Minor-Releases. Jedes Minor-Release erhält rund vierzehn Monate Patch-Unterstützung: zwölf Monate Standardunterstützung, dann eine zweimonatige Wartungsphase, nach der die Serie das End of Life erreicht und keine Korrekturen mehr erhält.
Stand September 2026 sind die aktiv gepflegten Minor-Releases 1.37, 1.36 und 1.35. Version 1.34 befindet sich in ihrem letzten Wartungsfenster und erreicht am 27. Oktober 2026 das End of Life. Version 1.33 hat das End of Life bereits am 28. Juni 2026 erreicht.
Zurückzufallen ist teuer, denn Upgrades dürfen keine Minor-Versionen überspringen. Die Version-Skew-Policy verlangt, dass kube-apiserver jeweils nur eine Minor-Version vorrückt, auch in Clustern mit einer einzelnen Instanz. Ein Cluster, der noch auf 1.33 läuft, braucht daher vier aufeinanderfolgende Control-Plane-Upgrades – 1.34, 1.35, 1.36 und 1.37 –, um wieder aktuell zu sein, und jedes davon erfordert eigene Vorbereitung, etwa die Prüfung, ob Ihre Admission Webhooks die API-Versionen verarbeiten können, die der neue Server ihnen sendet.
Nodes bringen eigenen Aufwand mit. In-Place-Minor-Version-Upgrades des kubelet werden nicht unterstützt: Jeder Node muss zuvor gedraint werden. Ein kubelet darf dem API-Server um bis zu drei Minor-Versionen hinterherhinken, aber die Dokumentation warnt, dass ein Cluster mit dauerhaft drei Versionen zurückliegenden kubelets diese upgraden muss, bevor das Control Plane überhaupt weiterziehen kann.
Hochverfügbarkeit ist ein Design, für das Sie verantwortlich sind
Ein einzelner Control-Plane-Node ist ein Single Point of Failure. Der Hochverfügbarkeits-Leitfaden von kubeadm beschreibt zwei Topologien. In der standardmäßigen Stacked-Topologie betreibt jeder Control-Plane-Node zugleich ein etcd-Mitglied, sodass der Verlust eines Nodes sowohl eine Control-Plane-Instanz als auch ein etcd-Mitglied kostet; die Dokumentation empfiehlt, mindestens drei Stacked-Control-Plane-Nodes zu betreiben. Die Alternative, externes etcd, trennt beides, benötigt aber mindestens drei Control-Plane-Hosts plus drei etcd-Hosts.
etcd braucht ein Quorum – eine Mehrheit seiner Mitglieder –, um Änderungen anzunehmen. Ein Cluster mit drei Mitgliedern toleriert den Ausfall eines Mitglieds, ein Cluster mit fünf Mitgliedern toleriert zwei, während ein viertes Mitglied keine zusätzliche Ausfalltoleranz bringt. Die Kubernetes-Dokumentation empfiehlt eine ungerade Anzahl von Mitgliedern und für die Produktion einen Cluster mit fünf Mitgliedern.
etcd reagiert außerdem empfindlich auf die Umgebung, in der es läuft:
- Datenträger und Netzwerk. Die Leistung von etcd hängt von Datenträger- und Netzwerk-I/O ab. Ressourcenmangel kann Heartbeat-Timeouts verursachen und den Cluster ohne Leader zurücklassen – und ein Cluster ohne Leader kann seinen Zustand nicht ändern, was bedeutet, dass keine neuen Pods mehr eingeplant werden können.
- Dedizierte Ressourcen. Die Dokumentation rät, etcd auf dedizierten Maschinen oder isolierten Umgebungen zu betreiben, damit seine Ressourcenanforderungen garantiert sind, und die eigene FAQ von etcd empfiehlt dringend SSDs.
- Zugriff entspricht Root. Der Zugriff auf etcd ist gleichbedeutend mit Root-Rechten im Cluster, daher sollte idealerweise nur der API-Server darauf zugreifen können, geschützt mit x509-TLS-Zertifikaten.
Ein Backup zählt erst, wenn Sie daraus wiederhergestellt haben
Die Kubernetes-Dokumentation ist deutlich: Wenn Ihr Cluster etcd als Backing Store nutzt, sorgen Sie für einen Backup-Plan für diese Daten. In der Praxis heißt das: geplante Snapshots mit etcdctl, gespeichert an einem Ort, der keine Ausfalldomäne mit dem Cluster teilt, und ein Wiederherstellungsverfahren mit etcdutl, das tatsächlich jemand geübt hat.
Snapshots erfordern außerdem sorgfältige Handhabung, denn sie enthalten alles, was der API-Server weiß. Standardmäßig speichert der API-Server Ressourcen in etcd im Klartext, ohne Verschlüsselung im Ruhezustand, sofern Sie sie nicht konfigurieren. Ein Snapshot eines unverschlüsselten Clusters kann daher Ihre Secrets enthalten.
Zertifikate laufen planmäßig ab
Von kubeadm erzeugte Client-Zertifikate laufen nach einem Jahr ab. kubeadm erneuert sie automatisch, wenn Sie ein Control-Plane-Upgrade durchführen; ein Cluster, der mindestens einmal im Jahr upgegradet wird, ist also versorgt – ein Cluster, der länger als ein Jahr ohne Upgrade bleibt, nicht. Sie können den Ablauf mit kubeadm certs check-expiration prüfen und manuell mit kubeadm certs renew all erneuern, was bei einem replizierten Control Plane auf jedem Control-Plane-Node ausgeführt werden muss.
Die Add-ons sind eigene Projekte mit eigenen Lebenszyklen
Ein Cluster ist mehr als sein Control Plane. Netzwerk, Ingress oder Gateway API, Storage-Treiber, Zertifikatsverwaltung, Metriken und Monitoring sind eigene Projekte, jedes mit eigenem Release-Zyklus, eigenen Versionen und eigenen End-of-Life-Daten. In einem selbst gehosteten Cluster ist es Ihre Aufgabe, sie alle im Blick zu behalten.
Im November 2025 kündigte das Kubernetes-Projekt die Einstellung von Ingress NGINX an, einem der am weitesten verbreiteten Ingress-Controller. Die Best-Effort-Wartung endete im März 2026: Es gibt keine weiteren Releases, Fehlerbehebungen oder Sicherheitsupdates. Bestehende Bereitstellungen laufen weiter und die Artefakte bleiben verfügbar, aber jede später entdeckte Schwachstelle wird nicht mehr gepatcht. Im Januar 2026 beschrieben das Kubernetes Steering Committee und das Security Response Committee es als kritische Infrastruktur für etwa die Hälfte der Cloud-nativen Umgebungen und drängten auf die Migration zur Gateway API oder zu einem anderen Controller.
Der eigene Migrationsleitfaden des Projekts fügt eine Warnung hinzu: Ingress NGINX hat implizite Verhaltensweisen, und eine Übersetzung, die korrekt aussieht, kann dennoch Ausfälle verursachen. Nichts davon ist ein Fehler von Kubernetes. Es ist das normale Leben eines großen Open-Source-Ökosystems – und genau die Arbeit, die ein selbst gehosteter Cluster auf Ihr Team verlagert.
Im direkten Vergleich
| Kategorie | Self-Hosted | Kube-DC Managed Cluster |
|---|---|---|
| Versionslebenszyklus | Sie verfolgen Release- und End-of-Life-Daten und upgraden jeweils eine Minor-Version, mit etwa vierzehn Monaten Support pro Minor-Release | Gestufte, vom Mandanten gesteuerte Upgrades: Control Plane und Worker-Pools werden getrennt, in Schritten aktualisiert. Sie wählen weiterhin die Zielversion und den Zeitpunkt |
| Control Plane | Drei oder mehr Control-Plane-Nodes, die Sie selbst entwerfen, absichern und patchen | Gehostete Control Planes laufen als verwaltete Pods auf der Plattform: Sie erhalten Ihre eigene Kubernetes-API und eine clusterspezifische PKI, ohne Master zu betreiben |
| etcd | Quorum-Dimensionierung, dedizierte Datenträger, TLS, Defragmentierung und Monitoring liegen bei Ihnen | Ein dedizierter oder geteilter Datastore, den die Plattform verwaltet, mit standardmäßig aktivierter vertikaler Autoskalierung von Control Plane und etcd |
| Backups | Sie entwerfen den Snapshot-Zeitplan, den Speicher und die Wiederherstellungsübungen | Geplante etcd-Snapshots, pro Cluster konfiguriert, mit optionaler Envelope-Verschlüsselung und Wiederherstellung – per Self-Service bei Single-Replica-Datastores, unterstützt bei Multi-Replica. Die Snapshots werden im S3-Speicher des Projekts auf der Plattform abgelegt; halten Sie daher eine eigene Kopie außerhalb der Plattform bereit, falls Sie eine außerhalb der Speicher-Ausfalldomäne der Plattform benötigen |
| Zertifikate | Einjährige kubeadm-Zertifikate, beim Upgrade oder von Ihnen erneuert | Clusterspezifische PKI- und etcd-TLS-Zertifikate werden automatisch mit dem Cluster bereitgestellt |
| Worker-Nodes | Sie stellen Nodes bereit, erstellen deren Images, patchen und ersetzen sie | Worker-Pools pro Pool dimensioniert (CPU, Arbeitsspeicher, Datenträger, Image), mit Autoscaling-Grenzen pro Pool |
| Metrics-API | Sie installieren und pflegen metrics-server | Vorinstalliert und funktionsfähig in unserem eigenen End-to-End-Test vom August 2026 |
| Zeit bis zum ersten Cluster | Stunden bis Tage der Einrichtung, plus laufende Wartung | Erstellt aus einem Projekt im Portal oder mit einem einzigen Manifest; die Plattformdokumentation beschreibt die Bereitstellung in Minuten |
| Bereitschaftsdienst | Ihr Team | 24/7-Support per E-Mail und Ticket mit einem Lösungsziel von 4 Stunden (MTTR), im Preis inbegriffen |
| Was bei Ihnen bleibt | Alles, von der Hardware bis zu den Workloads | Ihre Workloads, Zugriffskontrolle und die Add-ons, die Sie in Ihrem Cluster installieren – es ist ein vollständiger, vom Mandanten administrierter Kubernetes-Cluster |
Wann Self-Hosting die richtige Wahl ist
Wenn Ihr Team etcd bereits in der Produktion betreibt, den Release Notes von Kubernetes und Add-ons folgt, Wiederherstellungen übt und Bereitschaftsdienst abdeckt, ist Self-Hosting eine vernünftige Erweiterung bestehender Praxis. Es ist auch die richtige Wahl, wenn Sie Kontrolle brauchen, die ein Managed Service nicht bieten kann, etwa eine individuelle Control-Plane-Konfiguration oder eine vollständig isolierte Umgebung. Für ein Team ohne diese Fähigkeit wird jeder der obigen Abschnitte zu neuer, fortlaufender Arbeit.
Quellen
- Kubernetes releases and patch support policy
- Kubernetes patch releases: support period
- Kubernetes version skew policy
- kubeadm: options for highly available topology
- Operating etcd clusters for Kubernetes
- etcd FAQ: cluster size and failure tolerance
- Encrypting confidential data at rest
- Certificate management with kubeadm
- Ingress NGINX retirement: what you need to know
- Ingress NGINX: statement from the Steering and Security Response Committees
- Kube-DC platform datasheet
Die Plattform ansehen
Cloud Acropolis Kube-DC gibt Ihnen Ihre eigenen, vom Mandanten administrierten Kubernetes-Cluster – gehostete Control Planes, Worker-Pools und gestufte Upgrades – auf dedizierten vCPUs, Ceph-basiertem NVMe-Speicher, einer dedizierten öffentlichen IPv4-Adresse und S3-kompatiblem Objektspeicher. Sie bestellen und verwalten alles in einem Self-Service-Portal, mit 24/7-Support per E-Mail und Ticket und einem Lösungsziel von 4 Stunden inklusive. Jedes Paket enthält verschachtelte Kubernetes-Cluster, und eine geteilte GPU ist als Option verfügbar.
Kube-DC Kubernetes entdecken