Cloud Server for Kubernetes in Europe
Kubernetes is the standard orchestration platform for containerized workloads at scale. Running it well requires more than just installing k8s - you need sufficient hardware per node, reliable networking between nodes, and an understanding of what a minimum viable cluster actually looks like.
Hosting your Kubernetes cluster in Europe is a practical requirement if your users or data are here. Low-latency private networking between nodes, GDPR-compliant data residency, and physical proximity to your engineering team all push toward EU hosting.
Why EU hosting matters for Kubernetes
A Kubernetes cluster is a distributed system. Control plane components communicate constantly with worker nodes, and pods communicate with each other across the cluster. Network latency between nodes is not just a performance concern - it directly affects cluster stability. Etcd, the key-value store at the heart of Kubernetes, requires low-latency writes to maintain consistency. Nodes with high latency to the control plane can appear unhealthy and be evicted.
Placing all nodes in the same EU data center, or at least the same region, keeps inter-node latency under 1 ms. That is the baseline you want for a healthy cluster.
GDPR compliance is equally straightforward: workloads that process EU personal data should run on infrastructure that stays within EU jurisdiction.
Minimum server requirements
Kubernetes has real hardware requirements. The control plane and worker nodes have different profiles.
For the control plane node:
- RAM: 4 GB minimum (8 GB recommended for clusters with more than 10 workers)
- CPU: 2 cores minimum (4 cores recommended)
- Disk: 40 GB SSD (etcd is write-intensive; use fast disk)
For each worker node:
- RAM: 4 GB minimum per node
- CPU: 2 cores minimum per node
- Disk: 40 GB SSD per node
A production-ready minimum setup is 1 control plane node plus 2 worker nodes. For high availability, use 3 control plane nodes and 3 or more workers. k3s is a lighter alternative to full Kubernetes and can run on slightly less RAM, making it practical for smaller clusters.
Recommended DCXV configuration
DCXV cloud instances at https://dcxv.com/data-center#cloud start from EUR 15/month. For a 3-node Kubernetes cluster (1 control + 2 workers), three instances with 4 GB RAM and 4 vCPUs each is a reasonable starting point.
DCXV cloud instances on the same data center share a private network with very low inter-instance latency, which is exactly what Kubernetes needs. 24/7 engineer support is included without extra cost - useful when you are debugging a node that will not rejoin the cluster at midnight.
For larger clusters or workloads that need dedicated hardware guarantees, DCXV dedicated servers start from EUR 49/month.
Setup guide
Deploying a k3s cluster (lightweight Kubernetes) on three DCXV instances:
# On the control plane node: install k3s
curl -sfL https://get.k3s.io | sh -
# Get the join token from control plane
cat /var/lib/rancher/k3s/server/node-token
# On each worker node: join the cluster
curl -sfL https://get.k3s.io | K3S_URL=https://<control-plane-ip>:6443 K3S_TOKEN=<token> sh -
# Verify all nodes are ready (run on control plane)
kubectl get nodes
After the cluster is up, install an ingress controller and cert-manager for TLS:
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/main/deploy/static/provider/cloud/deploy.yaml
How many control-plane nodes
This is the decision to get right before anything is running on the cluster, because etcd keeps a quorum and quorum needs a majority. The counter-intuitive part is the second row:
| Control plane | Survives losing | Quorum needs | Pick it when |
|---|---|---|---|
| 1 node | Nothing - the API is gone | 1 of 1 | Development, CI, staging, anything you can rebuild |
| 2 nodes | Nothing, and it costs twice as much | 2 of 2 | Never - this is strictly worse than one node |
| 3 nodes | One node, with no loss of writes | 2 of 3 | Production, and the smallest that deserves the word |
| 5 nodes | Two nodes | 3 of 5 | Large clusters, or when a whole rack can go |
Two nodes is the trap: with an even number there is no majority to be had, so losing either one takes the API server down just as a single node would, and you have paid twice for it. Workers are the opposite - they are cattle, add and remove them freely, and nothing about the count is load-bearing.
Performance expectations
On a 3-node k3s cluster using 4 GB / 4 vCPU instances:
- Pod scheduling latency under 2 seconds for typical workloads
- Inter-pod network throughput of 1-5 Gbps within the same data center
- Ingress handling 1,000-3,000 HTTP requests per second depending on workload
- Control plane API response times under 50 ms for standard kubectl operations
- etcd write latency under 5 ms with SSD-backed storage
These are baseline figures for a cluster running moderate workloads. Heavy batch jobs, large numbers of pods, or workloads with intense inter-service communication will require additional nodes or larger instances.
These are expectations for hardware of this class, not measurements from our own lab. Treat them as a starting point for sizing and measure your own workload: real numbers depend on your data, your queries and your tuning far more than on the provider.
