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
Abrechnung in Euro aus Deutschland. Weitere Sprachen und Währungen sind derzeit nicht verfügbar.
Container und Orchestrierung · CNCF-konform
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.
Die Grenze
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.
Ohne Aufpreis in jeder Stufe, ohne Ticket, ohne Wartungsvertrag.
Alles, was von Ihrer Anwendung abhängt — und deshalb niemand für Sie entscheiden kann.

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
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.

Rechenbeispiel
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.
| Position | Menge | Einzelpreis | Summe |
|---|---|---|---|
| Control Plane, Stufe StandardSLA 99,9 %, automatische Upgrades | 1 | 0,00 € | 0,00 € |
| Ingress mit Load Balanceröffentliche IPv4 und IPv6, Proxy Protocol v2 | 1 | 0,00 € | 0,00 € |
| Worker-Node ND34 vCPU dediziert, 16 GB RAM, 160 GB NVMe | 3 | 77,60 € | 232,80 € |
| Block Storage NVMepersistente Volumes, 100 GB je Worker | 300 GB | 0,0860 € / GB | 25,80 € |
| Ausgehender Verkehr30 TB je Worker inklusive | 90 TB | 0,00 € | 0,00 € |
| Summe netto je Monat | 258,60 € |
Was dabei herauskommt
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.
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 € |
| ND3AMD EPYC (dediziert) | 4 | 16 GB | 160 GB | 77,60 € |
| ND4AMD EPYC (dediziert) | 8 | 32 GB | 240 GB | 138,99 € |
| ND5AMD EPYC (dediziert) | 16 | 64 GB | 360 GB | 276,49 € |
| NM4AMD EPYC (dediziert) | 8 | 64 GB | 320 GB | 193,30 € |
| NA4Ampere Altra (shared) | 8 | 16 GB | 160 GB | 21,49 € |
| NA5Ampere Altra (shared) | 16 | 32 GB | 320 GB | 41,49 € |
| NG-L4AMD EPYC (dediziert) | 8 | 48 GB | 400 GB | 540,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
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.
Control Plane kostenlos — Sie zahlen nur die Worker-Nodes.
0,00 €/ Monat je Cluster
Control Plane über drei Brandabschnitte verteilt.
65,70 €/ Monat je Cluster
Für regulierte Umgebungen mit Nachweispflicht.
177,84 €/ Monat je Cluster
| Merkmal | Standard0,00 € / Monat | Hochverfügbar65,70 € / Monat | Enterprise177,84 € / Monat |
|---|---|---|---|
| Verfügbarkeitszusagegemessen an der Erreichbarkeit des API-Servers | 99,9 % | 99,99 % | 99,99 % mit Gutschrift |
| Worker-Nodes je Cluster | 100 | 500 | 2.000 |
| Control Plane | ein Brandabschnitt, verwaltet | drei Brandabschnitte, aktiv/aktiv | dediziert, ohne fremde Mandanten |
| etcd-Sicherung | täglich, in zweiter Region | alle 15 Minuten | alle 15 Minuten, mit WORM-Sperre (bis Ablauf unveränderbar) |
| API-Endpunkt | öffentlich, mit IP-Freigabeliste | zusätzlich privat im vRack (Ihr privates Netz) | zusätzlich privat im vRack |
| Private Registrysiehe Abschnitt Private Registry | eine Registry je Projekt | mehrere Registries, Spiegel inklusive | mehrere Registries, Signaturpflicht möglich |
| Audit-Log | 7 Tage in der Konsole | Export nach Object Storage oder Loki | Export, revisionssicher |
| Härtung | Voreinstellungen von Upstream | Voreinstellungen von Upstream | CIS-Benchmark (Härtungskatalog), dokumentiert |
| Nachweise | ISO 27001 | ISO 27001 | ISO 27001 und BSI C5 |
| Eskalation | Ticket, 4 Stunden | Ticket, 1 Stunde | 24/7 Rufnummer, benannter Ansprechpartner |
Bestandteile
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.
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.
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.
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.
Managed Private Registry
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.
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.
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 auf alle Pods vererbt.
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 € 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.
| Speicherklasse | Grundlage | je GB / Monat | Mindestmenge | Beispielmenge | Beispiel / Monat |
|---|---|---|---|---|---|
| Registry StandardVoreinstellung. Trägt Anwendungsabbilder, Basisimages und Helm-Charts. | Object Storage Standard | 0,0070 € | 1 GB | 250 GB | 1,75 € |
| Registry PerformanceReines NVMe-Backend für große Abbilder und Rollouts über viele Knoten gleichzeitig. | Object Storage Performance | 0,0180 € | 1 GB | 250 GB | 4,50 € |
| Registry ArchivZiel der Aufbewahrungsregeln: abgelaufene Versionen, die aus Nachweisgründen bleiben müssen. | Cold Archive | 0,0024 € | 1000 GB | 1 TB | 2,46 € |
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 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
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

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
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.
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 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 — 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.
Region 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 werden über die API angebunden. Im Cluster ändert sich dabei nichts, was Sie zurückbauen müssten.
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 sie, ersetzt sie 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 — 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
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.
| 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 | bei Rancher bleiben Sie besser außen vor | Managed Rancher, ab drei Clustern |
Lebenszyklus
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.
| Version | verfügbar seit | Support bis | Status |
|---|---|---|---|
| 1.36 | 04/2026 | 08/2027 | Standard |
| 1.35 | 12/2025 | 04/2027 | gepflegt |
| 1.34 | 08/2025 | 12/2026 | gepflegt |
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.
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.
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.
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.
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.
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.
| API-Gruppe | Betroffene Objekte | entfernt in | Ersatz |
|---|---|---|---|
| networking.k8s.io/v1beta1 | Ingress, IngressClass | 1.22 | networking.k8s.io/v1 |
| batch/v1beta1 | CronJob | 1.25 | batch/v1 |
| policy/v1beta1 | PodDisruptionBudget | 1.25 | policy/v1 |
| autoscaling/v2beta2 | HorizontalPodAutoscaler | 1.26 | autoscaling/v2 |
| flowcontrol.apiserver.k8s.io/v1beta3 | FlowSchema, PriorityLevelConfiguration | 1.32 | flowcontrol.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.
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.
| Merkmal | Standard | Hochverfügbar | Enterprise |
|---|---|---|---|
| Worker-Nodes je Cluster | 100 | 500 | 2.000 |
| Node-Pools je Cluster | 8 | 32 | 64 |
| Cluster je Projekt | 5 | 25 | unbegrenzt |
| Pods je Node | 110 | 110 | 110 |
| Services vom Typ LoadBalancer | 5 | 20 | 100 |
| etcd-Datenbankgröße | 8 GB | 8 GB | 8 GB |
| Persistente Volumes je NodeGrenze des Block-Storage-Anschlusses | 16 | 16 | 16 |
Automatisierung
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.
# 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
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"
}
}
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
Nächster Schritt
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.