Wo Managed Kubernetes hingehört

Teams, die Kubernetes in der Schweiz betreiben, wählen zwischen vier Marktschichten. Jede trifft einen anderen Kompromiss zwischen Kontrolle, Betriebsaufwand und Kosten. Diese Seite ordnet diese Schichten ein, damit du siehst, wo VSHN Managed Kubernetes steht, und warum wir es für die Lücke in der Mitte gebaut haben.

Die vier Schichten

Interesse anmelden

Do-it-yourself Kubernetes

Selbstbetriebenes Kubernetes gibt dir volle Kontrolle: du wählst jede Komponente, bestimmst deinen eigenen Upgrade-Takt und läufst auf beliebiger Infrastruktur. Diese Kontrolle ist zugleich der Preis. Kubernetes in Produktion zu betreiben bedeutet, den Node-Lebenszyklus zu verantworten, Versions-Upgrades alle paar Monate, CNI- und Ingress-Entscheidungen, Storage-Betrieb, Security-Patching und die On-Call-Rotation dahinter.

DIY ist sinnvoll, wenn: Du ein reifes Plattform-Team hast, das Kubernetes-Betrieb als Kernkompetenz behandelt, und du Kontrolle über jede Schicht brauchst.

CSP gemanagte Control Planes

Gemanagte Kubernetes-Engines von Cloud-Anbietern (Exoscale SKS, STACKIT, IONOS, OVHcloud und ähnliche) betreiben API-Server und etcd für dich. Beim Node-Patching sind einige davon weiter, als der Ruf vermuten lässt: STACKIT und IONOS patchen Kubernetes- und OS-Versionen auf Worker-Nodes inzwischen ohne manuellen Trigger, und bei OVHcloud lässt sich ein Security-Patch oder ein Versions-Upgrade mit einem Klick oder über die API auslösen. Exoscales eigene SKS-Dokumentation beschreibt dagegen einen Lebenszyklus, den du selbst über API oder CLI verwaltest, ohne dokumentierte automatische Patch-Funktion.

Ein automatischer Patch macht aus einem Cluster noch keine Plattform. STACKITs eigener Wartungshinweis zu den Flatcar-OS-Images bittet Kunden ausdrücklich, ihre Workloads vor dem automatischen Upgrade selbst zu testen. Das ist bei VSHN Managed Kubernetes nicht anders: Die Kompatibilität deiner Applikationen bleibt bei dir, ausser du nimmst Application Operations dazu. Der Unterschied liegt in allem zwischen Node und Applikation. Keiner der vier bündelt Ingress, Storage oder Observability in die Control Plane. Exoscale dokumentiert Ingress und Load Balancing als Aufgabe, die du selbst konfigurierst; STACKIT verschickt Metriken, Logs und Traces an ein separates Observability-Produkt, das du selbst betreibst; IONOS verkauft Monitoring als separaten, optionalen Dienst; und OVHclouds eigene Verantwortungsmatrix hält fest, dass die Sicherheit der Worker-Nodes, Container und Pods sowie deren Dimensionierung und Backup beim Kunden bleiben.

Eine CSP-Control-Plane ist sinnvoll, wenn: Du die Control Plane abgeben willst und bereit bist, alles darüber selbst zu betreiben: Ingress, Storage, Netzwerk und Observability, und sie mit jedem automatischen Patch kompatibel zu halten.

VSHN Managed Kubernetes (die fehlende Mitte)

Dieser Dienst übernimmt den gesamten Plattform-Lebenszyklus auf einem klar definierten, standardisierten Stack: Talos als immutables OS, Cilium für Networking, die Gateway API für Ingress, Rook / Ceph für Storage, alles über Cluster API gesteuert. VSHN führt Versions-Upgrades, OS-Updates und die zentralen Komponenten nach definiertem Wartungsplan aus, und zwar als ein Paket, das VSHN auf eigenen Clustern gemeinsam geprüft hat, bevor es deinen erreicht. Du erhältst Kubernetes als erstklassige Schnittstelle mit abgenommener Betriebslast, ohne für Enterprise-Umfang zu zahlen, den du nicht brauchst.

Es ist bewusst abgegrenzt: standardisierte Konfigurationen, Betrieb während der Geschäftszeiten und eine klare Verantwortungslinie. Das hält es einfacher und günstiger als eine Enterprise-Plattform.

VSHN Managed Kubernetes ist sinnvoll, wenn: Du Produktions-Kubernetes betrieben haben willst, Schweizer Souveränität schätzt, und eine Enterprise-Plattform wie OpenShift mehr ist, als deine Workloads brauchen.

Enterprise OpenShift

Managed OpenShift ist die Enterprise-Option: durchgehender Betrieb, höhere Service-Level, integriertes Entwickler-Tooling und die Compliance-Lage, die regulierte Branchen brauchen. Es ist das richtige Werkzeug, wenn deine Workloads Betrieb rund um die Uhr und Garantien auf reguliertem Niveau verlangen, und mehr als nötig, wenn nicht. Siehe Managed OpenShift.

OpenShift ist sinnvoll, wenn: Du regulierte oder geschäftskritische Workloads betreibst, die durchgehenden Betrieb und einen breiteren Enterprise-Funktionsumfang rechtfertigen.

Du betreibst bereits OpenShift?

Alles bisher Gesagte setzt einen Entscheid voraus, den du noch nicht getroffen hast. Wenn OpenShift bei dir schon läuft, stellt sich die Frage anders: Die Subscriptions sind bezahlt, sie verlängern sich jedes Jahr, und genutzt wird davon womöglich wenig. Teams in dieser Lage beschreiben es meist ähnlich. Routes sind praktisch, BuildConfigs kommen zum Einsatz, und darüber hinaus liegt eine Enterprise-Plattform herum, für die bezahlt wird.

Darauf gibt es zwei ehrliche Antworten, und sie führen an unterschiedliche Orte.

OpenShift behalten, den Betrieb abgeben

Wenn die Plattform passt und der Betrieb das Problem ist, löst ein Plattformwechsel das Falsche. Weder an deinen Clustern noch an den Subscriptions noch an deiner Red-Hat-Beziehung muss sich etwas ändern, damit jemand anderes sie betreibt. Das gibt es heute, und für die meisten Teams in dieser Lage ist es der kürzere Weg. Siehe Managed OpenShift.

Auf Kubernetes wechseln

Wenn du von der Plattform tatsächlich wenig brauchst, lohnt es sich, den Wechsel durchzurechnen. Sei dir dabei im Klaren, was er bedeutet: Es ist ein Neuaufbau, keine Migration. Deine Manifeste ziehen nicht unverändert um, weil das, worauf du dich stützt, zu OpenShift gehört und nicht zu Kubernetes.

Was ersetzt werden muss:

• Routes werden zu Gateway API oder Ingress, samt neu gebautem Umgang mit TLS und Hostnamen
• BuildConfigs und ImageStreams haben keine Entsprechung. Builds wandern in dein CI-System, und das ist meist der grösste einzelne Brocken
• Security Context Constraints werden zu Pod Security Standards. Die beiden lassen sich nicht eins zu eins abbilden, Workload-Berechtigungen werden also neu hergeleitet statt umgerechnet
• Die integrierte Registry wird zu einer externen, die du selbst betreibst oder betreiben lässt
• Operators aus dem OpenShift-Katalog brauchen Upstream-Entsprechungen. Wo es keine gibt, wird die Funktion nachgebaut oder gestrichen
• Web-Konsole und Entwickler-Tooling fallen weg, was deine Entwicklerinnen und Entwickler stärker trifft als dein Plattformteam

Nichts davon ist exotisch, und alles davon ist Arbeit. Die Lizenzersparnis muss das übertreffen, und das tut sie nicht immer.

Bevor du sie so oder so triffst

Zwei Hebel senken eine OpenShift-Rechnung, ohne Plattform oder Anbieter zu wechseln. Beide lohnen sich zuerst, weil sie umkehrbar sind und Wochen statt Quartale brauchen: Right-Sizing gegen den tatsächlichen Verbrauch der Cluster statt gegen die einmal provisionierte Grösse, und Nicht-Produktions-Cluster ausserhalb der Geschäftszeiten auf null herunterfahren. Häufig verschiebt schon der zweite Hebel die Rechnung so weit, dass die Migrationsfrage ihre Dringlichkeit verliert.

Kläre das, bevor du Plattformen vergleichst. Eine Migration, die sich gegen eine unoptimierte Rechnung rechnet, rechnet sich gegen eine Zahl, die du ohnehin hättest ändern können.

Managed Kubernetes ist noch in Entwicklung, wir migrieren also derzeit niemanden von OpenShift weg. Wenn du diesen Entscheid gerade durchdenkst, hol dir eine Zweitmeinung zur Migration. Schildere uns, was du betreibst und was es kostet, und du bekommst unsere Einschätzung, ob sich der Wechsel lohnt, auch dann, wenn sie lautet: bleiben.

Welche Schicht passt zu dir?

Wenn du den Cluster wirklich betrieben haben willst, eine Enterprise-Plattform aber überdimensioniert ist, ist Managed Kubernetes die Schicht, die für diese Lücke gebaut wurde. Melde dein Interesse an und erzähl uns von deinen Clustern. Wir besprechen, ob die Plattform zu deinem Team passt.