So bewerten Sie einen Managed-Kubernetes-Anbieter in Europa

September 2026 • Comparison

Eine Preisseite für Managed Kubernetes sagt Ihnen nicht, was nachts passiert, wenn etwas schiefgeht. Diese Checkliste behandelt die Fragen, die das entscheiden, und zeigt zu jeder, was mehrere europäische Anbieter tatsächlich veröffentlichen. Jede Anbieteraussage stammt aus der eigenen Dokumentation oder Preisseite des Anbieters, gelesen im September 2026, und ist im Abschnitt „Quellen“ verlinkt.

1. Fragen Sie, was tatsächlich verwaltet wird

Anbieter ziehen die Grenze zwischen ihrer Aufgabe und Ihrer an unterschiedlichen Stellen. Das Service-Level-Agreement von Exoscale SKS ist eindeutig: Es deckt nur die Verfügbarkeit des Control Plane ab, nicht Worker-Nodes, Pods, Volumes, Anwendungen oder Daten. Der Kunde bleibt verantwortlich für Workloads, die Zugriffskontrolle des Clusters, persistente Daten, Backups, die Planung der Disaster Recovery und Wiederherstellungsverfahren.

Andere Anbieter beschreiben mehr Automatisierung. IONOS sagt, sein Managed Service übernehme Updates und Sicherheitskorrekturen automatisch und Sie wählen, wann sie laufen. Infomaniak sagt, Sie könnten das Control Plane und die Worker-Nodes jederzeit aktualisieren, und es verwalte alle Kubernetes-Komponenten. Wie auch immer die Formulierung lautet, holen Sie schriftliche Antworten auf diese Fragen ein:

• Wer aktualisiert das Control Plane, wer die Worker-Nodes, und wer entscheidet über den Zeitpunkt?
• Wer patcht das Betriebssystem der Worker-Nodes?
• Wem gehören die Backups des Cluster-Zustands und Ihrer persistenten Volumes?
• Welche Add-ons (Netzwerk, Ingress, Metriken) werden bereitgestellt, und wer hält sie aktuell?

2. Prüfen Sie, welche Control-Plane-Stufe Sie tatsächlich kaufen

Ein kostenloses Control Plane ist nicht dasselbe Produkt wie ein kostenpflichtiges. Die untenstehenden kostenlosen Stufen sind geteilt und haben kein SLA, während die kostenpflichtigen Stufen Replikate, einen dedizierten Datastore und ein schriftliches Verfügbarkeitsziel hinzufügen.

Das ist wichtig wegen der Art, wie Kubernetes selbst gebaut ist. Wie unser Artikel zu Managed vs. Self-Hosted Kubernetes erklärt, empfiehlt die Kubernetes-Dokumentation für die Produktion etcd-Cluster mit mehreren Mitgliedern, und etcd braucht eine Mehrheit seiner Mitglieder, um Änderungen vorzunehmen. Ein einzelnes API-Replikat auf einem geteilten Datastore ist eine vernünftige Wahl für die Entwicklung und eine schwache für die Produktion.

3. Lesen Sie, was das SLA abdeckt

Zwei Anbieter können beide eine Prozentzahl bewerben und damit sehr Unterschiedliches meinen. Fragen Sie, was gemessen wird (Verfügbarkeit der Control-Plane-API, Verfügbarkeit der Nodes oder beides), über welchen Zeitraum, was ausgeschlossen ist und was Sie erhalten, wenn das Ziel verfehlt wird. Exoscale zum Beispiel schreibt 50 % der monatlichen Gebühren für betroffene Ressourcen gut, wenn die Verfügbarkeit zwischen 99,95 % und 98,3 % liegt, und 100 % darunter. Es schließt außerdem Ausfälle bei Nodes, Volumes und Pods aus, weil sein SLA für das Control Plane gilt.

Es hilft auch, die Prozentzahl in Zeit zu übersetzen. In einem Monat mit 30 Tagen:

Scaleway nennt 99,5 % für seine dedizierten Kapsule-Control-Planes, Infomaniak nennt 99,9 % für seine dedizierten Stufen, und Exoscale nennt mindestens 99,95 % für seinen Pro-Tarif. Diese Zahlen sind nur vergleichbar, wenn die Definitionen übereinstimmen – lesen Sie also die Definitionen, bevor Sie die Zahlen vergleichen.

4. Fragen Sie, ob die vCPU dediziert ist

Geteilte vCPUs werden auf physischen Kernen eingeplant, die mehrere virtuelle Maschinen gleichzeitig nutzen. Die Dokumentation von Scaleway beschreibt die Folge unverblümt: Bei Spitzenlast durch benachbarte Workloads können Ihre Workloads durch CPU-Konkurrenz langsamer werden, bekannt als CPU Steal. Dedizierte vCPUs bieten exklusiven Zugriff auf physische Kerne und gleichbleibende Leistung. Die eigene Empfehlung von Scaleway zählt Worker-Nodes in Kubernetes-Clustern zu den typischen Einsatzfällen geteilter Instanzen, was eine faire Wahl für die Entwicklung und ein echter Kompromiss für die Produktion ist.

IONOS lässt Sie für die Worker-Nodes seines Managed Kubernetes zwischen dedizierten Kernen und vCPUs wählen. Viele Anbieter geben nicht an, was Sie bei einem bestimmten Tarif bekommen. Wenn die Dokumentation schweigt, fragen Sie schriftlich nach, denn es verändert sowohl die Leistung als auch den Preis, den Sie erwarten sollten.

5. Prüfen Sie die Speicherreplikation und wo die Kopien liegen

Persistente Volumes sind der Ort, an dem ein Kubernetes-Cluster die Daten hält, die Sie nicht neu aufbauen können – fragen Sie also, wie sie geschützt sind:

• Blockspeicher von Exoscale hält zwei Kopien der Daten auf getrennten Servern, innerhalb derselben Zone repliziert, mit 5.000 IOPS pro Volume.
• Blockspeicher von Scaleway (NVMe-Volumes) wird dreifach repliziert, mit einem SLA von 99,99 %, und die FAQ merkt an, dass die IOPS bei Spitzenlast schwanken können.
• Blockspeicher von Infomaniak läuft auf einem verschlüsselten Ceph-Cluster mit drei Replikaten auf NVMe und gibt bis zu 4.000 garantierte IOPS an.
• Hikube gibt an, Daten synchron über drei Schweizer Rechenzentren zu replizieren.

Replikation schützt vor dem Verlust einer Platte oder eines Servers. Sie ist kein Backup, denn eine versehentliche Löschung wird mitrepliziert, und Kopien innerhalb einer Zone oder eines Standorts schützen nicht davor, diese Zone oder diesen Standort zu verlieren. Fragen Sie, wo jede Kopie liegt, und planen Sie ein separates Offsite-Backup für alles, was Sie sich nicht leisten können zu verlieren.

6. Lesen Sie die Support-Bedingungen, nicht die Schlagzeile

„Support rund um die Uhr“ kann sehr unterschiedliche Dinge bedeuten. Die Tabelle zeigt, was jeder Anbieter nach eigener Aussage ohne Aufpreis enthält und was die schnellere oder rund um die Uhr verfügbare Betreuung kostet.

Beachten Sie, was diese Zahlen sind. Es sind Ziele für die erste Reaktion, nicht für die Lösung. OVHcloud sagt das selbst: Die Bearbeitungszeit endet, wenn das Team mit der Bearbeitung des Tickets beginnt, nicht wenn der Vorfall gelöst ist, und es gibt keine Garantie, die Ziele zu erreichen. Wenn Sie Anbieter vergleichen, fragen Sie nach dem Lösungsziel, dem Eskalationsweg, den Kanälen und den Sprachen, und prüfen Sie, ob der Support als Prozentsatz Ihrer Ausgaben berechnet wird.

7. Achten Sie auf Traffic-Gebühren und versteckte Posten

Der Monatspreis eines Nodes ist selten die ganze Rechnung. Fragen Sie nach ausgehendem Traffic, öffentlichen IPv4-Adressen, Load Balancern, Snapshots, Objektspeicher-Anfragen und Support-Gebühren. Infomaniak gibt an, dass Bandbreite kostenlos ist, außer beim Objektspeicher oberhalb von 10 TB verbrauchter Bandbreite, und UpCloud gibt an, keine Kosten für ausgehenden Traffic zu haben. Mehrere Anbieter berechnen ihre schnelleren Support-Stufen als Prozentsatz Ihrer monatlichen Ausgaben, wie die obige Tabelle zeigt, sodass dieser Posten mit Ihrer Nutzung wächst.

8. Fragen Sie, wo die Daten liegen – einschließlich Backups und Protokollen

Der Datenstandort umfasst mehr als die primäre Datenbank. Fragen Sie, wo Backups, Protokolle und Monitoring-Daten gespeichert werden, welche Gesellschaft die Infrastruktur betreibt und welches Landesrecht für diese Gesellschaft gilt. Hikube liefert ein Beispiel für eine konkrete Antwort: Es gibt an, dass keine Daten über ausländische Server laufen, einschließlich Backups, Protokollen und Monitoring-Metriken, und dass Bescheinigungen zur Datenresidenz für Auditoren auf Anfrage verfügbar sind. Verlangen Sie von jedem Anbieter dieselbe Detailtiefe schriftlich.

9. Prüfen Sie den Ausstieg, bevor Sie einsteigen

Kubernetes selbst ist portabel, die Bindung entsteht also durch alles, was darum herum liegt. Fragen Sie, ob der Cluster Standard-Upstream-Kubernetes mit einer normalen kubeconfig ist, ob Terraform, Helm und GitOps-Tools damit funktionieren, wie Sie Ihre Daten und Volumes exportieren und wie lange Ressourcen nach der Kündigung aufbewahrt werden. Ein Anbieter, der das klar beantwortet, ist einer, den Sie verlassen können – und gerade das macht es leichter, ihm zu vertrauen, solange Sie bleiben.

10. Führen Sie vor der Verpflichtung einen zweiwöchigen Test durch

Bitten Sie um eine Testphase oder einen Tarif mit geringer Bindung und testen Sie die Dinge, auf die es ankommt – nicht die Konsolen-Demo:

• Zeit bis zum ersten Cluster. Erstellen Sie einen Cluster und messen Sie die Zeit.
• Stateful-Daten. Stellen Sie eine Anwendung mit einem persistenten Volume bereit, löschen Sie den Pod und bestätigen Sie, dass die Daten erhalten bleiben.
• Ein Upgrade. Upgraden Sie den Cluster um eine Minor-Version und notieren Sie, was Sie selbst tun mussten.
• Eine Wiederherstellung. Stellen Sie aus einem Backup oder Snapshot in einen neuen Cluster wieder her. Ein Backup, aus dem Sie nicht wiederhergestellt haben, ist eine Annahme.
• Support. Eröffnen Sie nachts ein Ticket, stufen Sie es als dringend ein und erfassen Sie sowohl die Zeit bis zur ersten Reaktion als auch die Zeit bis zur Lösung.
• Leistung unter Last. Führen Sie einen CPU-lastigen Job auf einem Worker-Node aus, prüfen Sie auf CPU Steal und testen Sie den Datenträger mit einem fsync-intensiven Benchmark.

Zwei Befehle decken den letzten Punkt ab. Auf einem Worker-Node gibt vmstat 1 10 eine Spalte st für die Steal-Zeit aus; dauerhaft von null verschiedene Werte, während Ihr Job läuft, bedeuten, dass andere Mandanten Ihre CPU wegnehmen. Bei Datenträgern erklärt die etcd-Performance-Dokumentation, dass die Anfragelatenz durch die Netzwerk-Umlaufzeit plus die Zeit begrenzt wird, die fdatasync braucht, um Daten in den permanenten Speicher zu schreiben, und nennt als typische fdatasync-Latenz etwa 10 ms bei einer rotierenden Platte und oft unter 1 ms bei einer SSD. Ein gängiger Weg, sie zu messen, ist fio mit synchronen Schreibvorgängen und fdatasync:

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

Der Bericht enthält Perzentile der fdatasync-Latenz. Die etcd-Empfehlung von Red Hat betrachtet eine fsync-Latenz im 99. Perzentil unter 10 ms als Maßstab für einen Datenträger, der etcd hosten kann – nutzen Sie das daher als Referenzpunkt beim Vergleich von Anbietern.

Wo Kube-DC steht

So beantwortet Cloud Acropolis Kube-DC dieselben Fragen. Wir führen auf, was dokumentiert ist und was nicht, damit Sie es an Ihrer eigenen Checkliste prüfen können.

Quellen (gelesen im 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

Weiterführende Lektüre

• Managed vs. Self-Hosted Kubernetes: Die technische Realität

Testen Sie Kube-DC anhand der Checkliste

Jeder der obigen Punkte lässt sich an einem Kube-DC-Paket testen: dedizierte vCPU, Ceph-basierter NVMe-Speicher, eine dedizierte öffentliche IPv4, S3-kompatibler Objektspeicher, Ihre eigenen vom Mandanten administrierten Kubernetes-Cluster und 24/7-Support mit einem Lösungsziel von 4 Stunden. Bestellen Sie in einem Self-Service-Portal, führen Sie den zweiwöchigen Test durch und beurteilen Sie uns an den Ergebnissen.