Kubernetes auf europäischen Cloud-Providern im Vergleich

Kubernetes auf deutscher oder europäischer Infrastruktur planen? WZ-IT vergleicht Provider und Betriebsmodelle anhand Ihrer Anwendungen, Daten, Ausfallziele und Zuständigkeiten und setzt die gewählte Plattform um. Europäische Kubernetes-Infrastruktur ansehen

Europäische Kubernetes-Angebote unterscheiden sich vor allem beim Betriebsmodell. Hetzner stellt Cloud- und Bare-Metal-Infrastruktur mit Kubernetes-Integrationen bereit. OVHcloud, IONOS, STACKIT, Open Telekom Cloud und Scaleway bieten jeweils einen Managed-Kubernetes-Dienst. Hinter demselben Produktbegriff liegen jedoch unterschiedliche Regionen, Plattformintegrationen, Service Levels und Verantwortungsgrenzen.

Die Einordnung folgt Betriebsmodell, Infrastrukturpfad, Regionen, Plattformintegrationen, Service Levels und Verantwortungsgrenzen. Diese Kriterien zeigen, welcher Provider zum konkreten Zielbild passt.

Inhaltsverzeichnis

• Die Anbieter im Überblick
• Hetzner
• OVHcloud
• IONOS Cloud
• STACKIT
• Open Telekom Cloud
• Scaleway
• Die wichtigsten Auswahlkriterien
• Warum EU-Region nicht automatisch Souveränität bedeutet
• Entscheidungsmatrix nach Ausgangslage

Die Anbieter im Überblick

Stand: 22. Juli 2026. Produktmerkmale, Regionen und Preise ändern sich. Vor einer Entscheidung müssen die aktuellen Leistungsbeschreibungen geprüft werden.

Die Tabelle ist keine Rangliste. Ein Managed Service reduziert bestimmte Aufgaben, kann aber stärker an das Cloud-Ökosystem gebunden sein. Ein selbst betriebener Cluster bietet mehr Gestaltungsfreiheit, verlagert dafür Lifecycle und Störungsbehandlung zum eigenen Team oder Betriebspartner.

Hetzner

Hetzner positioniert Kubernetes über seine Cloud- und Dedicated-Infrastruktur sowie offizielle Integrationen wie Cloud Controller Manager und CSI-Treiber. Ein nativer Hetzner Managed-Kubernetes-Service ist nicht die Grundlage dieses Modells. Cluster werden selbst oder durch einen Dienstleister aufgebaut und betrieben.

Das ermöglicht mehrere Architekturen:

• vollständig auf Cloud-VMs,
• Control Plane auf Cloud-VMs und Worker auf Dedicated Servern,
• direkt auf Bare Metal,
• als VMs innerhalb einer Proxmox-Private-Cloud.

Hetzner passt vor allem dann in die Shortlist, wenn API-gesteuerte Cloud-Ressourcen oder Dedicated-Leistung mit einem selbst definierten Kubernetes-Stack verbunden werden sollen. Der operative Umfang muss dafür vollständig geplant werden. Mehr dazu steht im Artikel Kubernetes auf Hetzner.

OVHcloud

OVHcloud Managed Kubernetes Service bietet eine verwaltete Control Plane, Node Pools, Load-Balancer- und Storage-Integration sowie private Vernetzung über das OVHcloud-Ökosystem. OVHcloud veröffentlicht eine klare Verantwortungsgrenze: Der Provider wartet die Control Plane, Kunden bleiben unter anderem für Worker, Pods, Container, Sizing und Datensicherung verantwortlich.

Zusätzlich können eigene Cluster auf Public-Cloud-VMs, Dedicated Servern oder Proxmox betrieben werden. Dadurch deckt OVHcloud sowohl native Managed- als auch Self-managed-Architekturen ab. Bei der Auswahl sind die konkrete Region, Angebotsstufe und benötigte Verbindung zwischen Public Cloud, vRack und Dedicated-Ressourcen relevant. Details behandelt Kubernetes auf OVHcloud.

IONOS Cloud

IONOS Cloud Managed Kubernetes betreibt die Kubernetes-Control-Plane und integriert Node Pools in die IONOS Compute Engine. IONOS nennt automatisierte Updates, Autoscaling, CSI-basierten Storage und eine über Regionen verteilte Control Plane als Bestandteile des Dienstes.

Das Angebot ist für Organisationen relevant, die Kubernetes als deutschen beziehungsweise europäischen Cloud-Service mit integrierten Compute-, Storage- und Netzwerkressourcen beziehen möchten. Wie bei jedem Managed Service müssen Workload-Sicherheit, GitOps, Observability, Backups und Anwendungsbetrieb separat bewertet werden.

STACKIT

Die STACKIT Kubernetes Engine ist ein verwalteter, CNCF-konformer Kubernetes-Dienst innerhalb der STACKIT Cloud. Die Dokumentation positioniert SKE für standardisierte Kubernetes-Anwendungen und containerisierte Workloads sowie für die Migration bestehender Anwendungen in die europäische Cloud.

STACKIT gehört in eine Shortlist, wenn ein deutscher Cloud-Anbieter, Managed Kubernetes und das STACKIT-Service-Ökosystem gemeinsam betrachtet werden sollen. Zu prüfen sind die verfügbaren Regionen und Zonen, die benötigten Plattformdienste, Netzwerkpfade, Supportmodelle und die Verantwortung oberhalb der Control Plane.

Open Telekom Cloud

Die Open Telekom Cloud stellt mit der Cloud Container Engine einen Kubernetes-basierten Cluster-Dienst bereit. Davon zu unterscheiden ist der zusätzliche Managed-Containers-Leistungsumfang der Telekom, der laut Leistungsbeschreibung Beratung, Aufbau und Betrieb von CCE-Clustern bis zu weiteren Plattformaufgaben umfassen kann.

Diese Trennung ist für Angebotsvergleiche wichtig: Der Cloud-Dienst selbst und ein zusätzlicher Managed-Service sind nicht dasselbe Produkt. Für öffentliche oder regulierte Organisationen können die Vertrags-, Zertifizierungs- und Supportmerkmale der Open Telekom Cloud relevant sein; die konkrete Eignung ergibt sich erst aus der Anforderungsliste.

Scaleway

Scaleway bietet zwei Modelle. Kapsule ist ein Managed-Kubernetes-Dienst auf Scaleway-Infrastruktur. Kosmos nutzt eine verwaltete Control Plane und kann zusätzlich Nodes anderer Anbieter oder eigene Server einbinden.

Die offizielle Shared-Responsibility-Dokumentation grenzt Provider- und Kundenpflichten detailliert ab. Kapsule passt für eine Scaleway-native Plattform; Kosmos adressiert Multi-Cloud- oder externe Node-Pools. Bei verteilten Nodes sind Netzwerk, Latenz, Fehlerdomänen und der eingeschränkte Automatisierungsumfang externer Ressourcen besonders zu prüfen.

Die wichtigsten Auswahlkriterien

1. Verantwortungsgrenze

Der Begriff "Managed" reicht als Auswahlkriterium nicht aus. Dokumentiert werden muss, wer folgende Schichten betreibt:

1. Rechenzentrum, Hardware und Hypervisor,
2. Control Plane und etcd,
3. Worker-Betriebssystem und Node-Lifecycle,
4. CNI, CSI, Ingress und Plattform-Add-ons,
5. GitOps, Registry und Delivery,
6. Workloads, Datenbanken und Daten,
7. Monitoring, Backup, Restore und Incident Response.

2. Standort und Ausfallgrenzen

Eine Region kann aus einer oder mehreren Availability Zones bestehen. Für jeden Dienst muss geprüft werden, ob Control Plane, Worker, Storage, Load Balancer und Backups dieselben oder unterschiedliche Ausfallgrenzen nutzen. Auch Kapazität und Service Levels unterscheiden sich je Region.

3. Netzwerk

Relevante Fragen sind:

• Gibt es private Node-Netze und private Load Balancer?
• Wie werden API, Administrationsdienste und interne Anwendungen erreicht?
• Lassen sich Cloud, Bare Metal und On-Premises verbinden?
• Welche Egress-Kosten und festen Ausgangsadressen entstehen?
• Welche CNI- und Network-Policy-Optionen sind verfügbar?

4. Storage und Datenbanken

CSI-Integration allein beantwortet keine Datenarchitektur. Benötigt werden Informationen zu Performance, Zonenbindung, Snapshots, Verschlüsselung, Replikation und Wiederherstellung. Für zustandsbehaftete Anwendungen kann ein Managed-Database-Dienst sinnvoller sein als eine Datenbank direkt im Cluster.

5. Lifecycle und Automation

Zu prüfen sind unterstützte Kubernetes-Versionen, Upgrade-Fristen, Wartungsfenster, Node-Replacement, Terraform- oder OpenTofu-Unterstützung, Cluster API, GitOps und Auditierbarkeit. Automatisierte Erstellung ist nur ein Teil des Lifecycles; Upgrades und Wiederherstellung sind ebenso wichtig.

6. Vollständige Kosten

In die TCO gehören:

• Control Plane,
• Worker Compute und Reserven,
• Storage und Snapshots,
• Load Balancer und öffentliche IPs,
• ausgehender Traffic,
• Registry, Logging und Monitoring,
• Backups und zweiter Standort,
• Support,
• interner oder externer Betriebsaufwand.

Warum EU-Region nicht automatisch Souveränität bedeutet

Ein Rechenzentrum in Deutschland oder der EU ist ein relevantes Merkmal, aber keine vollständige Souveränitäts- oder DSGVO-Bewertung. Zusätzlich sind zu prüfen:

• Vertragspartner und anwendbares Recht,
• Unterauftragnehmer und Supportstandorte,
• administrative Zugriffsmöglichkeiten,
• Schlüsselverwaltung und Verschlüsselung,
• Telemetrie und externe Plattformabhängigkeiten,
• Datenflüsse der Anwendungen,
• Portabilität von Images, Daten und Infrastructure as Code,
• Lösch- und Exit-Prozesse.

Auch ein europäischer Provider kann technisch falsch konfiguriert werden. Umgekehrt entsteht Datenkontrolle nicht allein durch Self-hosting, wenn Backups, Identitäten oder SaaS-Abhängigkeiten unberücksichtigt bleiben.

Entscheidungsmatrix nach Ausgangslage

WZ-IT erstellt aus den Anforderungen eine Shortlist, prüft die Verantwortungsgrenzen und baut die Plattform anschließend auf dem gewählten Modell. Neben europäischen Providern werden bei bestehenden Cloud-Landschaften auch EKS, AKS und GKE berücksichtigt.

Quellen

• Hetzner Cloud Controller Manager
• OVHcloud Managed Kubernetes Service
• IONOS Cloud Managed Kubernetes
• STACKIT Kubernetes Engine
• Open Telekom Cloud Service Description
• Scaleway: Kapsule und Kosmos
• Scaleway Shared Responsibility Model