Kubernetes Platforms on STACKIT, IONOS, and Open Telekom Cloud: What Actually Runs There

Key Points:

• STACKIT Kubernetes Engine (Schwarz Group), IONOS Managed Kubernetes, and Open Telekom Cloud CCE (Deutsche Telekom) all give you a managed control plane in German or EU data centers. STACKIT and IONOS hold their own CNCF Certified Kubernetes listings; OTC CCE inherits conformance from the Huawei Cloud CCE stack it runs on. Standard Kubernetes tooling runs on all three.
• The real gap versus AWS, GCP, or Azure is not Kubernetes. It is the surrounding ecosystem: thinner managed service catalogs, thinner GPU supply, and weaker Infrastructure-as-Code coverage. Terraform and Crossplane providers are mature for hyperscalers and patchy here.
• Because all three run conformant Kubernetes, the vendor-neutral layer is identical everywhere: Kyverno or OPA Gatekeeper for admission policy, Argo CD or Flux for GitOps, KServe plus vLLM for model serving, Prometheus and Grafana for observability.
• Qovery runs on top of any of the three through bring-your-own existing Kubernetes cluster, the same way it runs on AWS, GCP, Azure, and Scaleway. It adds git-push deploys, preview environments per pull request, auto-stop, per-environment RBAC, and managed upgrades while the cluster and the cloud bill stay in your own account.
• Pick on data residency, certifications (BSI C5, ISO 27001), managed service coverage, and GPU needs. Not on Kubernetes version support, where the three are broadly comparable.

I get a version of this question almost every week now, and it has gotten sharper lately: "We want our engineers, and increasingly our AI agents, to provision Kubernetes resources and even host open-weight models, but everything has to stay in the EU and nothing can get deployed outside approved limits. Which European cloud actually does all of that?"

Here is my honest answer after watching teams move onto STACKIT, IONOS, and Open Telekom Cloud. The managed Kubernetes part is close to a commodity. All three give you a conformant control plane in an EU data center, and your manifests, your Helm charts, and your GitOps run the same as they did on EKS. The differences that matter are managed service breadth, GPU availability, IaC provider coverage, and certifications. And the real work, the part nobody hands you, is the developer-facing platform you still have to build on top. That work is identical on all three.

Let me prove it.

What are STACKIT, IONOS, and Open Telekom Cloud, and why do EU teams pick them over AWS, GCP, or Azure?

All three are European cloud providers offering managed Kubernetes from EU data centers under EU-only corporate ownership. That ownership is the single reason teams pick them. It is jurisdictional control over data, not a better Kubernetes.

STACKIT is operated by the Schwarz Group, the parent of Lidl and Kaufland, with data centers in Germany (Neckarsulm, Ellhofen) and Austria. Its Kubernetes service is STACKIT Kubernetes Engine (SKE).

IONOS Cloud is part of IONOS SE / United Internet, with data centers in Frankfurt, Berlin, Paris, London, and Spain, plus US regions. Its service is IONOS Managed Kubernetes, and it tends to be the simplest on pricing.

Open Telekom Cloud is operated by T-Systems (Deutsche Telekom), built on a Huawei Cloud-derived OpenStack stack, with regions in Germany (Biere, Magdeburg) and the Netherlands. Its service is CCE, the Cloud Container Engine.

The driver is always the same: GDPR Chapter V transfer rules, the Schrems II ruling that invalidated Privacy Shield, public-sector procurement rules, and BSI C5 attestation requirements.

I will say plainly what you give up. Smaller managed service catalogs, fewer regions, thinner GPU supply, smaller partner ecosystems, and less third-party tooling coverage. A piece that pretends otherwise is not worth reading.

How do STACKIT Kubernetes Engine, IONOS Managed Kubernetes, and Open Telekom Cloud CCE compare?

All three deliver a managed control plane with node-pool autoscaling and in-place version upgrades. The meaningful differences sit in control-plane pricing, GPU node availability, managed data services next door, IaC coverage, and certifications.

One nuance worth getting right on conformance. STACKIT SKE is listed in the CNCF conformance repo continuously from v1.24 through v1.36. IONOS Managed Kubernetes is listed from v1.27 through v1.35. Open Telekom Cloud does not file its own entry. CCE's conformance lineage belongs to Huawei Cloud CCE, the upstream product OTC runs. In practice CCE is the same conformant Kubernetes, but if a CNCF-listed badge matters to your procurement team, know where it actually comes from.

A few honest callouts. On GPUs, STACKIT is the strongest of the three, offering A100, L40S, and H100 flavors you can attach to SKE node pools. OTC gives you T4 and V100 flavors with the CCE AI Suite add-on, and has announced H100 for HPC, though I could not confirm H100 as a CCE node flavor. IONOS offers Cloud GPU VMs with H200, but GPU-backed Managed Kubernetes node pools are not documented, so plan to verify that with them directly before you commit a training workload.

On IaC, only IONOS ships a Partner-tier (verified) Terraform provider. STACKIT's provider is community-tier but vendor-maintained and heavily used, and OTC's provider is community-tier too. All three have Crossplane providers via Upjet, but these are early and community-maintained. If you expect the same provider depth you get on AWS, you will be disappointed, and for some primitives you will end up calling the provider's own API.

Which Kubernetes tooling runs unchanged, and which does not?

Because all three run conformant Kubernetes, the entire vendor-neutral CNCF layer installs and behaves identically. The only things that break are cloud-provider-specific integrations.

Runs as-is on all three: Argo CD and Flux for GitOps (both CNCF graduated), Helm, Kyverno and OPA Gatekeeper for admission policy (both graduated now), Prometheus, Grafana, Loki, cert-manager, Istio or Cilium, and KServe plus vLLM for inference. These do not care which EU cloud they land on.

Needs attention: workload identity and secrets. None of the three gives you an IRSA or GKE Workload Identity equivalent, so plan for External Secrets Operator plus Vault or the provider's secret store. LoadBalancer annotations differ, storage classes differ (ionos-enterprise-essential on IONOS, perf-0 through perf-6 on STACKIT, Everest classes on OTC), and DNS integration depends on whether external-dns supports your DNS provider.

Needs the most work: Crossplane and Terraform coverage for cloud primitives beyond Kubernetes, for the reasons above. The practical move is to prefer vendor-neutral components deliberately, because that is exactly what keeps the stack portable between the three providers and back to a hyperscaler if your sovereignty requirements change.

On the model-serving question specifically, since it comes up a lot: yes, you can self-host open-weight models on these clusters, and that keeps inference data in-jurisdiction instead of calling a US API. vLLM reports up to 24x higher throughput than vanilla HuggingFace Transformers serving, which makes it the usual choice behind KServe. The catch is GPU supply, which is thinner than on hyperscalers. Plan for smaller models or a dedicated EU GPU provider if your model does not fit the flavors on offer.

What do you still have to build after the cluster is running?

A managed control plane gives you an API server and node pools. That is it. The developer-facing platform is still yours to assemble, and it is identical work on all three providers.

The missing layer is long: CI/CD and image builds, ingress and TLS, per-environment configuration and secrets, ephemeral preview environments, database provisioning and backups, RBAC per team and per environment, cost controls, and the recurring cluster and node upgrades. On a hyperscaler you can paper over some of this with managed services. On a sovereign cloud, with a thinner catalog next to the cluster, more of it falls on your team.

Cost control is where this bites hardest, and I have the receipts. Cast AI's Kubernetes cost benchmark, analyzing thousands of clusters, found that only 13% of provisioned CPUs and 20% of provisioned memory were actually used. Without quotas, non-production auto-stop, and right-sizing, idle environments quietly dominate your bill. The sovereign cloud does not fix this for you.

You have three honest ways to close the gap: build it yourself with CNCF components, buy an internal developer platform, or adopt a full distribution like Rancher or OpenShift.

How do you add self-service deployment on top of STACKIT, IONOS, or OTC?

The fastest route is an internal developer platform that connects to a Kubernetes cluster you already run, rather than one that only provisions hyperscaler infrastructure. Here is how the real options stack up.

Qovery runs on a bring-your-own existing Kubernetes cluster, which is the supported path for STACKIT SKE, IONOS Managed Kubernetes, and OTC CCE, exactly as it supports AWS, GCP, Azure, and Scaleway. I want to be precise here: there is no named first-party integration with those three providers, and there does not need to be. The BYO Kubernetes path is what makes them work. On top of the cluster you get git-push deployments, preview environments per pull request, environment auto-stop for non-production, per-environment RBAC, managed cluster upgrades, and databases backed by managed cloud services.

Why does BYOC matter so much here specifically? Because the cluster, the data, and the cloud bill all stay in the EU provider account and in your company's name. That is the whole point of choosing a sovereign cloud, and a SaaS platform that provisions and holds the infrastructure for you would undo it.

The alternatives are legitimate, and I will describe them straight. Rancher is excellent for managing a fleet of clusters. OpenShift is a supported full distribution, heavier and licensed, and the natural fit if you already run Red Hat. Humanitec targets large organizations orchestrating a bespoke platform. Backstage is a developer portal, not a deployment runtime, so you pair it with something that actually ships code. Argo CD plus Helm is the pure DIY path if you want to own every layer.

One thing an IDP does not replace: admission policy still belongs to Kyverno or Gatekeeper, model serving to KServe plus vLLM, and cloud primitive provisioning to Terraform or Crossplane. Qovery does not do those, and you should be suspicious of any platform that claims to do all of it.

Rough guidance by team size. A small team with no platform engineers gets the most from a managed IDP like Qovery on BYO Kubernetes. A mid-size team with one or two platform engineers can go IDP or assemble CNCF components. A regulated enterprise with an existing Red Hat footprint should look hard at OpenShift.

Does this setup actually satisfy GDPR and data sovereignty?

Hosting on an EU-owned provider in an EU region removes the third-country transfer problem for the data you run there. That is real, and it is the main thing Schrems II was about. But sovereignty is a property of the full stack, not one cluster.

What EU residency on STACKIT, IONOS, or OTC gives you: data at rest and compute inside the EU, operated by an EU-headquartered company, under EU law.

What it does not automatically give you: compliant SaaS add-ons, EU-only CI runners, EU-only logging and monitoring, and EU-only LLM inference. A single US-hosted observability backend or AI API in your chain can reintroduce exactly the transfer you were trying to avoid. Audit the whole thing.

On certifications, check per provider rather than assume. STACKIT lists BSI C5 Type 2 and ISO 27001. IONOS holds BSI C5 (scoped to specific services, so confirm Managed Kubernetes is covered) and an ISO 27001 IT-Grundschutz certificate that does name Managed Kubernetes in Germany. Open Telekom Cloud holds BSI C5 Type II and ISO 27001. Certifications are usually platform-level, so verify the audit scope for the exact service you deploy.

Self-hosting open-weight models with vLLM or KServe on EU GPUs is the clean way to keep inference in-jurisdiction instead of calling a US model API. And none of this is legal advice. If GDPR compliance is on the line, bring in your DPO.

How do you migrate an existing Kubernetes workload onto one of these?

Because workload manifests are portable, the migration effort concentrates in cloud-specific integrations. Here is the order I would run it.

1. Inventory your cloud-specific dependencies: IRSA or Workload Identity, managed databases, object storage, queues, provider-specific ingress annotations, and KMS.
2. Replace identity and secrets with External Secrets Operator plus Vault or the provider's secret store.
3. Map storage classes and re-test volume behavior. Validate restore, not just that snapshots exist.
4. Stand up the vendor-neutral layer first: Argo CD or Flux, Kyverno baseline policies, the Prometheus stack, cert-manager, and ingress.
5. Migrate data and cut over: replicate databases, run both environments in parallel, and cut DNS last.
6. Add the developer-facing layer (Qovery on BYO Kubernetes, or your chosen alternative) so teams keep git-push deploys and preview environments after the move.
7. Set quotas, LimitRange, and non-prod auto-stop on day one, so the new cluster does not inherit the old cluster's waste.