Zum Inhalt springenZum Inhalt springen
Mein Konto
Sprache Deutsch, Preise in Euro — Angaben einblenden
Sprache
Deutsch
Währung
Euro (EUR)
Preise
netto, zzgl. 19 % MwSt.

Abrechnung in Euro aus Deutschland. Weitere Sprachen und Währungen sind derzeit nicht verfügbar.

Container und Orchestrierung · CNCF-konform

Kubernetes

Wir betreiben die Steuerungsebene — den Teil des Clusters, der entscheidet, was wo läuft. Berechnet werden ausschließlich die Worker-Knoten, also die Maschinen, auf denen Ihre Container tatsächlich laufen.Die Steuerungsebene kostet nichts, und mit ihr der Ingress-Load-Balancer am Eingang des Clusters, die Treiber und der Autoscaler, der bei Platzmangel einen Knoten nachlegt. Die Kubernetes-API bleibt unverändert: Was hier läuft, läuft auch auf jedem anderen konformen Cluster.

Gepflegt werden 3 Minor-Fassungen gleichzeitig. Die aktuelle ist 1.36, verfügbar seit 04/2026 und gepflegt bis 08/2027.

Steuerungsebene
0,00 €
in der Stufe Standard
SLA
99,99 %
ab der Stufe Hochverfügbar
Worker-Knoten je Cluster
2.000
in der Stufe Enterprise
Registry-Speicher
0,0070 € / GB
je Monat, ohne Grundgebühr

Die Grenze

Was wir übernehmen, was bei Ihnen bleibt

Verwaltetes Kubernetes verschiebt Arbeit, es lässt sie nicht verschwinden. Diese beiden Spalten sagen vor allen Preisen, welcher Teil des Betriebs auf welcher Seite liegt.

ENTRONYX CLOUD übernimmt

Ohne Aufpreis in jeder Stufe, ohne Ticket, ohne Wartungsvertrag.

Steuerungsebene
API-Server, Scheduler, Controller-Manager und etcd — der Datenspeicher des Clusters — laufen auf unserer Hardware. Betrieb, Überwachung und Sicherung liegen bei uns.
etcd-Sicherung
Täglich in der Stufe Standard, alle 15 Minuten ab Hochverfügbar — verschlüsselt und in einer anderen Region als der Cluster.
Versionswechsel
Vorprüfung, Anheben der Steuerungsebene, danach rollierend die Knotengruppen. Läuft eine Fassung aus, heben wir sie im angekündigten Wartungsfenster an.
Mitgelieferte Bausteine
CSI-Treiber (Speicheranbindung), Cloud Controller Manager (Anbindung an unsere API), Autoscaler und der Ingress-Load-Balancer sind installiert, versioniert und werden mit dem Cluster aktualisiert.
Registry
Betrieb der privaten Registry, Prüfung jeder hochgeladenen Ebene gegen die Schwachstellendatenbank und der Spiegel öffentlicher Register.
Unterbau
Maschinen, Netz, Standort und Brandabschnitte der Worker (baulich getrennte Bereiche eines Standorts) — einschließlich Austausch defekter Hardware.

Sie behalten

Alles, was von Ihrer Anwendung abhängt — und deshalb niemand für Sie entscheiden kann.

Ihre Manifeste
Deployments, Services, Helm-Charts und die Auslieferungskette. Argo CD oder Flux — Werkzeuge, die den Cluster aus einem Git-Repository abgleichen — legen wir an, betreiben sie aber nicht mit.
Zuschnitt der Knotengruppen
Welcher Instanztyp, wie viele Knoten, welche Unter- und Obergrenze der Autoscaler bekommt. Wir legen nichts von allein nach.
Daten in den Volumes
Die etcd-Sicherung enthält Objektdefinitionen, keine Nutzdaten. Inhalte persistenter Volumes sichern Sie über Volume-Snapshots.
Rechte und Netzrichtlinien
RBAC-Rollen (die Zugriffsrechte im Cluster), Dienstkonten und NetworkPolicy. Wir setzen keine Regel in Ihrem Cluster, die Sie nicht angelegt haben.
Zeitpunkt des Sprungs
Innerhalb des Pflegefensters entscheiden Sie, wann der Cluster auf die nächste Minor-Fassung geht.
Anpassung an entfernte APIs
Der Preflight-Lauf — die Vorprüfung vor jedem Versionswechsel — meldet Objekte mit abgekündigter API-Gruppe. Die Umstellung im Manifest bleibt Ihre Arbeit.
Mehrere gleichartige Servereinschübe übereinander in einer Reihe, Statusleuchten in einer Flucht.

6 Wörter, die weiter unten vorausgesetzt werden

Knoten
eine einzelne Maschine im Cluster, auf der Ihre Container laufen
Knotengruppe
mehrere Knoten desselben Typs, die gemeinsam wachsen und schrumpfen — im Werkzeug „Node-Pool“
Steuerungsebene
der Teil des Clusters, der entscheidet, was wo läuft; englisch Control Plane
Registry
der Ablageort Ihrer Container-Abbilder, aus dem die Knoten sie ziehen
Ingress
der Eingang von außen in den Cluster — eine öffentliche Adresse vor Ihren Diensten
Autoscaler
der Dienst, der bei Platzmangel einen Knoten nachlegt und ihn später wieder abräumt

Gepflegt werden 3 Minor-Fassungen gleichzeitig. Die aktuelle 1.36 bekommt bis 08/2027 Sicherheitskorrekturen, die älteste noch geführte 1.34 bis 12/2026. Danach heben wir die Steuerungsebene in einem angekündigten Fenster an — die Einzelheiten stehen unter Versionen.

Preismodell

Sie zahlen Rechenknoten, nicht Verwaltung

Die Control Plane läuft auf unserer Hardware, wird von uns aktualisiert, gesichert und überwacht — und erscheint in der Stufe Standard mit 0,00 € auf der Rechnung. Das ist kein Einführungsangebot, sondern das Modell.

Ein Kubernetes-Cluster besteht aus zwei Teilen. Die Steuerungsebene — API-Server, Scheduler, Controller-Manager und etcd — entscheidet, was wo läuft. Die Worker führen aus. Nur der zweite Teil verbraucht Ihre Ressourcen, und nur er wird berechnet.

Worker-Nodes sind normale Cloud-Instanzen aus demselben Katalog wie alles andere. Derselbe Stundensatz, dieselbe Deckelung auf den Monatspreis, dieselben Standorte. Ein Knoten, den der Autoscaler nach zwei Stunden wieder entfernt, kostet zwei Stunden.

Der Inklusiv-Traffic hängt am Node, nicht am Cluster: Jeder Worker bringt sein eigenes Volumen mit, und die Summe steht dem gesamten Cluster zur Verfügung. Ein Pool aus drei ND3-Knoten trägt damit 90 TB ausgehenden Verkehr im Monat, unabhängig davon, über welchen Node er abfließt.

Was zusätzlich anfällt: persistente Volumes über Block Storage, der Speicher der privaten Registry, ausgehender Verkehr oberhalb des Inklusivvolumens der Nodes und — falls gebucht — der Aufpreis für die Stufen Hochverfügbar oder Enterprise.

Control Plane
0,00 €
API-Server, Scheduler, etcd, Upgrades
Ingress-Load-Balancer
0,00 €
in jeder Stufe enthalten
CSI, CCM, Autoscaler
0,00 €
gepflegt und überwacht
Worker-Node ND3
77,60 €
4 vCPU dediziert, 16 GB
Persistentes Volume
0,0860 € / GB
Block Storage NVMe, RWO (ein Knoten schreibt)
Gemeinsames Dateisystem
0,0518 € / GB
RWX (mehrere Knoten) über NFS 4.1
Geöffnetes 2-HE-Servergehäuse von schräg oben auf der Werkbank: Kühlkörper mit Kupferboden über dem Sockel, bestückte und verriegelte Speicherbänke, Lüfterwand, hinten die Netzteile mit Kaltgerätebuchse, an der Front die Laufwerkseinschübe.

Rechenbeispiel

Ein produktionsfähiger Cluster, Position für Position

Drei dedizierte Worker, je ein persistentes Volume von 100 GB, ein öffentlicher Ingress. Genug für eine Anwendung mit Datenbank, Cache und Hintergrundverarbeitung — mit Kapazität für den Ausfall eines Knotens.

Monatliche Kosten eines Clusters mit 3 × ND3 und 300 GB persistentem Speicher, netto
PositionMengeEinzelpreisSumme
Control Plane, Stufe StandardSLA 99,9 %, automatische Upgrades10,00 €0,00 €
Ingress mit Load Balanceröffentliche IPv4 und IPv6, Proxy Protocol v210,00 €0,00 €
Worker-Node ND34 vCPU dediziert, 16 GB RAM, 160 GB NVMe377,60 €232,80 €
Block Storage NVMepersistente Volumes, 100 GB je Worker300 GB0,0860 € / GB25,80 €
Ausgehender Verkehr30 TB je Worker inklusive90 TB0,00 €0,00 €
Summe netto je Monat258,60 €

Was dabei herauskommt

Rechenkapazität
12 dedizierte vCPU
Arbeitsspeicher
48 GB
Lokale NVMe
480 GB
Persistenter Speicher
300 GB
Kosten je vCPU
21,55 €
Summe netto
258,60 €
Brutto je Monatinkl. 19 % USt.
307,73 €

Zuschnitte, die sich als Worker eignen

Ein Flavor ist der Zuschnitt eines Knotens: vCPU, Arbeitsspeicher und lokale NVMe in einer festen Kombination. Zuschnitte mit geteilten Kernen empfehlen wir für Produktionscluster nicht. Auf jedem Knoten laufen dauerhaft Kubernetes-eigene Prozesse mit — sie verbrauchen ihren Anteil der Quote schneller, als es die Anwendung tut.

Preiseinheit wählen

Monatspreis ist zugleich die Obergrenze der stundenweisen Abrechnung

Für Node-Pools geeignete Instanztypen mit vCPU, Arbeitsspeicher, lokaler NVMe und Preis je Stunde oder Monat
KonfigurationvCPURAMNVMe lokalPreis / Monat
ND2AMD EPYC (dediziert)28 GB80 GB38,80 €
ND3AMD EPYC (dediziert)416 GB160 GB77,60 €
ND4AMD EPYC (dediziert)832 GB240 GB138,99 €
ND5AMD EPYC (dediziert)1664 GB360 GB276,49 €
NM4AMD EPYC (dediziert)864 GB320 GB193,30 €
NA4Ampere Altra (shared)816 GB160 GB21,49 €
NA5Ampere Altra (shared)1632 GB320 GB41,49 €
NG-L4AMD EPYC (dediziert)848 GB400 GB540,00 €

NG-L4 gehört in einen eigenen Pool 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.

Drei Stufen

Der Unterschied liegt in der Steuerungsebene

Alle drei Stufen liefern dieselbe Kubernetes-Version, dieselben Treiber und dieselben Worker. Was sich unterscheidet, ist die Ausfallsicherheit der Control Plane, die Obergrenze für Knoten und der Nachweisumfang.

Standard

Control Plane kostenlos — Sie zahlen nur die Worker-Nodes.

0,00 €/ Monat je Cluster

SLA
99,9 %
Worker max.
100
  • Verwaltete Control Plane
  • Automatische Upgrades
  • CSI- und CCM-Treiber
  • Cluster Autoscaler
  • Ingress mit Load Balancer

Hochverfügbar

empfohlen

Control Plane über drei Brandabschnitte verteilt.

65,70 €/ Monat je Cluster

SLA
99,99 %
Worker max.
500
  • Alles aus Standard
  • 3-Zonen Control Plane
  • etcd-Backup alle 15 Minuten
  • Private API-Endpunkt
  • Audit-Log-Export

Enterprise

Für regulierte Umgebungen mit Nachweispflicht.

177,84 €/ Monat je Cluster

SLA
99,99 % mit Gutschrift
Worker max.
2.000
  • Alles aus Hochverfügbar
  • Dedizierte Control Plane
  • Multi-Region-Föderation
  • CIS-Benchmark-Härtung
  • BSI-C5-Nachweis
  • 24/7 Eskalationspfad
Die drei Kubernetes-Stufen im Merkmalsvergleich
MerkmalStandard0,00 € / MonatHochverfügbar65,70 € / MonatEnterprise177,84 € / Monat
Verfügbarkeitszusagegemessen an der Erreichbarkeit des API-Servers99,9 %99,99 %99,99 % mit Gutschrift
Worker-Nodes je Cluster1005002.000
Control Planeein Brandabschnitt, verwaltetdrei Brandabschnitte, aktiv/aktivdediziert, ohne fremde Mandanten
etcd-Sicherungtäglich, in zweiter Regionalle 15 Minutenalle 15 Minuten, mit WORM-Sperre (bis Ablauf unveränderbar)
API-Endpunktöffentlich, mit IP-Freigabelistezusätzlich privat im vRack (Ihr privates Netz)zusätzlich privat im vRack
Private Registrysiehe Abschnitt Private Registryeine Registry je Projektmehrere Registries, Spiegel inklusivemehrere Registries, Signaturpflicht möglich
Audit-Log7 Tage in der KonsoleExport nach Object Storage oder LokiExport, revisionssicher
HärtungVoreinstellungen von UpstreamVoreinstellungen von UpstreamCIS-Benchmark (Härtungskatalog), dokumentiert
NachweiseISO 27001ISO 27001ISO 27001 und BSI C5
EskalationTicket, 4 StundenTicket, 1 Stunde24/7 Rufnummer, benannter Ansprechpartner

Bestandteile

Was im Cluster bereits läuft

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.

CSI-Treiber

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.

Zugriffsmodi
RWO (ein Knoten) auf Block, RWX (mehrere) über NFS
Online-Vergrößerung
ja, ohne Neustart des Pods
Snapshots
VolumeSnapshotClass, inkrementell
Topologie
Volume bleibt an seinen Brandabschnitt gebunden

Cloud Controller Manager

Der CCM verbindet Kubernetes mit unserer API: Er setzt die Provider-ID auf jedem Node, entfernt gelöschte Instanzen aus dem Cluster und legt für jeden Service vom Typ LoadBalancer eine öffentliche Adresse an.

Load Balancer
über service.beta.entronyx.cloud/… annotierbar
Verfahren
round-robin, least-connections, source-hash
Proxy Protocol
v2, für echte Client-IP
Routen
Pod-Netz wird im vRack bekannt gemacht

Cluster Autoscaler

Je Node-Pool setzen Sie eine Unter- und Obergrenze. Kann ein Pod wegen fehlender Kapazität nicht platziert werden, entsteht innerhalb von rund 60 Sekunden ein neuer Node. Pools dürfen auf null herunterskalieren.

Auswahlverfahren
least-waste
Abbau
nach 10 Minuten unter 50 % Auslastung
Schutz
PodDisruptionBudgets werden eingehalten
Skalieren aus null
ja, für GPU- und Batch-Pools

Ingress und Netz

Cilium, das Netzwerk-Plugin des Clusters, läuft im eBPF-Modus und ersetzt kube-proxy. ingress-nginx und Gateway API v1 stehen als Add-on bereit, cert-manager holt Zertifikate über DNS-01 gegen unser Anycast-DNS.

CNI
Cilium, eBPF, ohne kube-proxy
Netzrichtlinien
NetworkPolicy und CiliumNetworkPolicy
Beobachtung
Hubble-Flüsse, 24 Stunden Vorhaltung
Pods je Node
110, Pod-CIDR standardmäßig /16

Managed Private Registry

Ihre Abbilder liegen dort, wo die Knoten stehen

Eine verwaltete, private Container-Registry je Projekt: OCI-konform (der offene Standard für Container-Abbilder), im selben Standort wie der Cluster, mit Schwachstellenprüfung beim Hochladen und Aufbewahrungsregeln, die den Speicher nicht unbemerkt volllaufen lassen.

Prüfung beim Hochladen

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: Ein neu gesetzter Tag erbt ihn, ein neuer Build nicht.

Auslöser
jeder Push, ohne Zutun
Erneute Prüfung
täglich gegen die aktualisierte Datenbank
Sperre
je Schweregrad, standardmäßig ab kritisch
Ausnahmen
je Repository, mit Ablaufdatum und Begründung

Aufbewahrungsregeln

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.

Behalten
die letzten n Versionen je Repository
Schutzmuster
Tags wie v* oder release-* bleiben immer
Ungetaggt
Manifeste ohne Tag fallen nach n Tagen weg
Archiv
ältere Versionen wandern in die Archivklasse

Anbindung an den Cluster

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 auf alle Pods vererbt.

Kontotyp
Roboterkonto, nicht Ihr Benutzerkonto
Rechte
getrennt nach pull, push und delete
Laufzeit
Token mit Ablaufdatum, erneuerbar
Bindung
an das Dienstkonto statt an jedes Deployment

Spiegel öffentlicher Register

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.

Wirkung
keine Drosselung im Rollout
Erste Anfrage
wird durchgereicht und zwischengespeichert
Herkunft
Digest bleibt identisch zum Original
Netz
Abruf aus dem Cluster verlässt unser Netz nicht

Speicherklassen und Preise

Die Registry hat keine Grundgebühr. Sie legt Ebenen und Manifeste im Objektspeicher ab und wird zu dessen Sätzen berechnet — 0,0070 € je GB und Monat in der Voreinstellung. 250 GB belegter Speicher kosten damit 1,75 € netto im Monat. Gezählt wird die tatsächliche Belegung nach Entfernung doppelter Ebenen, nicht die Summe der Abbildgrößen.

Speicherklassen der privaten Registry, netto je Monat — der Betrag in der letzten Spalte ist Preis je GB multipliziert mit der Beispielmenge
SpeicherklasseGrundlageje GB / MonatMindestmengeBeispielmengeBeispiel / Monat
Registry StandardVoreinstellung. Trägt Anwendungsabbilder, Basisimages und Helm-Charts.Object Storage Standard0,0070 €1 GB250 GB1,75 €
Registry PerformanceReines NVMe-Backend für große Abbilder und Rollouts über viele Knoten gleichzeitig.Object Storage Performance0,0180 €1 GB250 GB4,50 €
Registry ArchivZiel der Aufbewahrungsregeln: abgelaufene Versionen, die aus Nachweisgründen bleiben müssen.Cold Archive0,0024 €1000 GB1 TB2,46 €

Einrichten und im Cluster verwenden

Registry, Roboterkonto, Prüfregel, Aufbewahrung und Spiegel sind fünf Befehle. Im Cluster bleibt es Standard-Kubernetes: ein Secret vom Typ dockerconfigjson, gebunden an das Dienstkonto des Namensraums.

registry-einrichten.sh
# Registry anlegen — Speicherklasse und Region 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
Das Roboterkonto bekommt ausschließlich Leserechte. Ein Token mit Schreibrecht gehört in die Build-Kette, nicht in den Cluster.
registry-secret.yaml
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
# Das Dienstkonto zieht das Secret für alle Pods des Namensraums,
# damit es nicht in jedem Deployment wiederholt werden muss
imagePullSecrets:
  - name: entronyx-registry
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  namespace: produktion
spec:
  template:
    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/library/valkey:8
Das Secret am Dienstkonto erspart die Wiederholung in jedem Deployment. Der Spiegelpfad mirror/library/… ersetzt die öffentliche Herkunft, ohne den Digest zu verändern.
Regal mit beschrifteten, gleich großen Behältern, ein Fach ist herausgezogen.

Die Registry von ENTRONYX CLOUD hat keine Grundgebühr: Abgerechnet wird der belegte Speicher nach Abzug doppelter Ebenen. Ein Abruf aus dem eigenen Cluster verlässt unser Netz nicht und kostet deshalb nichts.

Private Registry · Abrechnung nach Belegung

Managed Rancher

Eine Oberfläche für eine Flotte von Clustern

Rancher wird als verwalteter Dienst betrieben: Sie melden sich an, binden Cluster an und vergeben Rechte. Aktualisierung, Sicherung und Verfügbarkeit der Rancher-Instanz liegen bei uns.

Mehrere Cluster, eine Oberfläche

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.

Zugang
ein Anmeldevorgang für alle Cluster
kubectl
eingebaute Konsole, oder weiter lokal
Ereignisse
über alle Cluster zusammengeführt
Betrieb
die Instanz wird von uns aktualisiert

Auch Cluster außerhalb von ENTRONYX

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.

Voraussetzung
konformer Cluster ab Version 1.30
Verbindung
vom Agenten ausgehend, über TLS
Eingriffstiefe
Beobachten und Anwenden, keine Umbauten
Lösen
Agent entfernen, der Cluster läuft weiter

Rechteverbund statt zweiter Nutzerliste

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.

Anmeldung
OIDC (Anmeldestandard) gegen Ihren Verzeichnisdienst
Rollen
aus dem Rechteverbund, nicht doppelt gepflegt
Geltungsbereich
je Instanz, Cluster oder Projekt
Entzug
Austritt aus der Gruppe wirkt sofort

Anwendungskatalog und Flottenrollout

Helm-Charts — das Paketformat für Kubernetes-Anwendungen — aus einem gemeinsamen Katalog lassen sich auf eine Auswahl von Clustern gleichzeitig ausrollen — nach Bezeichnung gefiltert, etwa auf alle Cluster mit der Bezeichnung stage=produktion.

Quelle
eigener Katalog oder Ihre Helm-Repositorien
Auswahl
über Bezeichnungen, nicht über Listen
Reihenfolge
stufenweise, mit Halt bei Fehlern
Abgleich
Abweichungen werden gemeldet

Vom leeren Rancher zur Flotte

  1. 01

    Instanz anlegen

    wenige Minuten

    Region wählen, Verzeichnisdienst verbinden. Die Instanz bekommt einen eigenen Namen unter unserer Domain und ein Zertifikat, das automatisch erneuert wird.

  2. 02

    Eigene Cluster übernehmen

    ohne Agent

    Cluster aus Ihren ENTRONYX-Projekten werden über die API angebunden. Im Cluster ändert sich dabei nichts, was Sie zurückbauen müssten.

  3. 03

    Fremde Cluster importieren

    ein Manifest

    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.

  4. 04

    Rechte zuordnen

    aus dem Rechteverbund

    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.

  5. 05

    Betrieb aufnehmen

    laufend

    Kataloganwendungen ausrollen, Zustände vergleichen, Ereignisse verfolgen. Für die tägliche Arbeit bleibt kubectl unverändert nutzbar — Rancher ergänzt sie, ersetzt sie nicht.

rancher-einrichten.sh
# 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 — kein Agent nötig, 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
Der Import eines fremden Clusters ist der einzige Schritt, der im Zielcluster etwas verändert — er startet dort einen Agenten und sonst nichts.

Wann Sie das brauchen — und wann nicht

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.

Betrieb ohne und mit Managed Rancher im Vergleich
MerkmalEin Cluster, ein TeamMehrere Cluster, Teams oder Standorte
Zugangeine kubeconfig, lokal gepflegtein Anmeldevorgang für alle Cluster
RechtevergabeRoleBindings direkt im ClusterRollen einmal im Rechteverbund, wirksam überall
Übersichtkubectl und eigene Dashboards genügenZustand aller Cluster nebeneinander
Fremde Clustergetrennte Werkzeugkette je Anbieterimportiert, in derselben Oberfläche
AusrollenHelm gegen einen ClusterAuswahl über Bezeichnungen, stufenweise
Aufwandkeiner — es gibt nichts zusätzlich zu lerneneine Oberfläche mehr, die Ihr Team kennen muss
Unsere Empfehlungbei Rancher bleiben Sie besser außen vorManaged Rancher, ab drei Clustern

Lebenszyklus

Versionen und Upgrade-Pfad

Wir führen drei Minor-Versionen parallel. Eine neue Version steht spätestens sechs Wochen nach dem Upstream-Release bereit, die älteste läuft mindestens zwölf Monate weiter.

Das Fenster je Version umfasst rund sechzehn Monate — vom Tag der Verfügbarkeit bis zum Supportende in der Tabelle. Innerhalb dieses Fensters bekommt die Version Sicherheitsaktualisierungen und Fehlerkorrekturen, danach nicht mehr. Läuft eine Version aus, ohne dass Sie gesprungen sind, heben wir die Control Plane in einem angekündigten Wartungsfenster auf die nächste Minor-Version an.

Unterstützte Kubernetes-Versionen mit Verfügbarkeit und Supportende
Versionverfügbar seitSupport bisStatus
1.3604/202608/2027Standard
1.3512/202504/2027gepflegt
1.3408/202512/2026gepflegt

Ablauf eines Upgrades

  1. 01

    Preflight

    vor dem Wartungsfenster

    Prüfung auf abgekündigte API-Gruppen, fehlende PodDisruptionBudgets (die Mindestzahl laufender Pods je Anwendung) und Add-ons, deren Version nicht zur Zielversion passt. Das Ergebnis ist eine Liste, keine Vermutung.

  2. 02

    Control Plane

    5 bis 15 Minuten

    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.

  3. 03

    Node-Pools

    rollierend

    Jeder Pool wird mit Surge 1 erneuert: ein neuer Node kommt hinzu, ein alter wird abgeriegelt, geleert und entfernt. PodDisruptionBudgets werden eingehalten, notfalls wartet der Vorgang.

  4. 04

    Versionsversatz

    Grenze

    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 Node-Pools bewusst zurückbleiben — etwa ein Pool mit besonders sensiblen Arbeitslasten.

  5. 05

    Rücknahme

    nur nach vorn

    Ein Downgrade der Control Plane 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.

Verhalten bei veralteten API-Gruppen

Eine entfernte API-Gruppe 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.

Von Upstream entfernte API-Gruppen, die der Preflight-Lauf meldet
API-GruppeBetroffene Objekteentfernt inErsatz
networking.k8s.io/v1beta1Ingress, IngressClass1.22networking.k8s.io/v1
batch/v1beta1CronJob1.25batch/v1
policy/v1beta1PodDisruptionBudget1.25policy/v1
autoscaling/v2beta2HorizontalPodAutoscaler1.26autoscaling/v2
flowcontrol.apiserver.k8s.io/v1beta3FlowSchema, PriorityLevelConfiguration1.32flowcontrol.apiserver.k8s.io/v1

Die Umstellung ist in der Regel eine Zeile im Manifest: Gruppe und Version tauschen, Feld- und Objektnamen bleiben gleich. Ausnahmen kündigen wir mit der Freigabe der jeweiligen Version in den Versionshinweisen an.

Grenzwerte

Die Werte sind harte Grenzen der Steuerungsebene, keine Empfehlungen. Wer sie ausreizen will, sollte vorher mit uns über die Verteilung der Node-Pools sprechen — 2000 Knoten in einem einzigen Pool verhalten sich anders als 2000 Knoten in vierzig Pools.

Technische Obergrenzen je Kubernetes-Stufe
MerkmalStandardHochverfügbarEnterprise
Worker-Nodes je Cluster1005002.000
Node-Pools je Cluster83264
Cluster je Projekt525unbegrenzt
Pods je Node110110110
Services vom Typ LoadBalancer520100
etcd-Datenbankgröße8 GB8 GB8 GB
Persistente Volumes je NodeGrenze des Block-Storage-Anschlusses161616

Automatisierung

Cluster als Code

Cluster, Node-Pools, Registries und Autoscaling-Grenzen sind Ressourcen im Terraform-Provider. Was Sie in der Konsole klicken können, können Sie auch versionieren.

Kommandozeile
# Cluster anlegen — die Control Plane wird nicht berechnet
entronyx kube cluster create prod-fra \
  --version 1.36 --tier ha --region fra1 --private-endpoint
 
# Node-Pool 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                    DEFAULT
# nvme-delete         csi.block.entronyx.cloud       true
# nvme-retain         csi.block.entronyx.cloud       false
# capacity-delete     csi.block.entronyx.cloud       false
# shared-nfs          csi.file.entronyx.cloud        false
Die kubeconfig — die Zugangsdatei für kubectl — enthält ein kurzlebiges Token, das über den ENTRONYX-Anmeldedienst erneuert wird. Für CI-Systeme erzeugen Sie stattdessen ein Dienstkonto mit begrenzter Rolle.
main.tf
resource "entronyx_kube_cluster" "prod" {
  name             = "prod-fra"
  region           = "fra1"
  version          = "1.36"
  tier             = "ha" # 99,99 %, Control Plane über 3 Brandabschnitte
  private_endpoint = true
  vrack            = entronyx_vrack.prod.id
 
  etcd_backup {
    interval = "15m"
    region   = "hel1" # Sicherung liegt außerhalb des Cluster-Standorts
  }
}
 
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"
  }
}
Ein Wechsel der version-Angabe löst ein Upgrade aus — erst der Control Plane, dann rollierend der Node-Pools.
service-und-pvc.yaml
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:
  type: LoadBalancer   # der Cloud Controller legt die öffentliche IP an
  selector:
    app: web
  ports:
    - port: 443
      targetPort: 8443
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: data
spec:
  storageClassName: nvme-retain   # Volume überlebt das Löschen des Claims
  accessModes: [ReadWriteOnce]
  resources:
    requests:
      storage: 100Gi
Beide Objekte sind Standard-Kubernetes. Ohne die Annotationen bekommt der Load Balancer round-robin ohne Proxy Protocol; ohne storageClassName greift nvme-delete.

Nächster Schritt

Cluster anlegen, Worker konfigurieren

Die Steuerungsebene steht in unter fünf Minuten. Knotengruppen, Registry und Rancher-Anbindung konfigurieren Sie im selben Durchgang — mit denselben Preisen, denselben Standorten und derselben stundenweisen Abrechnung.

Steuerungsebene
0,00 €
Beispielcluster
258,60 €
Worker max.
2.000
Version
1.36