How to Evaluate a Managed Kubernetes Provider in Europe

September 2026 • Comparison

A managed Kubernetes price page does not tell you what happens when something goes wrong at night. This checklist covers the questions that decide that, and for each one it shows what several European providers actually publish. Every provider fact comes from the provider’s own documentation or price page, read in September 2026, and is linked in the Sources section.

1. Ask what is actually managed

Providers draw the line between their job and yours in different places. Exoscale’s SKS service-level agreement is explicit: it covers the availability of the control plane only, not worker nodes, pods, volumes, applications or data. The customer remains responsible for workloads, cluster access control, persistent data, backups, disaster-recovery planning and restore procedures.

Other providers describe more automation. IONOS says its managed service handles updates and security fixes automatically, and that you choose when they run. Infomaniak says you can update the control plane and the worker nodes at any time, and that it manages all Kubernetes components. Whatever the wording, get written answers to these questions:

• Who upgrades the control plane, who upgrades the worker nodes, and who decides the timing?
• Who patches the operating system of the worker nodes?
• Who owns backups of cluster state and of your persistent volumes?
• Which add-ons (networking, ingress, metrics) are provided, and who keeps them current?

2. Check which control-plane tier you are really buying

A free control plane is not the same product as a paid one. The free tiers below are shared and carry no SLA, while the paid tiers add replicas, a dedicated datastore and a written availability target.

This matters because of how Kubernetes itself is built. As our article on managed versus self-hosted Kubernetes explains, the Kubernetes documentation recommends multi-member etcd clusters for production, and etcd needs a majority of its members to make changes. A single API replica on a shared datastore is a reasonable choice for development and a weak one for production.

3. Read the SLA for what it covers

Two providers can both advertise a percentage and mean very different things. Ask what is measured (control-plane API availability, node availability, or both), over what period, what is excluded, and what you receive if the target is missed. Exoscale, for example, credits 50% of the monthly fees for affected resources when uptime falls between 99.95% and 98.3%, and 100% below that. It also excludes failures in nodes, volumes and pods, because its SLA applies to the control plane.

It also helps to translate the percentage into time. In a 30-day month:

Scaleway lists 99.5% for its dedicated Kapsule control planes, Infomaniak lists 99.9% for its dedicated tiers, and Exoscale lists at least 99.95% for its Pro plan. Those numbers are only comparable if the definitions match, so read the definitions before you compare the numbers.

4. Ask whether the vCPU is dedicated

Shared vCPUs are scheduled on physical cores that several virtual machines use at once. Scaleway’s documentation describes the consequence plainly: during peak demand from neighbouring workloads, your workloads can slow down through CPU contention, known as CPU steal. Dedicated vCPUs give exclusive access to physical cores and consistent performance. Scaleway’s own guidance lists worker nodes in Kubernetes clusters among the typical uses of shared instances, which is a fair choice for development and a real trade-off for production.

IONOS lets you choose between dedicated cores and vCPUs for its managed Kubernetes worker nodes. Many providers do not state which one you get on a given plan. If the documentation is silent, ask in writing, because it changes both the performance and the price you should expect.

5. Check storage replication, and where the copies live

Persistent volumes are where a Kubernetes cluster keeps the data you cannot rebuild, so ask how they are protected:

• Exoscale block storage keeps two copies of the data on distinct servers, replicated within the same zone, with 5,000 IOPS per volume.
• Scaleway block storage (NVMe volumes) is triple-replicated with a 99.99% SLA, and its FAQ notes that IOPS can fluctuate during peak load.
• Infomaniak block storage runs on an encrypted Ceph cluster with three replicas on NVMe, and states up to 4,000 IOPS guaranteed.
• Hikube states that it replicates data synchronously across three Swiss datacenters.

Replication protects against the loss of a disk or a server. It is not a backup, because a mistaken deletion is replicated too, and copies inside one zone or one site do not protect you from losing that zone or site. Ask where every copy lives, and plan a separate, off-site backup for anything you cannot afford to lose.

6. Read the support terms, not the headline

“24/7 support” can mean very different things. The table shows what each provider says is included at no extra cost and what the faster or round-the-clock cover costs.

Note what these figures are. They are targets for the first response, not for resolution. OVHcloud says so itself: its handling time ends when the team starts processing the ticket, not when the incident is resolved, and it gives no guarantee of meeting the objectives. When you compare providers, ask for the resolution target, the escalation path, the channels and the languages, and check whether support is billed as a percentage of your spend.

7. Look for traffic charges and hidden line items

The monthly price of a node is rarely the whole bill. Ask about outbound traffic, public IPv4 addresses, load balancers, snapshots, object-storage requests and support fees. Infomaniak states that bandwidth is free, except object storage above 10 TB of bandwidth consumed, and UpCloud states that it has no outbound traffic costs. Several providers price their faster support tiers as a percentage of your monthly spend, as the table above shows, so that line item grows with your usage.

8. Ask where the data lives, including backups and logs

Data location covers more than the primary database. Ask where backups, logs and monitoring data are stored, which entity operates the infrastructure, and which country’s law applies to that entity. Hikube gives an example of a specific answer: it states that no data passes through foreign servers, including backups, logs and monitoring metrics, and that data residency attestations are available on request for auditors. Ask any provider for the same level of detail in writing.

9. Check the exit before you enter

Kubernetes itself is portable, so the lock-in comes from everything around it. Ask whether the cluster is standard upstream Kubernetes with a normal kubeconfig, whether Terraform, Helm and GitOps tools work against it, how you export your data and volumes, and how long resources are retained after you terminate. A provider that answers these clearly is one you can leave, and that makes it easier to trust while you stay.

10. Run a two-week test before you commit

Ask for a trial or a low-commitment plan, and test the things that matter rather than the console demo:

• Time to first cluster. Create a cluster and time it.
• Stateful data. Deploy an application with a persistent volume, delete the pod, and confirm the data survives.
• An upgrade. Upgrade the cluster by one minor version and note what you had to do yourself.
• A restore. Restore from a backup or a snapshot into a new cluster. A backup you have not restored is an assumption.
• Support. Open a ticket at night, classify it as urgent, and record both the first-response time and the time to resolution.
• Performance under load. Run a CPU-heavy job on a worker node and check for CPU steal, and test the disk with a fsync-heavy benchmark.

Two commands cover the last item. On a worker node, vmstat 1 10 prints a column named st for steal time; sustained non-zero values while your job runs mean that other tenants are taking your CPU. For disks, the etcd performance documentation explains that request latency is bounded by the network round-trip time plus the time fdatasync needs to commit data to permanent storage, and it puts typical fdatasync latency at about 10 ms for a spinning disk and often under 1 ms for an SSD. A common way to measure it is fio with synchronous writes and fdatasync:

fio --name=disk-latency --directory=/mnt/test --rw=write --ioengine=sync --fdatasync=1 --size=22m --bs=2300

The report includes fdatasync latency percentiles. Red Hat’s etcd guidance treats a 99th-percentile fsync latency below 10 ms as the bar for a disk that can host etcd, so use that as a reference point when you compare providers.

Where Kube-DC stands

Here is how Cloud Acropolis Kube-DC answers the same questions. We list what is documented and what is not, so you can test it against your own checklist.

Sources (read in September 2026)

• Exoscale: SKS service-level agreement
• Exoscale: support plans
• Exoscale: SKS product page
• Exoscale: block storage
• Infomaniak: managed Kubernetes service
• Infomaniak: Public Cloud
• Infomaniak: premium support guide
• Scaleway: containers pricing (Kapsule)
• Scaleway: support plans
• Scaleway: shared vs dedicated vCPUs
• Scaleway: block storage FAQ
• OVHcloud: support levels
• OVHcloud: Standard support
• OVHcloud: Business support
• IONOS: Managed Kubernetes
• UpCloud
• Hikube by Hidora
• etcd: performance
• Red Hat: recommended etcd practices
• Kube-DC platform datasheet

Related reading

• Managed vs. Self-Hosted Kubernetes: The Technical Reality

Put Kube-DC through the checklist

Every point above can be tested on a Kube-DC package: dedicated vCPU, Ceph-backed NVMe storage, a dedicated public IPv4, S3-compatible object storage, your own tenant-administered Kubernetes clusters, and 24/7 support with a 4-hour resolution target. Order in a self-service portal, run the two-week test, and judge us on the results.