Wir betreiben die Steuerungsebene in Rechenzentren in Deutschland; ein Worker-Knoten kostet, was die Instanz im Katalog kostet. Drei ND3-Knoten, 300 GB Volumes und etcd-Sicherung: 267,60 €310,42 $ netto im Monat.
Je Cluster und Monat
0,00 €0,00 $
Die Steuerungsebene — der Teil des Clusters, der entscheidet, was wo läuft — betreiben wir; in der Stufe Standard berechnen wir dafür nichts.
ND3: 4 dedizierte vCPU, 16 GB RAM, je Monat
77,60 €90,02 $
Ein Worker-Knoten kostet im Cluster, was die Instanz im Katalog kostet: Stundensatz, gedeckelt auf den Monatspreis, ohne Aufschlag für Kubernetes.
Load Balancer Layer 4
enthalten
Zu jeder Stufe gehören ein Load Balancer Layer 4 am Eingang, die Treiber für Speicher und Load Balancer (CSI und CCM) und der Cluster Autoscaler, der bei Platzmangel Knoten nachlegt.
Zugesagte Verfügbarkeit
99,99 %
Ab der Stufe Hochverfügbar läuft die Steuerungsebene über drei baulich getrennte Brandabschnitte; die Stufe Hochverfügbar kostet 65,70 €76,21 $ je Cluster und Monat. Zugesagt ist die Erreichbarkeit des API-Servers.
Ohne Vertragsbindung
monatlich
Die Kubernetes-API bleibt unverändert: Ihre Manifeste und Helm-Charts laufen auf jedem anderen konformen Cluster weiter, sobald die plattformeigenen Namen und Annotationen angepasst sind.
Standorte in drei Städten
4
Zur Wahl stehen Frankfurt am Main, Berlin und München; betrieben wird die Plattform von einem Unternehmen mit Sitz in Köln, nach deutschem und europäischem Recht.
Managed Kubernetes verschiebt Arbeit, es lässt sie nicht verschwinden. Zuerst steht, was wir ohne Ticket übernehmen; danach, was bei Ihnen bleibt.
Ohne Wartungsvertrag: Betrieb und Wartung dieser Teile sind in den Preisen dieser Seite enthalten.
Alles, was von Ihrer Anwendung abhängt — und was deshalb niemand für Sie entscheiden kann.
Die Steuerungsebene läuft auf unserer Hardware, wird von uns aktualisiert und überwacht — und kostet in der Stufe Standard 0,00 €0,00 $. Das ist kein Einführungsangebot, sondern das Modell.
Ein Kubernetes-Cluster besteht aus zwei Teilen: Die Steuerungsebene entscheidet, was wo läuft, die Worker-Knoten führen aus. Berechnet werden die Worker-Knoten und, was Sie an Speicher und Netz dazu belegen; für die Steuerungsebene fällt erst ab der Stufe Hochverfügbar der Aufpreis der Stufe an.
Worker-Knoten sind gewöhnliche Cloud-Instanzen aus dem Instanzkatalog: derselbe Stundensatz, dieselbe Deckelung auf den Monatspreis. Bei stündlicher Abrechnung kostet ein Knoten, den der Autoscaler nach zwei Stunden wieder entfernt, zwei Stunden.
Das Inklusivvolumen an Datenverkehr hängt am Knoten, nicht am Cluster: Jeder Worker bringt sein eigenes mit, und die Summe steht dem gesamten Cluster zur Verfügung. Eine Knotengruppe aus drei ND3-Knoten trägt damit 90 TB ausgehenden Verkehr im Monat, unabhängig davon, über welchen Knoten er abfließt.
Steuerungsebene, Stufe Standard
Je Cluster und Monat; Betrieb und Überwachung liegen bei uns.
Load Balancer Layer 4
TCP und UDP mit Proxy Protocol v2, am Eingang des Clusters. Weitere und größere Load Balancer werden berechnet; der Betrag des enthaltenen wird dabei gutgeschrieben.
Öffentliche Anbindung je Knoten
1 × IPv4 + /64 IPv6
Grundgebühr der Private Registry
Berechnet wird der belegte Speicher
Wartung im Vorgabefenster
Festes Wochenfenster, die Knoten werden nacheinander getauscht. Zeiten und Ankündigungsfrist regelt das SLA.
Zum Leistungsumfang jeder Stufe gehören außerdem: CSI- und CCM-Treiber · Cluster Autoscaler.
Alle drei Stufen liefern dieselbe Kubernetes-Version, dieselben Treiber und dieselben Worker. Was sich unterscheidet, sind vor allem die Ausfallsicherheit der Steuerungsebene, die Obergrenze für Knoten und der Nachweisumfang.
Control Plane kostenlos — Sie zahlen nur die Worker-Nodes.
0,00 €0,00 $Steuerungsebene, je Cluster und Monat
Beispielcluster in dieser Stufe
267,60 €310,42 $netto im Monat
3 × ND3, 300 GB Volumes, etcd-Sicherung
Control Plane über drei Brandabschnitte verteilt.
65,70 €76,21 $Steuerungsebene, je Cluster und Monat
Beispielcluster in dieser Stufe
324,30 €376,19 $netto im Monat
3 × ND3, 300 GB Volumes, etcd-Sicherung
Für regulierte Umgebungen mit Nachweispflicht.
177,84 €206,29 $Steuerungsebene, je Cluster und Monat
Beispielcluster in dieser Stufe
436,44 €506,27 $netto im Monat
3 × ND3, 300 GB Volumes, etcd-Sicherung
| Merkmal | Standard0,00 €0,00 $ / Monat | Hochverfügbar65,70 €76,21 $ / Monat | Enterprise177,84 €206,29 $ / Monat |
|---|---|---|---|
| Verfügbarkeitszusagegemessen an der Erreichbarkeit des API-Servers; die Gutschriftenstaffel des SLA gilt in jeder Stufe | 99,9 % | 99,99 % | 99,99 % |
| Worker-Knoten je Cluster | 100 | 500 | 2.000 |
| Steuerungsebene | ein Brandabschnitt, verwaltet | drei Brandabschnitte, aktiv/aktiv | dediziert, ohne fremde Mandanten |
| etcd-Sicherung | tägliche Snapshots, als Option buchbar | im Preis der Stufe enthalten | im Preis der Stufe enthalten; WORM-Sperre über die Sicherungsstufe „Vault Backup (365 Tage)“ buchbar |
| API-Endpunkt | öffentlich, mit IP-Freigabeliste | zusätzlich privat im vRack (Ihr privates Netz) | zusätzlich privat im vRack |
| Private Registrysiehe Abschnitt Registry | eine Registry je Projekt | mehrere Registrys, Spiegel inklusive | mehrere Registrys, Signaturpflicht möglich |
| Audit-Log | 7 Tage in der Konsole | Export nach Object Storage oder Loki | Export, revisionssicher |
| Härtung | Voreinstellungen des Kubernetes-Projekts | Voreinstellungen des Kubernetes-Projekts | CIS-Benchmark (Härtungskatalog), dokumentiert |
| Nachweise | ISO 27001 | ISO 27001 | ISO 27001 und BSI C5 |
| SupportReaktionszeiten nach SLA: Im Preis jeder Stufe ist der Basis-Support enthalten, Erstreaktion in 8 Stunden bei kritischen Störungen, erreichbar Montag bis Freitag von 08:00 bis 18:00 Uhr. | Ticket | Ticket | Ticket und Eskalationspfad rund um die Uhr |
Schnellere Erstreaktion als im Basis-Support? Supportstufen im SLA
Fragen zur Stufe Enterprise oder zu den Nachweisen? Rückruf vereinbaren
Stellen Sie Stufe, Worker und Volumes ein: Der Rechner weist jeden Posten mit Menge und Einzelpreis aus und übergibt die Auswahl an den Konfigurator — die Vorgabe ist der Beispielcluster mit 3 × ND3, je 100 GB Volume und etcd-Sicherung.
Die Steuerungsebene betreiben wir in jeder Stufe; die Stufe entscheidet über ihre Verteilung und die zugesagte Verfügbarkeit (SLA). Worker und Volumes kosten in jeder Stufe dasselbe.
Preis je Knoten und Monat. Für Produktionscluster empfehlen wir Zuschnitte mit dedizierten Kernen.
Alle Worker dieser Knotengruppe haben denselben Zuschnitt. Weitere Gruppen und die automatische Skalierung stellen Sie im Konfigurator ein.
Persistenter Speicher auf Block Storage NVMe, 0,0860 €0,0998 $ je GB und Monat. Berechnet wird die bereitgestellte Menge.
Im Zustandsspeicher etcd steht jedes Objekt, das Sie im Cluster anlegen — nicht die Daten auf Ihren Volumes. Ist sie abgewählt, verantworten Sie die Sicherung selbst. In den Stufen Hochverfügbar und Enterprise ist sie im Stufenpreis enthalten.
Knoten mit Grafikkarten bilden eine eigene Knotengruppe, etwa für Inferenz. Als Worker zugelassen ist jeder Zuschnitt des Katalogs, auch die zehn GPU-Zuschnitte — zum Stundensatz der Instanz und auf deren Monatspreis gedeckelt. Das Geräte-Plugin für NVIDIA wird beim Anlegen der Gruppe ausgerollt.
Eine Knotengruppe mit Grafikkarten darf auf null herunterskalieren: Knoten, die der Autoscaler abschaltet, kosten bei stündlicher Abrechnung ab der Abschaltung nichts mehr.
Gerechnet ist der Dauerbetrieb über den ganzen Monat; bei stündlicher Abrechnung ist der Monatspreis die Obergrenze. Ein Load Balancer Layer 4 ist im Cluster enthalten. Nicht eingerechnet sind die Private Registry und weitere Load Balancer. Diese Posten wählen Sie im Konfigurator, ebenso Standort, Version und weitere Knotengruppen.
Ein Zuschnitt legt vCPU, Arbeitsspeicher und lokale NVMe eines Knotens als feste Kombination fest; in der Kommandozeile und in Terraform heißt er flavor. Zuschnitte mit geteilten Kernen empfehlen wir für Produktionscluster nicht. Auf jedem Knoten laufen dauerhaft Kubernetes-eigene Prozesse mit — bei geteilten Kernen verbrauchen sie einen Teil der Rechenzeit, die dem Knoten zusteht, noch bevor die Anwendung läuft.
Monatspreis ist zugleich die Obergrenze der stundenweisen Abrechnung
| Konfiguration | vCPU | RAM | NVMe lokal | Preis / Monat |
|---|---|---|---|---|
| ND2AMD EPYC (dediziert) | 2 | 8 GB | 80 GB | 38,80 €45,01 $ |
| ND3AMD EPYC (dediziert) | 4 | 16 GB | 160 GB | 77,60 €90,02 $ |
| ND4AMD EPYC (dediziert) | 8 | 32 GB | 240 GB | 138,99 €161,23 $ |
| ND5AMD EPYC (dediziert) | 16 | 64 GB | 360 GB | 276,49 €320,73 $ |
| NM4AMD EPYC (dediziert) | 8 | 64 GB | 320 GB | 193,30 €224,23 $ |
| NA4Ampere Altra (shared) | 8 | 16 GB | 160 GB | 21,49 €24,93 $ |
| NA5Ampere Altra (shared) | 16 | 32 GB | 320 GB | 41,49 €48,13 $ |
| NG-RTX4000Intel Core i5-13500 (dediziert) | 20 | 64 GB | 1 TB | 214,00 €248,24 $ |
| NG-L4AMD EPYC (dediziert) | 8 | 48 GB | 400 GB | 540,00 €626,40 $ |
GPU-Zuschnitte — in dieser Liste NG-RTX4000 und NG-L4 — gehören in eine eigene Knotengruppe mit dem Taint nvidia.com/gpu. Ein Taint ist eine Sperrmarkierung am Knoten: Dort landen nur Arbeitslasten, die eine Grafikkarte wirklich brauchen und die Markierung ausdrücklich tolerieren.
Beispiele, keine Kunden: ohne Namen, ohne Zitate. Jeder Betrag ist mit den Sätzen dieser Seite gerechnet, und jedes Beispiel lässt sich als Vorlage in den Konfigurator übernehmen.
Kundenportal
Ausgangslage
Ein Kundenportal mit einer Datenbank im Cluster. Fällt ein Brandabschnitt aus, soll die Kubernetes-API erreichbar bleiben, und die Daten liegen auf eigenen Volumes.
Entscheidung
Stufe Hochverfügbar, zugesagt mit 99,99 % Verfügbarkeit; dazu 3 × ND3 und 300 GB Block Storage NVMe, also 100 GB je Knoten. Im Betrag stehen Steuerungsebene, Knoten und Volumes; ein Load Balancer Layer 4 ist im Cluster enthalten, die etcd-Sicherung in der Stufe. Eine Private Registry ist nicht eingerechnet.
Auswertung
Ausgangslage
Nächtliche Auswertungen und Exportläufe: einige Stunden hohe Last, sonst wenig. Die Dienste, die Aufträge annehmen und einreihen, laufen durchgehend.
Entscheidung
Stufe Standard mit zwei Knotengruppen: 2 × ND2 tragen die durchlaufenden Dienste; die zweite Gruppe hält 1 × ND4 vor, damit der erste Auftrag nicht auf einen Knotenstart wartet, und wächst mit dem Cluster Autoscaler auf bis zu acht Knoten. Im Betrag stehen die drei Knoten der Untergrenze und die etcd-Sicherung „Snapshots (7 Tage)“; ein Load Balancer Layer 4 ist im Cluster enthalten. Volumes und eine Private Registry sind nicht eingerechnet. Jeder weitere Knoten der zweiten Gruppe kostet 0,1904 €0,2209 $ je Stunde; erreicht jede Gruppe ihre Obergrenze, sind es höchstens 1.198,52 €1.390,28 $ im Monat.
Ergebnis
225,59 €261,68 $
je Monat, netto
Als Vorlage konfigurieren — Stapelverarbeitung mit Lastspitzen
Sprachmodell
Ausgangslage
Ein Sprachmodell beantwortet Anfragen einer Anwendung. Die Anwendung braucht gewöhnliche Knoten, das Modell Grafikkarten — beides im selben Cluster, in getrennten Knotengruppen.
Entscheidung
Stufe Standard mit zwei Knotengruppen: 3 × ND3 mit 300 GB Block Storage NVMe für die Anwendung, dazu 2 × NG-RTX4000 als eigene Gruppe für das Modell. Im Betrag stehen beide Knotengruppen, die Volumes und die etcd-Sicherung „Snapshots (7 Tage)“; ein Load Balancer Layer 4 ist im Cluster enthalten. Eine Private Registry ist nicht eingerechnet.
Vom ersten Cluster bis zum ersten Deployment — mit kubectl, Helm und der GitOps-Kette, die Sie schon benutzen.
Sie wählen eine der drei Stufen und einen Standort; zur Wahl stehen Frankfurt am Main, Berlin und München. Die Steuerungsebene steht in unter fünf Minuten; wir richten sie ein und betreiben sie. In der Stufe Standard wird sie nicht berechnet; ab der Stufe Hochverfügbar läuft sie über drei Brandabschnitte, und ihre Verfügbarkeit ist mit 99,99 % zugesagt.
Eine Knotengruppe fasst Knoten gleichen Zuschnitts zusammen; im Konfigurator legen Sie bis zu sechs Gruppen an, Grafikkarten als eigene Gruppe neben den übrigen. Je Gruppe setzen Sie eine Unter- und eine Obergrenze. Dazwischen legt der Cluster Autoscaler Knoten nach, sobald Pods — die kleinsten Einheiten, in denen Ihre Container laufen — keinen Platz finden, und gibt Knoten wieder ab, deren Pods auf den übrigen Platz haben. Die Bereitstellung der Instanz hinter einem neuen Knoten dauert im Mittel 35 Sekunden, zugesagt unter 60 Sekunden; danach meldet sich der Knoten am Cluster an.
Sie laden die kubeconfig, die Zugangsdatei für den Cluster, und arbeiten mit kubectl, Helm und GitOps-Werkzeugen wie Argo CD oder Flux unverändert weiter: Der Cluster spricht die Kubernetes-API, eine eigene Schnittstelle steht nicht dazwischen. Läuft Ihr Cluster bereits andernorts, ziehen Sie selbst um: einen neuen Cluster anlegen, die Container-Abbilder in die Private Registry übertragen, Manifeste oder die GitOps-Quelle auf den neuen Cluster richten, zuletzt die Volume-Daten übertragen und den DNS-Eintrag umstellen. Beide Cluster laufen nebeneinander, bis der neue den Verkehr trägt.
Was eine Einkaufs- oder Datenschutzprüfung zuerst fragt: wo der Cluster läuft, wovon er getrennt ist und was sich belegen lässt — mit dem Vertrag zur Auftragsverarbeitung nach Art. 28 DSGVO, dem Zertifikat nach ISO 27001 und dem Testat nach BSI C5:2020.
Ein Cluster läuft an dem Standort, den Sie bei der Bestellung wählen — zur Wahl stehen Frankfurt am Main, Berlin und München, also Rechenzentren in Deutschland. Betrieben wird die Plattform von einem Unternehmen mit Sitz in Köln, nach deutschem und europäischem Recht und ohne Muttergesellschaft in einem Drittstaat. Der Vertrag zur Auftragsverarbeitung nach Art. 28 DSGVO kommt mit dem Hauptvertrag.
Der API-Endpunkt eines Clusters ist öffentlich erreichbar und über eine IP-Freigabeliste eingegrenzt; ab der Stufe Hochverfügbar gibt es ihn zusätzlich privat im vRack, Ihrem privaten Netz. In der Stufe Enterprise läuft die Steuerungsebene dediziert, ohne fremde Mandanten.
Nach ISO 27001 liegt ein Zertifikat über das Managementsystem für Informationssicherheit vor. Nach BSI C5:2020 liegt ein Testat vom Typ 2 vor: das Urteil einer Wirtschaftsprüfungsgesellschaft über die Wirksamkeit der Kontrollen in einem Prüfzeitraum von zwölf Monaten, kein Zertifikat. Sein Geltungsbereich nennt Kubernetes als Dienst; in der Stufentabelle steht der C5-Nachweis bei der Stufe Enterprise.
Die Fassung C5:2026 ist seit dem 07.04.2026 veröffentlicht und für Prüfzeiträume ab dem 01.06.2027 anzuwenden — bis dahin gilt C5:2020.
Die Private Registry prüft Abbilder auf bekannte Schwachstellen; in der Stufe Enterprise lässt sich zusätzlich eine Signaturpflicht für Abbilder setzen. Das Audit-Log, das Protokoll der Zugriffe auf die Kubernetes-API, steht je nach Stufe in der Konsole oder als Export bereit.
Fällt ein Knoten aus, starten seine Pods auf den übrigen neu. Bei einem Versionswechsel wird ein Knoten nach dem anderen ersetzt; PodDisruptionBudgets — die Mindestzahl laufender Pods je Anwendung — werden dabei eingehalten.
Vier Komponenten verbinden Kubernetes mit unserer Infrastruktur. Sie sind installiert, versioniert und werden mit dem Cluster aktualisiert — ohne dass Sie ein Helm-Chart pflegen müssen.
Der Speichertreiber csi.block.entronyx.cloud stellt Volumes auf Block Storage NVMe bereit, csi.file.entronyx.cloud bindet NFS-Freigaben ein. Vier StorageClasses (Speicherprofile) sind vorinstalliert, nvme-delete ist die Voreinstellung. Welche Klasse ein Standort bedient, folgt dem Speicherkatalog: Shared File Storage gibt es in Frankfurt am Main und München, Block Storage Kapazität in Frankfurt am Main und Berlin.
Der CCM verbindet Kubernetes mit unserer API: Er setzt auf jedem Knoten die Provider-ID (die Kennung der Instanz dahinter), entfernt gelöschte Instanzen aus dem Cluster und legt für jeden Service vom Typ LoadBalancer eine öffentliche Adresse an.
Je Knotengruppe setzen Sie eine Unter- und eine Obergrenze. Kann ein Pod wegen fehlender Kapazität nicht platziert werden, legt der Autoscaler einen neuen Knoten an. Bereitstellung der Instanz: im Mittel 35 Sekunden, zugesagt unter 60 Sekunden. Knotengruppen mit Grafikkarten und für Stapelläufe dürfen auf null herunterskalieren; der Konfigurator legt jede Gruppe mit mindestens einem Knoten an. Die Zahl der Pods regelt der HorizontalPodAutoscaler: Ab Kubernetes 1.37 skaliert er bis auf null Pods — nur bei Objekt- und externen Metriken und als Beta-Funktion, die eingeschaltet ausgeliefert wird.
Cilium, das Netzwerk-Plugin des Clusters, läuft im eBPF-Modus und ersetzt kube-proxy. Den Verkehr von außen steuern Sie über die Gateway API, die Nachfolgerin der Ingress-Schnittstelle: Cilium setzt Gateway, HTTPRoute, GRPCRoute, TLSRoute, TCPRoute und UDPRoute selbst um, ein zusätzlicher Controller läuft dafür nicht. Ingress-Objekte mit der Klasse cilium bedient das Netzwerk-Plugin weiter. Die Zertifikate stellt cert-manager aus, über DNS-01 gegen unser Anycast-DNS. Das Pod-Netz ist in der Voreinstellung ein /16.
Für neue Cluster stehen drei Minor-Versionen zur Wahl. Eine neue Version ist spätestens sechs Wochen nach ihrer Veröffentlichung durch das Kubernetes-Projekt wählbar; Voreinstellung wird sie, sobald Netzwerk-Plugin, Cluster Autoscaler und Rancher sie unterstützen.
Das ist der Grund, warum heute 1.36 Voreinstellung ist und 1.37 wählbar: Netzwerk-Plugin und Rancher führen 1.37 noch nicht in ihrer Kompatibilitätsliste, und der Cluster Autoscaler ist für 1.37 noch nicht veröffentlicht. Cluster auf 1.37 lassen sich deshalb noch nicht an Managed Rancher anbinden.
Das Kubernetes-Projekt pflegt jede Minor-Version rund vierzehn Monate: zwölf mit allen Korrekturen, danach zwei, in denen nur noch Sicherheits- und kritische Korrekturen erscheinen. Das Ende dieser vierzehn Monate steht in der Versionstabelle unter „Korrekturen bis“. Es folgen zwei Monate Übergang, in denen keine neuen Korrekturen des Kubernetes-Projekts erscheinen. Sind Sie bis dahin nicht selbst gesprungen, heben wir die Steuerungsebene im angekündigten Wartungsfenster auf die nächste Minor-Version an — ab dem Monat, der dort unter „Anhebung ab“ steht. Für ältere Versionen berechnen wir bis zur Anhebung keinen Aufpreis. „Verfügbar seit“ nennt den Monat, seit dem eine Version bei uns wählbar ist; die vierzehn Monate zählen ab ihrer Veröffentlichung durch das Kubernetes-Projekt.
| Version | |
|---|---|
| 1.37 neu verfügbar seit 10/2026 Korrekturen bis 10/2027 Anhebung ab 12/2027 | neu |
| 1.36 Voreinstellung verfügbar seit 04/2026 Korrekturen bis 06/2027 Anhebung ab 08/2027 | Voreinstellung |
| 1.35 gepflegt verfügbar seit 12/2025 Korrekturen bis 02/2027 Anhebung ab 04/2027 | gepflegt |
| 1.34 läuft aus verfügbar seit 08/2025 Korrekturen bis 10/2026 Anhebung ab 12/2026 | läuft aus |
Stand: Oktober 2026
Prüfung auf API-Versionen, die es in der Zielversion nicht mehr gibt, fehlende PodDisruptionBudgets (die Mindestzahl laufender Pods je Anwendung) und Add-ons, deren Version nicht zur Zielversion passt. Das Ergebnis ist eine Liste, keine Vermutung.
Die Steuerungsebene wird zuerst angehoben. In der Stufe Hochverfügbar bleibt der API-Server während des gesamten Vorgangs erreichbar, weil die drei Instanzen nacheinander wechseln.
Jede Knotengruppe wird mit Surge 1 erneuert: Ein neuer Knoten kommt hinzu, ein alter wird abgeriegelt, geleert und entfernt. PodDisruptionBudgets werden eingehalten, notfalls wartet der Vorgang.
Zwischen API-Server und Kubelet — dem Dienst, der auf jedem Knoten die Container startet — dürfen höchstens drei Minor-Versionen liegen. Solange dieser Abstand eingehalten ist, dürfen Knotengruppen bewusst zurückbleiben — etwa eine Gruppe mit besonders sensiblen Arbeitslasten. Eine Gruppe mit drei Versionen Abstand blockiert allerdings das nächste Anheben der Steuerungsebene: Diese Gruppe muss vorher nachziehen.
Ein Downgrade der Steuerungsebene ist nicht möglich, weil etcd sein Schema migriert. Der Rückweg führt über einen neuen Cluster in der alten Version und das Einspielen Ihrer Manifeste.
Je Version drei Änderungen, die im Betrieb eines verwalteten Clusters zählen — wo es einen Reifegrad gibt, steht er dabei.
Eine entfernte API-Version löscht keine Objekte. Was im Cluster liegt, bleibt liegen und läuft weiter — erst der nächste Apply, das nächste Helm-Upgrade oder der nächste GitOps-Abgleich schlägt fehl, oft Monate nach dem Upgrade. Der Preflight-Lauf durchsucht deshalb den gesamten Objektbestand und nicht nur Ihre Manifeste im Repository. Findet er eine Verwendung, bricht das Upgrade ab, statt den Fehler in die Zukunft zu verschieben. Seit 1.32 führt der Leitfaden des Kubernetes-Projekts keine weitere entfernte stabile oder Beta-API-Version.
| API-Version | ||
|---|---|---|
| networking.k8s.io/ | Ingress, IngressClass | networking.k8s.io/v1 |
| batch/ | CronJob | batch/v1 |
| policy/ | PodDisruptionBudget | policy/v1 |
| autoscaling/ | HorizontalPodAutoscaler | autoscaling/v2 |
| flowcontrol.apiserver.k8s.io/ | FlowSchema, PriorityLevelConfiguration | flowcontrol.apiserver.k8s.io/v1 |
| flowcontrol.apiserver.k8s.io/ | FlowSchema, PriorityLevelConfiguration | flowcontrol.apiserver.k8s.io/v1 |
Bei CronJob und PodDisruptionBudget genügt meist die neue Versionsangabe im Manifest. Bei Ingress und HorizontalPodAutoscaler ändern sich zusätzlich Feldnamen. Was eine Version darüber hinaus ändert, kündigen wir mit ihrer Freigabe in den Versionshinweisen an.
Diese Änderungen entfernen keine API-Version, und kein Apply scheitert an ihnen: Das Objekt wird angenommen und verhält sich anders — oder der Baustein dahinter erhält keine Korrekturen mehr.
| Änderung | |
|---|---|
| Endpoints-API abgekündigt seit 1.33 Die API ist abgekündigt, aber nicht entfernt. Werkzeuge und Controller, die Endpoints lesen oder schreiben, auf EndpointSlices umstellen. | Die API ist abgekündigt, aber nicht entfernt. Werkzeuge und Controller, die Endpoints lesen oder schreiben, auf EndpointSlices umstellen. |
| gitRepo-Volume endgültig abgeschaltet seit 1.36 Pods mit einem gitRepo-Volume starten nicht mehr. | Pods mit einem gitRepo-Volume starten nicht mehr. |
| Service.spec.externalIPs abgekündigt seit 1.36 Das Feld wirkt vorerst weiter; die Entfernung ist für 1.43 geplant. | Das Feld wirkt vorerst weiter; die Entfernung ist für 1.43 geplant. |
| SELinuxMount eingeschaltet seit 1.37 Betrifft nur Knoten mit SELinux: Pods, die dasselbe Volume mit unterschiedlichen SELinux-Labels einhängen, starten dort unter Umständen nicht. | Betrifft nur Knoten mit SELinux: Pods, die dasselbe Volume mit unterschiedlichen SELinux-Labels einhängen, starten dort unter Umständen nicht. |
| ingress-nginx eingestellt seit 24.03.2026 Das Projekt erhält keine Sicherheitskorrekturen mehr. Nachfolge ist die Gateway API; die Ingress-API selbst bleibt bestehen. | Das Projekt erhält keine Sicherheitskorrekturen mehr. Nachfolge ist die Gateway API; die Ingress-API selbst bleibt bestehen. |
Die Werte sind harte Grenzen, keine Empfehlungen. Wer sie ausreizen will, sollte vorher mit uns über die Verteilung der Knotengruppen sprechen — viele kleine Knoten in einer Gruppe verhalten sich anders als wenige große in mehreren.
| Merkmal | Standard | Hochverfügbar | Enterprise |
|---|---|---|---|
| Worker-Knoten je Cluster | 100 | 500 | 2.000 |
| Knotengruppen je Cluster | 6 | 6 | 6 |
| Load Balancer je Cluster | 8 | 8 | 8 |
| Cluster je Projekt | 5 | 25 | unbegrenzt |
| Pods je Knoten | 110 | 110 | 110 |
| etcd-Datenbankgröße | 8 GB | 8 GB | 8 GB |
| Persistente Volumes je KnotenGrenze des Block-Storage-Anschlusses | 16 | 16 | 16 |
Cluster, Knotengruppen, die Private Registry und Autoscaling-Grenzen sind Ressourcen im Terraform-Provider und lassen sich ebenso über die Kommandozeile einrichten. Was Sie in der Konsole klicken können, können Sie auch versionieren.
# Cluster anlegen, Stufe ha: Steuerungsebene über drei Brandabschnitte
entronyx kube cluster create prod-fra \
--version 1.36 --tier ha --region fra1 --private-endpoint
# Knotengruppe mit Autoscaling zwischen 3 und 12 Workern
entronyx kube nodepool create workers \
--cluster prod-fra --flavor nd3 --min 3 --max 12 --autoscale
# Zugangsdaten in die bestehende kubeconfig einhängen
entronyx kube kubeconfig prod-fra --merge
kubectl get nodes -o wide
kubectl get storageclass
# NAME PROVISIONER
# nvme-delete (default) csi.block.entronyx.cloud
# nvme-retain csi.block.entronyx.cloud
# capacity-delete csi.block.entronyx.cloud
# shared-nfs csi.file.entronyx.cloud
resource "entronyx_kube_cluster" "prod" {
# Stufe ha: Steuerungsebene über 3 Brandabschnitte.
# entronyx_vrack.prod ist Ihr privates Netz, gesondert angelegt.
name = "prod-fra"
region = "fra1"
version = "1.36"
tier = "ha"
private_endpoint = true
vrack = entronyx_vrack.prod.id
etcd_backup {
interval = "15m"
}
}
resource "entronyx_kube_nodepool" "workers" {
cluster = entronyx_kube_cluster.prod.id
name = "workers"
flavor = "nd3"
autoscale = true
min_nodes = 3
max_nodes = 12
labels = { workload = "general" }
}
resource "entronyx_kube_nodepool" "inference" {
cluster = entronyx_kube_cluster.prod.id
name = "inference"
flavor = "ng-l4"
autoscale = true
min_nodes = 0 # skaliert bis auf null herunter
max_nodes = 4
taints {
key = "nvidia.com/gpu"
value = "true"
effect = "NoSchedule"
}
}
version-Angabe löst ein Upgrade aus — erst der Steuerungsebene, dann rollierend der Knotengruppen.apiVersion: v1
kind: Service
metadata:
name: web
annotations:
service.beta.entronyx.cloud/proxy-protocol: "true"
service.beta.entronyx.cloud/health-check-path: "/healthz"
service.beta.entronyx.cloud/algorithm: "least-connections"
spec:
# Der Cloud Controller legt die öffentliche IP an
type: LoadBalancer
selector:
app: web
ports:
- port: 443
targetPort: 8443
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: data
spec:
# nvme-retain: Das Volume überlebt das Löschen des Claims
storageClassName: nvme-retain
accessModes: [ReadWriteOnce]
resources:
requests:
storage: 100Gi
storageClassName greift nvme-delete.# Eingang für HTTP über die Gateway API — statt des Service vom
# Typ LoadBalancer aus service-pvc.yaml. Das Gateway bringt seinen
# Load Balancer mit, terminiert TLS und spricht danach
# unverschlüsselt mit dem Backend; der Service bleibt im Cluster
apiVersion: v1
kind: Service
metadata:
name: web
spec:
type: ClusterIP
selector:
app: web
ports:
- port: 80
targetPort: 8080
---
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: eingang
annotations:
# cert-manager stellt das Zertifikat aus und legt das Secret an
cert-manager.io/cluster-issuer: <ihr-aussteller>
spec:
gatewayClassName: cilium
listeners:
- name: https
protocol: HTTPS
port: 443
hostname: app.example.org
tls:
mode: Terminate
certificateRefs:
- name: app-example-org-tls # Secret mit dem Zertifikat
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: web
spec:
parentRefs:
- name: eingang
hostnames: [app.example.org]
rules:
- backendRefs:
- name: web # der Service oben
port: 80
cilium. Das Gateway ist der Eingang für HTTP: Cilium setzt es um, der Listener terminiert TLS, und die HTTPRoute leitet die Anfragen an den Service web weiter. Je Dienst genügt einer der beiden Wege — jeder legt einen eigenen Load Balancer an.
Die Private Registry hat keine Grundgebühr: Berechnet wird der belegte Speicher nach Abzug doppelter Ebenen, und ein Abruf aus dem eigenen Cluster verlässt das Netz nicht.
Die Private Registry ist eine verwaltete Container-Registry je Projekt: OCI-konform (der offene Standard für Container-Abbilder), am selben Standort wie der Cluster, mit Schwachstellenprüfung beim Hochladen und Aufbewahrungsregeln, die den Speicher nicht unbemerkt volllaufen lassen.
Jede neue Ebene wird nach dem Push gegen die Schwachstellendatenbank gehalten, bevor das Abbild ausgeliefert werden kann. Der Befund hängt am Digest — der Prüfsumme des Abbilds — und nicht am Tag, dem frei vergebenen Namen einer Version: Ein neu gesetzter Tag erbt ihn, ein neuer Build nicht.
Ohne Regel wächst eine Registry monoton: Jeder Build legt eine Version ab, keine verschwindet. Die Regeln arbeiten je Repository und lassen sich vor der Ausführung im Trockenlauf ansehen.
Der Cluster meldet sich mit einem Roboterkonto an, das nur lesen darf. Das Zugangstoken liegt als imagePullSecret — das Zugangsgeheimnis für den Abruf von Abbildern — im Namensraum und wird über das Dienstkonto an alle Pods vererbt, die unter ihm laufen.
Ein Rollout über viele Knoten fragt dasselbe Abbild viele Male gleichzeitig an — genau der Fall, in dem öffentliche Register anonyme Abrufe drosseln. Der Spiegel holt das Abbild einmal und liefert es danach aus unserem Netz.
Die Registry hat keine Grundgebühr. Sie legt Ebenen und Manifeste im Objektspeicher ab und wird zu dessen Sätzen berechnet — 0,0070 €0,0081 $ je GB und Monat in der Voreinstellung. Für 250 GB belegten Speicher sind das 1,75 €2,03 $ netto im Monat. Gezählt wird die tatsächliche Belegung nach Entfernung doppelter Ebenen, nicht die Summe der Abbildgrößen.
| Speicherklasse | je GB / Monat | |
|---|---|---|
| Registry StandardVoreinstellung. Trägt Anwendungsabbilder, Basisabbilder und Helm-Charts.Grundlage: Object Storage Standard Mindestmenge: 1 GB Beispielmenge: 250 GB Beispiel / Monat: 1,75 €2,03 $ | Object Storage Standard | 0,0070 €0,0081 $ |
| Registry PerformanceReines NVMe-Backend für große Abbilder und Rollouts über viele Knoten gleichzeitig.Grundlage: Object Storage Performance Mindestmenge: 1 GB Beispielmenge: 250 GB Beispiel / Monat: 4,50 €5,22 $ | Object Storage Performance | 0,0180 €0,0209 $ |
| Registry ArchivZiel der Aufbewahrungsregeln: abgelaufene Versionen, die aus Nachweisgründen bleiben müssen.Grundlage: Cold Archive Mindestmenge: 1.000 GB Beispielmenge: 1.000 GB Beispiel / Monat: 2,40 €2,78 $ | Cold Archive | 0,0024 €0,0028 $ |
Registry, Roboterkonto, Prüfregel, Aufbewahrung und Spiegel sind fünf Befehle. Im Cluster bleibt es unverändertes Kubernetes: ein Secret vom Typ dockerconfigjson, gebunden an das Dienstkonto des Namensraums.
# Registry anlegen — Speicherklasse und Standort
# wie beim Objektspeicher
entronyx registry create prod \
--region fra1 --class standard --quota 250
# Roboterkonto nur mit Lesezugriff, für die Knoten des Clusters
entronyx registry robot create ci-pull \
--registry prod --scope "repo:*:pull" --ttl 90d
# Prüfregel: Abbilder mit kritischer Schwachstelle werden
# nicht ausgeliefert
entronyx registry policy set prod \
--scan-on-push --block-severity critical --block-unscanned
# Aufbewahrung: Die letzten 10 Versionen je Repository bleiben,
# ungetaggte Manifeste fallen nach 7 Tagen weg
entronyx registry retention set prod \
--keep-latest 10 --keep-tagged "v*,release-*" \
--purge-untagged-after 7d --archive-after 180d
# Spiegel für ein öffentliches Register: Abrufe laufen danach über uns
entronyx registry mirror add prod \
--upstream docker.io --cache-ttl 24h
# Zugangsdaten des Roboterkontos als imagePullSecret
# im Cluster hinterlegen
entronyx registry robot token ci-pull --registry prod \
--format docker \
| kubectl create secret generic entronyx-registry \
--namespace produktion --type kubernetes.io/dockerconfigjson \
--from-file=.dockerconfigjson=/dev/stdin
apiVersion: v1
kind: Secret
metadata:
name: entronyx-registry
namespace: produktion
type: kubernetes.io/dockerconfigjson
stringData:
# Erzeugt mit: entronyx registry robot token ci-pull --format docker
.dockerconfigjson: |
{ "auths": { "prod.registry.entronyx.cloud":
{ "auth": "<base64>" } } }
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: default
namespace: produktion
# Neue Pods unter diesem Dienstkonto bekommen das Secret mit;
# es muss dann nicht in jedem Deployment stehen
imagePullSecrets:
- name: entronyx-registry
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: web
namespace: produktion
spec:
selector:
matchLabels: { app: web }
template:
metadata:
labels: { app: web }
spec:
containers:
- name: web
image: prod.registry.entronyx.cloud/team/web:1.8.2
# Der Spiegel ersetzt das öffentliche Register: dieselbe
# Zeile, anderer Ursprung, keine Ratenbegrenzung im Rollout
- name: cache
image: prod.registry.entronyx.cloud/mirror/valkey/valkey:8
Managed Rancher ist Rancher als verwalteter Dienst: Sie melden sich an, binden Cluster an und vergeben Rechte. Updates, Sicherung und Verfügbarkeit der Rancher-Instanz liegen bei uns.
Rancher zeigt Zustand, Auslastung und Ereignisse aller angebundenen Cluster nebeneinander. Die Cluster-Ansicht ist eine Sicht auf denselben API-Server, den auch kubectl anspricht — kein zweiter Zustand, der auseinanderlaufen könnte.
Ein fremder Cluster wird importiert: Rancher gibt ein Manifest aus, das im Zielcluster einen Agenten startet und die Verbindung von innen nach außen aufbaut. Der fremde API-Server muss dafür nicht öffentlich erreichbar sein. Rancher 2.15 importiert konforme Cluster der Versionen 1.34 bis 1.36; die Spanne verschiebt sich mit jeder Rancher-Version. Cluster auf 1.37 — auch Ihre eigenen bei uns — lassen sich anbinden, sobald Rancher die Version führt.
Rancher führt keine eigene Benutzerverwaltung. Wer sich anmeldet, kommt aus demselben Verzeichnisdienst wie in der Konsole. Die Rollen stammen aus dem Rechteverbund: eine Gruppe, eine Zuweisung, wirksam in allen zugeordneten Clustern.
Helm-Charts, die Pakete für Kubernetes-Anwendungen, lassen sich aus einem gemeinsamen Katalog auf eine Auswahl von Clustern gleichzeitig ausrollen — gefiltert nach Bezeichnung, etwa auf alle Cluster mit der Bezeichnung stage=produktion.
Standort wählen, Verzeichnisdienst verbinden. Die Instanz bekommt einen eigenen Namen unter unserer Domain und ein Zertifikat, das automatisch erneuert wird.
Cluster aus Ihren ENTRONYX-Projekten binden wir über die API an. Ein Manifest spielen Sie dafür nicht ein.
Für Cluster bei anderen Anbietern oder im eigenen Rechenzentrum erzeugt Rancher ein Manifest. Angewendet startet es den Agenten, der die Verbindung von innen aufbaut.
Gruppen bekommen Rollen — auf die Instanz, auf einzelne Cluster oder auf Projekte innerhalb eines Clusters. Es entsteht keine zweite Nutzerliste, die gepflegt werden müsste.
Kataloganwendungen ausrollen, Zustände vergleichen, Ereignisse verfolgen. Für die tägliche Arbeit bleibt kubectl unverändert nutzbar: Rancher ergänzt das Werkzeug und ersetzt es nicht.
# Rancher-Instanz anlegen; die Anmeldung läuft über denselben
# Verzeichnisdienst wie die Konsole
entronyx rancher create zentral --region fra1 --sso oidc
# Einen ENTRONYX-Cluster übernehmen — ohne Manifest, die Verbindung
# entsteht über die API
entronyx rancher attach zentral --cluster prod-fra
# Einen fremden Cluster importieren: Rancher gibt ein Manifest aus,
# das im Zielcluster einen Agenten startet
entronyx rancher import zentral --name kunde-onprem > agent.yaml
kubectl --kubeconfig ~/.kube/onprem apply -f agent.yaml
# Rechte kommen aus dem Rechteverbund,
# nicht aus einer zweiten Nutzerliste
entronyx iam binding create \
--group "team-plattform" --role rancher.clusterOwner \
--scope zentral
entronyx iam binding create \
--group "team-anwendung" --role rancher.projectMember \
--scope zentral/produktion
Rancher ist eine zusätzliche Komponente in Ihrer Kette. Bei einem einzelnen Cluster und einem Team, das ohnehin mit kubectl arbeitet, bringt sie mehr Oberfläche als Nutzen. Ab dem dritten Cluster, spätestens bei getrennten Teams oder Standorten, kippt die Rechnung. Für eine Flotte über mehrere Standorte ist die Stufe Enterprise gedacht.
| Merkmal | Ein Cluster, ein Team | Mehrere Cluster, Teams oder Standorte |
|---|---|---|
| Zugang | eine kubeconfig, lokal gepflegt | ein Anmeldevorgang für alle Cluster |
| Rechtevergabe | RoleBindings direkt im Cluster | Rollen einmal im Rechteverbund, wirksam überall |
| Übersicht | kubectl und eigene Dashboards genügen | Zustand aller Cluster nebeneinander |
| Fremde Cluster | getrennte Werkzeugkette je Anbieter | importiert, in derselben Oberfläche |
| Ausrollen | Helm gegen einen Cluster | Auswahl über Bezeichnungen, stufenweise |
| Aufwand | keiner — es gibt nichts zusätzlich zu lernen | eine Oberfläche mehr, die Ihr Team kennen muss |
| Unsere Empfehlung | auf Rancher verzichten Sie besser | Managed Rancher, ab drei Clustern |
Sechzehn Fragen aus dem ersten Gespräch über einen Cluster: Kosten, Datenort, Bindung, Betrieb und Unterlagen. Maßgeblich sind das SLA und die Unterlagen für den Einkauf.
Ein Cluster aus drei Worker-Knoten ND3 (je 4 vCPU dediziert, 16 GB RAM), 300 GB Block Storage NVMe und etcd-Sicherung kostet in der Stufe Standard 267,60 € netto im Monat, in der Stufe Hochverfügbar 324,30 €.
Die Rechnung in der Stufe Standard: Drei Knoten ND3 zu je 77,60 € sind 232,80 €, drei Volumes zu je 100 GB sind 25,80 €, die etcd-Sicherung für den Zustandsspeicher des Clusters kostet 9,00 €; die Steuerungsebene steht mit 0,00 € auf der Rechnung. In der Stufe Hochverfügbar kostet die Steuerungsebene 65,70 €; die etcd-Sicherung ist dort im Preis der Stufe enthalten und entfällt als eigener Posten.
Bei stündlicher Abrechnung zahlen Sie sekundengenau, höchstens aber den Monatsbetrag. Andere Zuschnitte und Mengen rechnen Sie im Rechner dieser Seite Position für Position durch; alle Beträge sind Nettobeträge.
Hinzu kommt je Monat, was Sie buchen: in der Stufe Standard die etcd-Sicherung (9,00 €), jeder weitere Load Balancer Layer 4 (11,98 €), ein ausgehendes Gateway für Knoten ohne öffentliche Adresse (39,98 €) und die Stufe Hochverfügbar (65,70 €) oder Enterprise (177,84 €); nach Menge berechnen wir Volumes, Registry-Speicher und Datenverkehr über dem Inklusivvolumen. Je GB und Monat kosten Volumes auf Block Storage NVMe 0,0860 € und die Private Registry 0,0070 €; jedes TB über dem Inklusivvolumen kostet 1,09 €.
Ohne Aufpreis enthalten sind die Steuerungsebene der Stufe Standard, ein Load Balancer Layer 4 und je Knoten eine öffentliche IPv4-Adresse mit einem /64-IPv6-Netz; die Private Registry hat keine Grundgebühr. Datenverkehr ist bis zum Inklusivvolumen der Knoten enthalten; bei ND3 sind das 30 TB im Monat je Knoten.
Das ausgehende Gateway brauchen nur Knoten ohne öffentliche Adresse, für ihren Verkehr nach außen — nicht zu verwechseln mit dem Gateway am Eingang des Clusters. Weitere Optionen wie größere Load Balancer oder eine andere Speicherklasse zeigt der Konfigurator mit Betrag, bevor Sie bestellen. Alle Beträge sind Nettobeträge.
Die Steuerungsebene kostet in der Stufe Standard 0,00 € und in der Stufe Hochverfügbar 65,70 € netto im Monat je Cluster (0,0900 € je Stunde); dafür läuft sie dort über drei Brandabschnitte statt in einem, zugesagt mit 99,99 % statt 99,9 % Erreichbarkeit des API-Servers. Die Worker-Knoten kosten in jeder Stufe dasselbe.
Ein Brandabschnitt ist ein baulich getrennter Bereich des Standorts. Die etcd-Sicherung ist in der Stufe Standard eine Option gegen Aufpreis, ab der Stufe Hochverfügbar ist sie im Preis der Stufe enthalten. Hochverfügbar trägt außerdem bis zu 500 statt 100 Worker-Knoten.
Die Stufe Enterprise kostet 177,84 € netto im Monat je Cluster. Sie bringt eine dedizierte Steuerungsebene ohne fremde Mandanten, die dokumentierte Härtung nach CIS-Benchmark und den Nachweis nach BSI C5; je Cluster sind dort bis zu 2.000 Worker-Knoten möglich.
Ihr Cluster läuft in einem Rechenzentrum in Deutschland, wahlweise in Frankfurt am Main, Berlin oder München; Betreiber der Plattform ist ein Unternehmen mit Sitz in Köln, das deutschem und europäischem Recht unterliegt, und eine Muttergesellschaft oder Holding in einem Drittstaat gibt es ebenso wenig wie einen Verwaltungszugriff von dort.
Anfragen von Behörden prüfen wir einzeln auf Rechtsgrundlage, Zuständigkeit und Verhältnismäßigkeit; soweit rechtlich zulässig, informieren wir Sie vor einer Herausgabe.
Die Auftragsverarbeitung nach Art. 28 DSGVO ist Bestandteil des Hauptvertrags. Die Liste der Unterauftragsverarbeiter nennt zu jedem Eintrag Sitzland und Verarbeitungszweck.
Ja, bei stündlicher Abrechnung: Ein Testcluster aus drei Knoten ND3 in der Stufe Standard kostet für 24 Stunden 7,65 € netto, mit einem einzelnen Knoten 2,55 €, und mit dem Löschen des Clusters endet die Abrechnung. Abgerechnet wird sekundengenau; Volumes und etcd-Sicherung sind in den Beträgen nicht gerechnet.
Der Testcluster ist ein gewöhnlicher Cluster der Stufe Standard und kein verkleinertes Angebot: Er hat dieselbe Kubernetes-Version, dieselben Treiber und dieselben Worker-Knoten wie ein Cluster im Betrieb.
Nein, bei stündlicher Abrechnung nicht: Den Cluster löschen Sie jederzeit ohne Frist, und die Abrechnung endet mit der Löschung (§ 11 AGB); eine Bindung über 12 oder 24 Monate ist freiwillig und bringt 5 % oder 8 % Rabatt. Die stündliche Abrechnung rechnet sekundengenau und ist auf den Monatsbetrag gedeckelt; schaltet die automatische Skalierung Knoten ab, kosten sie von da an nichts mehr.
Ohne Bindung läuft der Cluster monatlich weiter. Wer sich für 12 oder 24 Monate bindet, zahlt die Laufzeit im Voraus, mit der ersten Rechnung, und erhält 5 % oder 8 % Rabatt auf den gesamten monatlichen Nettobetrag — Steuerungsebene, Knoten, Speicher und Netz. Während der Bindung lässt sich der Cluster jederzeit vergrößern, nicht verkleinern. Kündbar ist die Bindung zum Laufzeitende; bei 12 Monaten verlängert sie sich sonst um 12 Monate.
Bei monatlicher Abrechnung gilt ein fester Monatsbetrag: Die Kapazität aller Knotengruppen bleibt bis zur Obergrenze reserviert und wird auch dann berechnet, wenn Knoten abgeschaltet sind.
In vier Schritten, die Sie selbst ausführen: erstens einen neuen Cluster anlegen, zweitens die Abbilder in die Private Registry übertragen, drittens Manifeste oder die GitOps-Quelle auf den neuen Cluster richten, viertens die Volume-Daten übertragen und den DNS-Eintrag umstellen. Beide Cluster laufen nebeneinander, bis der neue den Verkehr trägt. Wählbar sind für den neuen Cluster die Versionen 1.37, 1.36 und 1.35; die GitOps-Quelle ist das Git-Repository, aus dem Argo CD oder Flux abgleichen.
Anzupassen sind die Namen der StorageClasses (der Speicherprofile für Volumes), die Annotationen des bisherigen Load Balancers und Ihre Ingress-Objekte: Diese laufen weiter, sobald sie die Ingress-Klasse cilium tragen; Annotationen von ingress-nginx wertet Cilium, das Netzwerk-Plugin des Clusters, nicht aus.
In der Übergangszeit kann Managed Rancher den alten Cluster neben dem neuen führen. Für beide gilt die Spanne, die Rancher 2.15 verwaltet: Kubernetes 1.34 bis 1.36.
Ihre Manifeste und Helm-Charts laufen auf jedem anderen konformen Kubernetes-Cluster weiter, sobald die plattformeigenen Namen und Annotationen angepasst sind; ein vollständiger Export Ihrer Daten beim Anbieterwechsel wird nicht gesondert berechnet und nicht auf das Inklusivvolumen angerechnet. Die Kubernetes-API bleibt unverändert, eine eigene Schnittstelle steht nicht dazwischen; StorageClasses, Service-Typen und Annotationen sind gewöhnliche Kubernetes-Objekte.
An der Plattform hängen die Annotationen für den Load Balancer, die Namen der StorageClasses (der Speicherprofile für Volumes), der Klassenname cilium an Gateway- und Ingress-Objekten und der Registry-Name in Ihren Abbildpfaden; Richtlinien vom Typ CiliumNetworkPolicy setzen Cilium als Netzwerk-Plugin voraus. Ein Manifest ohne unsere Annotationen läuft unverändert; es bekommt dann die Voreinstellungen des Load Balancers.
Die Inhalte persistenter Volumes übertragen Sie selbst, denn die etcd-Sicherung enthält Objektdefinitionen und keine Nutzdaten. Planen Sie dafür Volume-Snapshots oder Ihre eigene Sicherung ein.
Die Zusage gilt der Erreichbarkeit des API-Servers Ihres Clusters, nicht Ihrer Anwendung: 99,9 % in der Stufe Standard, 99,99 % ab der Stufe Hochverfügbar. Worker-Knoten, Block Storage und Load Balancer haben eine eigene Zusage von 99,95 %.
Angekündigte Wartung zählt nicht als Ausfall, soweit sie mindestens fünf Kalendertage vorher angekündigt wurde und acht Stunden je Kalendermonat und Ressource nicht überschreitet. Die darüber hinausgehende Zeit zählt vollständig als Ausfallzeit. Ebenfalls ausgenommen sind unter anderem höhere Gewalt und Fehler in Ihrer eigenen Konfiguration.
Liegt ein Monat unter der Zusage, sieht das SLA eine Gutschrift auf die monatliche Grundgebühr der betroffenen Ressource vor: je nach erreichter Verfügbarkeit zwischen 10 % und 100 %. Bei der Steuerungsebene der Stufe Standard beträgt diese Grundgebühr 0,00 €. Zeigt unsere Messung die Unterschreitung, erteilen wir die Gutschrift ohne Antrag; andernfalls beantragen Sie sie mit Kennung der Ressource und Zeitraum der Störung — eigene Messdaten sind keine Voraussetzung. Maßgeblich ist das SLA in der Fassung 4.2.
Gesichert wird etcd, der Zustandsspeicher des Clusters mit allen Objektdefinitionen — in der Stufe Standard nur mit der gebuchten Option, ab der Stufe Hochverfügbar immer; der Inhalt Ihrer Volumes gehört nicht dazu. Daten in persistenten Volumes sichern Sie selbst über Volume-Snapshots.
In der Stufe Standard ist die etcd-Sicherung eine buchbare Option: „Snapshots (7 Tage)“ für 9,00 € netto im Monat. Ohne sie verantworten Sie die Sicherung selbst. Ab der Stufe Hochverfügbar ist die etcd-Sicherung im Preis der Stufe enthalten.
Jede Sicherung ist ein konsistenter Snapshot und verschlüsselt. Eine Wiederherstellung ersetzt den Zustand des gesamten Clusters und läuft deshalb über den Support, nicht in Selbstbedienung.
Den Sprung auf die nächste Minor-Version lösen Sie aus, solange Ihre Version gepflegt wird; findet die Vorprüfung dabei ein Objekt mit einer entfernten API-Version, bricht das Upgrade ab und nennt die betroffenen Objekte. Läuft Ihre Version aus, ohne dass Sie gesprungen sind, heben wir die Steuerungsebene in einem angekündigten Wartungsfenster an.
Die Vorprüfung durchsucht vor jedem Sprung den gesamten Objektbestand des Clusters, nicht nur Ihre Manifeste im Repository. Die Umstellung im Manifest bleibt Ihre Arbeit.
Angehoben wird zuerst die Steuerungsebene, danach rollierend jede Knotengruppe: Ein neuer Knoten kommt hinzu, ein alter wird geleert und entfernt. PodDisruptionBudgets — die Mindestzahl laufender Pods je Anwendung — werden eingehalten. Minor-Versionen lassen sich nicht überspringen, und ein Downgrade der Steuerungsebene ist nicht möglich.
Nein, jede Version der Versionstabelle kostet dasselbe. Neue Cluster legen Sie in den Versionen 1.37, 1.36 oder 1.35 an.
Das Kubernetes-Projekt pflegt eine Minor-Version wie 1.36 rund vierzehn Monate. Danach folgen zwei Monate Übergang, in denen von dort keine neuen Korrekturen kommen; anschließend heben wir die Steuerungsebene in einem angekündigten Wartungsfenster auf die nächste Minor-Version an. Für 1.34 heißt das: Korrekturen bis Oktober 2026, Anhebung ab Dezember 2026.
Nein: Das Kubernetes-Projekt hat den Ingress-Controller ingress-nginx am 24.03.2026 eingestellt, und in neuen Clustern rollen wir ihn nicht aus; den Verkehr von außen steuern Sie stattdessen über die Gateway API, die das Netzwerk-Plugin Cilium umsetzt. Seit der Einstellung erhält ingress-nginx keine Sicherheitskorrekturen mehr.
Bestehende Ingress-Objekte laufen weiter, sobald sie die Ingress-Klasse cilium tragen; Annotationen von ingress-nginx (nginx.ingress.kubernetes.io/…) wertet Cilium nicht aus. Die Ingress-API selbst bleibt bestehen.
Für den Umzug Ihrer Ingress-Regeln auf die Gateway API gibt es das Werkzeug ingress2gateway: Es übersetzt die gängigen Annotationen und meldet, was von Hand anzupassen ist.
Per Ticket: Im Preis enthalten ist der Basis-Support des SLA mit einer Erstreaktion in 8 Stunden bei kritischen Störungen (P1), erreichbar Montag bis Freitag von 08:00 bis 18:00 Uhr. Cluster der Stufe Enterprise haben zusätzlich einen Eskalationspfad rund um die Uhr. Auch eine Wiederherstellung aus der etcd-Sicherung beauftragen Sie per Ticket.
Wie dringend ein Fall ist, ordnet das SLA in vier Prioritäten ein, von P1 (der Produktivbetrieb steht vollständig) bis P4 (Fragen zur Nutzung). Neben dem Basis-Support führt das SLA drei weitere Supportstufen; die höchste reagiert bei P1 in 15 Minuten.
Der Auftragsverarbeitungsvertrag nach Art. 28 DSGVO ist Bestandteil jedes Vertrags; dokumentiert sind außerdem die technischen und organisatorischen Maßnahmen nach Art. 32 und die vollständige Liste der Unterauftragsverarbeiter, und als Nachweise liegen das Zertifikat nach ISO/IEC 27001:2022 und das Testat nach BSI C5:2020, Typ 2, vor.
Das Zertifikat ist gültig bis 30.11.2027 (Rezertifizierung alle drei Jahre); das Testat deckt den Prüfzeitraum 01.07.2025 bis 30.06.2026 (Folgeprüfung läuft). Der Geltungsbereich des Testats nennt Kubernetes als Dienst; in der Stufentabelle steht der C5-Nachweis bei der Stufe Enterprise. Den vollständigen C5-Bericht gibt es nur unter Vertraulichkeitsvereinbarung.
Eine anerkannte Zertifizierung nach Art. 42 DSGVO gibt es für den Dienst nicht. Die Verantwortung nach Art. 24 DSGVO bleibt bei Ihnen als verantwortlicher Stelle; wir stellen die Infrastruktur und die genannten Unterlagen bereit.
Ja: Zur Wahl stehen sechs Kartenmodelle bis zur NVIDIA H200 SXM, jeweils als eigene Knotengruppe neben Ihren übrigen Knoten; der günstigste GPU-Zuschnitt NG-RTX4000 (1 × NVIDIA RTX PRO 4000 Blackwell SFF, 24 GB Grafikspeicher) kostet 0,2932 € je Stunde, gedeckelt auf 214,00 € netto im Monat.
Das Geräte-Plugin wird auf diesen Knoten ausgerollt und meldet die Karten dem Cluster. Dynamic Resource Allocation, die Gerätezuteilung über eigene API-Objekte, ist seit Kubernetes 1.34 stabil; die Zuteilung der Karten läuft hier über das Geräte-Plugin.
Im Betrieb darf der Autoscaler eine solche Gruppe bis auf null Knoten abbauen; der Konfigurator legt jede Gruppe mit mindestens einem Knoten an. NG-RTX4000 gibt es für Cluster in Frankfurt am Main und München.
Der Konfigurator führt in fünf Schritten von der Steuerungsebene bis zur Abrechnung und zeigt jede Position mit Betrag, bevor Sie bestellen. Bei stündlicher Abrechnung zahlen Sie sekundengenau, höchstens den Monatspreis.