Kubernetes Clusters in Europe

What gets provisioned

You choose the node sizes and the cluster is built and handed over ready to use: control plane, container runtime, CNI networking, an ingress controller and a storage class backed by the same NVMe every other machine here uses. The kubeconfig is downloadable from your panel the moment it is up.

It is a real cluster on real VMs in our own data centres, not a managed abstraction over someone else's API. kubectl, Helm and anything that speaks to the Kubernetes API work exactly as they do anywhere else, because there is nothing non-standard in the middle.

• Control plane, CNI, ingress controller and a default storage class, configured
• kubeconfig in the panel - no ticket, no waiting
• Single-node for development, multi-node when you need to survive a node dying
• The same NVMe storage and European Tier III sites as every other product

Sizing the nodes

Start from what runs on the cluster rather than from a node count. Add up the CPU and memory requests of everything you intend to schedule, add the overhead of the control plane and the system pods, then leave enough headroom that one node can fail without the rest refusing to accept its pods.

Three small nodes generally beat one large one for anything you care about staying up, because a single node is a single reboot away from downtime. For development and CI, one node is fine and much cheaper.

What it costs

You pay for the nodes - the same CPU, RAM and NVMe pricing as any cloud server - plus a small flat management fee for the cluster itself. Kubernetes clusters start at 22 EUR per month.

That means a cluster is never mysteriously more expensive than the machines under it, and scaling it is the same arithmetic as scaling anything else here.

What people run on them

Microservice estates that have outgrown a single Docker host, applications that need rolling deploys without a maintenance window, and CI or agent workloads that want to scale out and then disappear again.

Self-hosted CI runners are a common pairing: a cluster gives them somewhere to burst into, and keeps build artefacts and source inside your own European infrastructure.

GitLab Runner· GitHub Actions Runner· Agent runners in the EU

Managed cluster or plain VMs

If you want to build the cluster yourself - a specific distribution, a particular CNI, an unusual topology - order plain cloud servers and treat them as nodes. Nothing here stops you, and the machines are identical.

Take the managed option when you would rather not spend the first week on the control plane, and when a working ingress and storage class on day one is worth more than choosing every component yourself.

Cloud Servers

Scaling, upgrades and moving in

Nodes can be added or resized as demand changes, the same way a cloud server can. Cluster upgrades are coordinated with you rather than applied under you, because a Kubernetes minor version is an API change and something in your manifests usually notices.

Migrating in is mostly manifest work: point Helm at the new cluster, restore persistent volumes from your own backups, then cut DNS over once the new ingress answers correctly.