Skip to content

Kubernetes

We operate the control plane — the part of the cluster that decides what runs where. You are only charged for the worker nodes, i.e. the machines on which your containers actually run.The control plane costs nothing, and with it the ingress load balancer at the entrance of the cluster, the drivers and the autoscaler, which adds a node when space is tight. The Kubernetes API remains unchanged: what runs here also runs on any other compliant cluster.

3 minor versions are maintained simultaneously. The current one is 1.36, available since 04/2026 and maintained until 08/2027.

Control plane
€0.00$0.00
in the Standard tier
SLA
99.99%
from tier Highly available, according to SLA 4.2
Worker nodes per cluster
2,000
in the Enterprise tier
Registry storage
€0.0070$0.0081 / GB
per month, no base fee

What we take over, what stays with you

Managed Kubernetes shifts work, it does not make it disappear. Before any prices, these two columns state which part of operations lies on which side.

ENTRONYX CLOUD takes over

At no extra charge in every tier, without a ticket, without a maintenance contract.

Control plane
API server, scheduler, controller manager and etcd — the cluster's data store — run on our hardware. Operations, monitoring and backup are our responsibility.
etcd backup
Daily in the Standard tier, every 15 minutes from High Availability upwards — encrypted and in a different region to the cluster.
Version upgrades
Pre-check, upgrading the control plane, then rolling upgrades for the node pools. If a version expires, we upgrade it during the announced maintenance window.
Included components
CSI drivers (storage connection), Cloud Controller Manager (connection to our API), autoscaler and the ingress load balancer are installed, versioned and updated with the cluster.
Registry
Operation of the private registry, checking every uploaded layer against the vulnerability database and mirroring public registries.
Infrastructure
Machines, network, location and fire zones of the workers (structurally separated areas of a location) — including the replacement of defective hardware.

You keep

Everything that depends on your application — and therefore nobody can decide for you.

Your manifests
Deployments, services, Helm charts and the delivery chain. We set up Argo CD or Flux — tools that sync the cluster from a Git repository — but do not operate them for you.
Sizing of the node pools
Which instance type, how many nodes, which lower and upper limits the autoscaler gets. We do not add anything on our own.
Data in the volumes
The etcd backup contains object definitions, not user data. You back up the contents of persistent volumes via volume snapshots.
Permissions and network policies
RBAC roles (the access rights in the cluster), service accounts and NetworkPolicy. We do not set any rules in your cluster that you have not created.
Timing of the upgrade
Within the maintenance window, you decide when the cluster moves to the next minor version.
Adaptation to removed APIs
The preflight run — the pre-check before every version change — reports objects with a deprecated API group. Updating the manifest remains your responsibility.
Several identical server chassis stacked in a row, status lights aligned.

6 words that are assumed further down

Nodes
a single machine in the cluster on which your containers run
Node pool
several nodes of the same type that grow and shrink together — in the tool “node pool”
Control plane
the part of the cluster that decides what runs where; English control plane
Registry
the storage location of your container images from which the nodes pull them
Ingress
the external entrance to the cluster — a public address in front of your services
Autoscaler
the service that adds a node when space is tight and removes it later

We maintain 3 minor versions simultaneously. The current 1.36 receives security patches until 08/2027, the oldest still supported 1.34 until 12/2026. After that, we upgrade the control plane in an announced window — details can be found under Versions.

You pay for compute nodes, not management

The control plane runs on our hardware, is updated, backed up and monitored by us — and appears on the invoice in the Standard tier at €0.00$0.00. This is not an introductory offer, but the model.

A Kubernetes cluster consists of two parts. The control plane — API server, scheduler, controller manager and etcd — decides what runs where. The workers execute. Only the second part consumes your resources, and only it is billed.

Worker nodes are normal cloud instances from the same catalogue as everything else. The same hourly rate, the same cap on the monthly price, the same locations. A node that the autoscaler removes again after two hours costs two hours.

The included traffic is attached to the node, not the cluster: each worker brings its own volume, and the sum is available to the entire cluster. A pool of three ND3 nodes thus contributes 90 TB of outbound traffic per month, regardless of which node it flows through.

What incurs additional costs: persistent volumes via Block Storage, the storage of the private registry, outbound traffic above the included volume of the nodes and — if booked — the surcharge for the High Availability or Enterprise tiers.

Included in the price

  • Control plane, tier Standard

    Managed control plane · Automatic upgrades

    €0.00$0.00
  • Load Balancer Layer 4

    TCP and UDP with Proxy Protocol v2. Supports the ingress controller of the cluster. Additional and higher tiers are billed, the included amount is credited.

    included
  • Public connection per node

    1 × IPv4 + /64 IPv6

    €0.00$0.00
  • Private Registry base fee

    Only used storage is billed

    €0.00$0.00
  • Maintenance window: Default window

    Tuesday to Thursday between 02:00 and 06:00 CET. The date is announced 72 hours in advance, the nodes are replaced sequentially.

    included
  • etcd backup from tier Highly available

    In Highly available and Enterprise, tier “Snapshots (7 days)” is included.

    included

The scope of services for each tier also includes: CSI and CCM drivers · Cluster Autoscaler.

Based on consumption

Worker node ND34 dedicated vCPU, 16 GB, per month
€77.60$90.02
Persistent volumeBlock Storage NVMe, RWO (one node writes)
€0.0860$0.0998 / GB
Shared file systemRWX (multiple nodes) via NFS 4.1
€0.0518$0.0601 / GB
Opened 2U server chassis from diagonally above on the workbench: heatsink with copper base over the socket, populated and locked memory banks, fan wall, power supplies with IEC connector at the back, drive bays at the front.

A production-ready cluster, item by item

Three dedicated workers, one 100 GB persistent volume each, one public ingress. Enough for an application with a database, cache and background processing — with capacity for the failure of one node.

Monthly costs of a cluster with 3 × ND3 and 300 GB persistent storage, net
ItemQuantityUnit priceTotal
Control plane, standard tierSLA 99.9%, automatic upgrades1€0.00$0.00€0.00$0.00
Ingress with Load BalancerPublic IPv4 and IPv6, Proxy Protocol v21€0.00$0.00€0.00$0.00
Worker node ND34 vCPU dedicated, 16 GB RAM, 160 GB NVMe3€77.60$90.02€232.80$270.05
Block Storage NVMePersistent volumes, 100 GB per worker300 GB€0.0860$0.0998 / GB€25.80$29.93
Outbound traffic30 TB per worker included90 TB€0.00$0.00€0.00$0.00
Net total per month€258.60$299.98

The result

Compute capacity
12 dedicated vCPUs
Memory
48 GB
Local NVMe
480 GB
Persistent storage
300 GB
Cost per vCPU
€21.55$25.00
Total net
€258.60$299.98
Gross per monthincl. 19% VAT.
€307.73$356.98

Sizes suitable as workers

A flavor is the size of a node: vCPU, memory and local NVMe in a fixed combination. We do not recommend sizes with shared cores for production clusters. Kubernetes' own processes run permanently on every node — they consume their share of the quota faster than the application does.

Select pricing unit

Monthly price is also the cap for hourly billing

Instance types suitable for node pools with vCPU, memory, local NVMe and price per hour or month
ConfigurationvCPURAMLocal NVMePrice / month
ND2AMD EPYC (dedicated)28 GB80 GB€38.80$45.01
ND3AMD EPYC (dedicated)416 GB160 GB€77.60$90.02
ND4AMD EPYC (dedicated)832 GB240 GB€138.99$161.23
ND5AMD EPYC (dedicated)1664 GB360 GB€276.49$320.73
NM4AMD EPYC (dedicated)864 GB320 GB€193.30$224.23
NA4Ampere Altra (shared)816 GB160 GB€21.49$24.93
NA5Ampere Altra (shared)1632 GB320 GB€41.49$48.13
NG-L4AMD EPYC (dedicated)848 GB400 GB€540.00$626.40

NG-L4 belongs in a separate pool with the taint nvidia.com/gpu. A taint is a restriction mark on the node: only workloads that really need a graphics card and explicitly tolerate the mark end up there.

Inference pool with graphics cards

Any instance size from the catalogue is permitted as a worker, including the 10 GPU configurations. They run in their own node group at the same hourly rate as the instance and with the same cap on the monthly price. The device plugin for NVIDIA is rolled out when the group is created.

A GPU group may scale down to zero. Nodes that the autoscaler shuts down cost nothing from the moment they are shut down — with hourly billing, you are only charged for what has run.

All GPU configurations with hourly rate

Calculation example · 2 × NG-RTX4000

1 × NVIDIA RTX PRO 4000 Blackwell SFF, 24 GB GDDR7 per node · location Frankfurt am Main, net

Hourly rate per node
€0.2932$0.3401
2 nodes per hour
€0.5864$0.6802
Pool in continuous operation, from 730 h per month
€428.00$496.48
Example cluster above, 3 × ND3 with volumes
€258.60$299.98

Cluster with inference pool per month

€686.60$796.46

Standard tier control plane at no extra charge. If the pool runs for less than 730 hours, the hourly rate per hour run applies.

The difference lies in the control plane

All three tiers deliver the same Kubernetes version, the same drivers and the same workers. What differs is the resilience of the control plane, the upper limit for nodes and the scope of evidence.

Standard

Control plane free of charge — you only pay for the worker nodes.

€0.00$0.00/ month per cluster

SLA
99.9%
Max. workers
100
  • Managed control plane
  • Automatic upgrades
  • CSI and CCM drivers
  • Cluster Autoscaler
  • Ingress with Load Balancer

Highly available

recommended

Control plane distributed across three fire zones.

€65.70$76.21/ month per cluster

SLA
99.99%
Max. workers
500
  • Everything from Standard
  • 3-zone control plane
  • etcd backup every 15 minutes
  • Private API endpoint
  • Audit log export

Enterprise

For regulated environments requiring evidence.

€177.84$206.29/ month per cluster

SLA
99.99% with service credit
Max. workers
2,000
  • Everything from High availability
  • Dedicated control plane
  • Multi-region federation
  • CIS benchmark hardening
  • BSI C5 certificate
  • 24/7 escalation path
Feature comparison of the three Kubernetes tiers
FeatureStandard€0.00$0.00 / monthHighly available€65.70$76.21 / monthEnterprise€177.84$206.29 / month
Availability commitmentmeasured by the availability of the API server99.9%99.99%99.99% with service credit
Worker nodes per cluster1005002,000
Control planeone fire zone, managedthree fire zones, active/activededicated, without other tenants
etcd backupdaily, in a second regionevery 15 minutesevery 15 minutes, with WORM lock (immutable until expiry)
API endpointpublic, with IP allowlistadditionally private in the vRack (your private network)additionally private in the vRack
Private registrysee Private Registry sectionone registry per projectmultiple registries, mirror includedmultiple registries, mandatory signature possible
Audit log7 days in the consoleExport to Object Storage or LokiExport, audit-proof
HardeningUpstream defaultsUpstream defaultsCIS benchmark (hardening catalogue), documented
CertificatesISO 27001ISO 27001ISO 27001 and BSI C5
EscalationTicket, 4 hoursTicket, 1 hour24/7 phone number, named contact

What is already running in the cluster

Four components connect Kubernetes to our infrastructure. They are installed, versioned and updated with the cluster — without you having to maintain a Helm chart.

CSI driver

The storage driver csi.block.entronyx.cloud provisions volumes on Block Storage NVMe, csi.file.entronyx.cloud mounts NFS shares. Four StorageClasses (storage profiles) are pre-installed, nvme-delete is the default.

Access modes
RWO (one node) on block, RWX (multiple) via NFS
Online expansion
yes, without restarting the pod
Snapshots
VolumeSnapshotClass, incremental
Topology
Volume remains bound to its fire zone

Cloud Controller Manager

The CCM connects Kubernetes to our API: it sets the provider ID on each node, removes deleted instances from the cluster and creates a public address for each service of type LoadBalancer.

Load Balancer
annotatable via service.beta.entronyx.cloud/…
Method
round-robin, least-connections, source-hash
Proxy Protocol
v2, for real client IP
Routes
Pod network is announced in the vRack

Cluster Autoscaler

You set a lower and upper limit per node pool. If a pod cannot be placed due to missing capacity, the autoscaler creates a new node. Instance provisioning: on average 35 seconds, guaranteed under 60 seconds. Pools may scale down to zero.

Selection process
least-waste
Scale down
after 10 minutes below 50% utilisation
Protection
PodDisruptionBudgets are respected
Scale from zero
yes, for GPU and batch pools

Ingress and network

Cilium, the cluster's network plugin, runs in eBPF mode and replaces kube-proxy. ingress-nginx and Gateway API v1 are available as an add-on, cert-manager fetches certificates via DNS-01 against our Anycast DNS.

CNI
Cilium, eBPF, without kube-proxy
Network policies
NetworkPolicy and CiliumNetworkPolicy
Observability
Hubble flows, 24-hour retention
Pods per node
110, pod CIDR /16 by default

Your images are stored where the nodes are

A managed, private container registry per project: OCI-compliant (the open standard for container images), in the same location as the cluster, with vulnerability scanning on upload and retention rules that prevent storage from filling up unnoticed.

Scan on upload

Every new layer is checked against the vulnerability database after the push, before the image can be delivered. The finding is attached to the digest — the checksum of the image — and not the tag: a newly set tag inherits it, a new build does not.

Triggered by
every push, without intervention
Rescan
daily against the updated database
Block
per severity, by default from critical
Exceptions
per repository, with expiry date and reason

Retention rules

Without a rule, a registry grows monotonically: every build stores a version, none disappear. The rules work per repository and can be viewed in a dry run before execution.

Retain
the last n versions per repository
Protection pattern
tags like v* or release-* always remain
Untagged
manifests without a tag are dropped after n days
Archive
older versions move to the archive class

Connection to the cluster

The cluster logs in with a robot account that only has read access. The access token is stored as an imagePullSecret — the access secret for retrieving images — in the namespace and is inherited by all pods via the service account.

Account type
robot account, not your user account
Permissions
separated by pull, push and delete
Term
token with expiry date, renewable
Commitment
to the service account instead of every deployment

Mirror of public registries

A rollout across many nodes requests the same image many times simultaneously — exactly the case where public registries throttle anonymous requests. The mirror fetches the image once and then delivers it from our network.

Effect
no throttling during rollout
First request
is passed through and cached
Origin
digest remains identical to the original
Network
retrieval from the cluster does not leave our network

Storage classes and prices

The registry has no base fee. It stores layers and manifests in object storage and is billed at its rates — €0.0070$0.0081 per GB and month by default. 250 GB of used storage therefore costs €1.75$2.03 net per month. The actual usage after removing duplicate layers is counted, not the sum of the image sizes.

Private registry storage classes, net per month — the amount in the last column is the price per GB multiplied by the example quantity
Storage classBasisper GB / monthMinimum quantityExample quantityExample / month
Registry StandardDefault setting. Hosts application images, base images and Helm charts.Object Storage Standard€0.0070$0.00811 GB250 GB€1.75$2.03
Registry PerformancePure NVMe backend for large images and rollouts across many nodes simultaneously.Object Storage Performance€0.0180$0.02091 GB250 GB€4.50$5.22
Registry ArchiveTarget for retention rules: expired versions that must be kept for evidence purposes.Cold Archive€0.0024$0.00281000 GB1 TB€2.46$2.85

Set up and use in the cluster

Registry, robot account, scan rule, retention and mirror are five commands. In the cluster, it remains standard Kubernetes: a secret of type dockerconfigjson, bound to the service account of the namespace.

registry-einrichten.sh
# Create registry — storage class and region as with Object Storage
entronyx registry create prod \
  --region fra1 --class standard --quota 250
 
# Robot account with read access only, for the nodes of the cluster
entronyx registry robot create ci-pull \
  --registry prod --scope "repo:*:pull" --ttl 90d
 
# Check rule: images with critical vulnerability are not delivered
entronyx registry policy set prod \
  --scan-on-push --block-severity critical --block-unscanned
 
# Retention: the last 10 versions per repository remain,
# untagged manifests are dropped after 7 days
entronyx registry retention set prod \
  --keep-latest 10 --keep-tagged "v*,release-*" \
  --purge-untagged-after 7d --archive-after 180d
 
# Mirror for a public registry — pulls run via us afterwards
entronyx registry mirror add prod \
  --upstream docker.io --cache-ttl 24h
 
# Store robot account credentials as imagePullSecret in the cluster
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
The robot account gets read-only permissions. A token with write access belongs in the build chain, not in the cluster.
registry-secret.yaml
apiVersion: v1
kind: Secret
metadata:
  name: entronyx-registry
  namespace: production
type: kubernetes.io/dockerconfigjson
stringData:
  # Generated with: entronyx registry robot token ci-pull --format docker
  .dockerconfigjson: |
    { "auths": { "prod.registry.entronyx.cloud": { "auth": "<base64>" } } }
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: default
  namespace: production
# The service account pulls the secret for all pods in the namespace,
# so that it does not have to be repeated in every deployment
imagePullSecrets:
  - name: entronyx-registry
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  namespace: production
spec:
  template:
    spec:
      containers:
        - name: web
          image: prod.registry.entronyx.cloud/team/web:1.8.2
        # The mirror replaces the public registry: the same line,
        # different origin, no rate limiting in the rollout
        - name: cache
          image: prod.registry.entronyx.cloud/mirror/library/valkey:8
The secret on the service account saves repetition in every deployment. The mirror path mirror/library/… replaces the public origin without changing the digest.
Shelf with labelled, equally sized containers, one compartment is pulled out.

The ENTRONYX CLOUD registry has no base fee: you are billed for the storage used after deducting duplicate layers. A pull from your own cluster does not leave our network and therefore costs nothing.

Private registry · billing by usage

One interface for a fleet of clusters

Rancher is operated as a managed service: you log in, connect clusters and assign permissions. Updates, backups and availability of the Rancher instance are our responsibility.

Multiple clusters, one interface

Rancher shows the state, utilisation and events of all connected clusters side by side. The cluster view is a view of the same API server that kubectl addresses — no second state that could diverge.

Access
one login process for all clusters
kubectl
built-in console, or continue locally
Events
merged across all clusters
Operations
the instance is updated by us

Clusters outside ENTRONYX, too

An external cluster is imported: Rancher outputs a manifest that starts an agent in the target cluster and establishes the connection from the inside out. The external API server does not need to be publicly accessible for this.

Requirement
compliant cluster from version 1.30
Connection
originating from the agent, via TLS
Depth of intervention
observe and apply, no modifications
Detach
remove agent, the cluster continues to run

Federated permissions instead of a second user list

Rancher does not maintain its own user management. Whoever logs in comes from the same directory service as in the console. The roles come from the rights federation: one group, one assignment, effective in all assigned clusters.

Login
OIDC (login standard) against your directory service
Roles
from the rights federation, not maintained twice
Scope
per instance, cluster or project
Revocation
leaving the group takes effect immediately

Application catalogue and fleet rollout

Helm charts — the package format for Kubernetes applications — from a shared catalogue can be rolled out to a selection of clusters simultaneously — filtered by label, for example to all clusters with the label stage=production.

Source
own catalogue or your Helm repositories
Selection
via labels, not via lists
Order
gradual, stopping on errors
Reconciliation
deviations are reported

From empty Rancher to fleet

  1. 01

    Create instance

    a few minutes

    Select region, connect directory service. The instance gets its own name under our domain and a certificate that is renewed automatically.

  2. 02

    Adopt your own clusters

    without agent

    Clusters from your ENTRONYX projects are connected via the API. Nothing changes in the cluster that you would need to revert.

  3. 03

    Import third-party clusters

    a manifest

    For clusters with other providers or in your own data centre, Rancher generates a manifest. When applied, it starts the agent that establishes the connection from the inside.

  4. 04

    Assign permissions

    from the identity federation

    Groups are assigned roles — for the instance, for individual clusters, or for projects within a cluster. There is no second user list that needs to be maintained.

  5. 05

    Start operations

    running

    Roll out catalogue applications, compare states, track events. For daily work, kubectl remains usable without changes — Rancher complements it, it does not replace it.

rancher-einrichten.sh
# Create Rancher instance; login runs via the same
# Directory service like the console
entronyx rancher create zentral --region fra1 --sso oidc
 
# Take over an ENTRONYX cluster — no agent needed, the connection
# is created via the API
entronyx rancher attach zentral --cluster prod-fra
 
# Import an external cluster: Rancher outputs a manifest,
# which starts an agent in the target cluster
entronyx rancher import zentral --name kunde-onprem > agent.yaml
kubectl --kubeconfig ~/.kube/onprem apply -f agent.yaml
 
# Rights come from the rights federation, not from a second user list
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
Importing a third-party cluster is the only step that changes anything in the target cluster — it starts an agent there and nothing else.

When you need this — and when you don't

Rancher is an additional component in your chain. With a single cluster and a team that already works with kubectl, it brings more interface than benefit. From the third cluster onwards, or at the latest with separate teams or locations, the calculation changes.

Operations without and with Managed Rancher in comparison
FeatureOne cluster, one teamMultiple clusters, teams, or locations
Accessone kubeconfig, maintained locallyone login process for all clusters
PermissionsRoleBindings directly in the clusterRoles once in the identity federation, effective everywhere
Overviewkubectl and custom dashboards are sufficientState of all clusters side by side
Third-party clustersseparate toolchain per providerimported, in the same interface
RolloutHelm against one clusterSelection via labels, in stages
Effortnone — there is nothing extra to learnone more interface your team needs to know
Our recommendationyou are better off without RancherManaged Rancher, from three clusters

Versions and upgrade path

We maintain three minor versions in parallel. A new version is available no later than six weeks after the upstream release, and the oldest continues to run for at least twelve months.

The window per version spans around sixteen months — from the day of availability to the end of support in the table. Within this window, the version receives security updates and bug fixes, but not afterwards. If a version expires without you having upgraded, we will upgrade the control plane to the next minor version during an announced maintenance window.

Supported Kubernetes versions with availability and end of support
Versionavailable sincesupport untilStatus
1.3604/202608/2027Standard
1.3512/202504/2027maintained
1.3408/202512/2026maintained

Upgrade process

  1. 01

    Preflight

    before the maintenance window

    Check for deprecated API groups, missing PodDisruptionBudgets (the minimum number of running pods per application) and add-ons whose version does not match the target version. The result is a list, not a guess.

  2. 02

    Control plane

    5 to 15 minutes

    The control plane is upgraded first. In the Highly Available tier, the API server remains accessible throughout the entire process because the three instances switch one after the other.

  3. 03

    Node pools

    rolling

    Each pool is renewed with Surge 1: a new node is added, an old one is cordoned, drained and removed. PodDisruptionBudgets are respected; if necessary, the process waits.

  4. 04

    Version skew

    Limit

    There can be a maximum of three minor versions between the API server and the kubelet — the service that starts the containers on each node. As long as this gap is maintained, node pools can deliberately stay behind — for example, a pool with particularly sensitive workloads.

  5. 05

    Rollback

    only forwards

    A downgrade of the control plane is not possible because etcd migrates its schema. The way back is via a new cluster in the old version and applying your manifests.

Behaviour with deprecated API groups

A removed API group does not delete any objects. What is in the cluster stays there and continues to run — only the next apply, the next Helm upgrade or the next GitOps sync will fail, often months after the upgrade. The preflight run therefore searches the entire object inventory and not just your manifests in the repository. If it finds a usage, the upgrade is aborted instead of postponing the error into the future.

API groups removed by upstream reported by the preflight run
API groupAffected objectsremoved inReplacement
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

The change is usually one line in the manifest: swap group and version, field and object names remain the same. We announce exceptions in the release notes when the respective version is released.

Limits

The values are hard limits of the control plane, not recommendations. If you want to push them to the limit, you should talk to us beforehand about the distribution of the node pools — 2,000 nodes in a single pool behave differently than 2,000 nodes in forty pools.

Technical upper limits per Kubernetes tier
FeatureStandardHighly availableEnterprise
Worker nodes per cluster1005002,000
Node pools per cluster83264
Clusters per project525unlimited
Pods per node110110110
Services of type LoadBalancer520100
etcd database size8 GB8 GB8 GB
Persistent volumes per nodeLimit of the block storage connection161616

Cluster as code

Clusters, node pools, registries and autoscaling limits are resources in the Terraform provider. Anything you can click in the console, you can also version.

Command line
# Create cluster — the Control Plane is not charged
entronyx kube cluster create prod-fra \
  --version 1.36 --tier ha --region fra1 --private-endpoint
 
# Node pool with autoscaling between 3 and 12 workers
entronyx kube nodepool create workers \
  --cluster prod-fra --flavor nd3 --min 3 --max 12 --autoscale
 
# Mount credentials into the existing kubeconfig
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
The kubeconfig — the access file for kubectl — contains a short-lived token that is renewed via the ENTRONYX login service. For CI systems, you create a service account with a limited role instead.
main.tf
resource "entronyx_kube_cluster" "prod" {
  name             = "prod-fra"
  region           = "fra1"
  version          = "1.36"
  tier             = "ha" # 99.99%, Control Plane across 3 fire zones
  private_endpoint = true
  vrack            = entronyx_vrack.prod.id
 
  etcd_backup {
    interval = "15m"
    region   = "hel1" # Backup is located outside the cluster location
  }
}
 
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 # scales down to zero
  max_nodes = 4
 
  taints {
    key    = "nvidia.com/gpu"
    value  = "true"
    effect = "NoSchedule"
  }
}
Changing the version specification triggers an upgrade — first of the control plane, then rolling for the 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   # the cloud controller creates the public IP
  selector:
    app: web
  ports:
    - port: 443
      targetPort: 8443
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: data
spec:
  storageClassName: nvme-retain   # Volume survives the deletion of the claim
  accessModes: [ReadWriteOnce]
  resources:
    requests:
      storage: 100Gi
Both objects are standard Kubernetes. Without the annotations, the Load Balancer gets round-robin without Proxy Protocol; without storageClassName, nvme-delete applies.

Create cluster, configure workers

The control plane is ready in under five minutes. You configure node groups, registry and Rancher connection in the same run — with the same prices, the same locations and the same per-second billing, capped at the monthly price.

Control plane
€0.00$0.00
Example cluster
€258.60$299.98
Max. workers
2,000
Version
1.36