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
| Do-it-yourself | CSP gemanagte Control Plane | VSHN Managed Kubernetes | Enterprise OpenShift | |
|---|---|---|---|---|
| Beispiele | kubeadm, Cluster API, eigener Stack | Exoscale SKS, STACKIT, IONOS, OVHcloud | Dieser Dienst | Managed OpenShift |
| Wer betreibt den Cluster | Dein Team | Du (nur Control Plane gemanagt) | VSHN | VSHN |
| Versions-Upgrades | Du | Du | VSHN | VSHN |
| OS-Lebenszyklus | Du | Du | VSHN (immutable Talos) | VSHN |
| Ingress, Storage, Networking | Du wählst und betreibst | Du wählst und betreibst | Standardisiert und betrieben | Standardisiert und betrieben |
| Service-Zeiten | Eigene | Anbieterabhängig | Geschäftszeiten, reaktiv | Durchgehender Betrieb |
| Souveränität | Hosting-abhängig | Oft Hyperscaler-gestützt | Souverän Schweiz (cloudscale.ch) | Schweizer Optionen verfügbar |
| Am besten für | Grosse Plattform-Teams | Teams, die den Rest gern betreiben | Teams, die die Plattform betrieben haben wollen, ohne Enterprise-Umfang | Regulierte Enterprise-Workloads |
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. Das ist echt nützlich, aber der Name verspricht zu viel. Node-Lebenszyklus, Versions-Upgrades, Ingress, Storage, Observability und Add-on-Kompatibilität bleiben deine Aufgabe. Eine gemanagte Control Plane ist keine gemanagte Plattform.
Eine CSP-Control-Plane ist sinnvoll, wenn: Du die Control Plane abgeben willst, dein Team aber bereit ist, alles darüber zu betreiben.
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. 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.