Was ist OpenShift?
OpenShift ist die Enterprise-Kubernetes-Plattform von Red Hat. Kubernetes steckt darin, und darum herum hat Red Hat zusammengestellt, was eine produktive Plattform braucht und Kubernetes bewusst weglässt: Entwicklerwerkzeuge, CI/CD-Pipelines, Service Mesh, Serverless, Monitoring, eine integrierte Registry und ein Operator-Ökosystem für Software auf der Plattform.
In einem Satz: Wenn Kubernetes ein Kernel ist, dann ist OpenShift eine Distribution darum herum, verkauft mit Supportvertrag. Warum diese Lücke überhaupt besteht, steht im Kubernetes-Erklärtext.
Was Red Hat tatsächlich beisteuert
Reines Kubernetes liefert einen Cluster und sonst nichts. Alles, was eine Plattform ausmacht, wählst, installierst, integrierst, härtest und aktualisierst du selbst, jedes Teil mit eigenem Release-Zyklus und eigener Kompatibilitätsmatrix.
OpenShift bringt diese Entscheidungen getroffen und integriert mit:
- Build- und Deploy-Werkzeuge, damit aus Quellcode ein laufender Container wird, ohne vorher eine Pipeline zu bauen.
- Integrierte Registry, Monitoring und Logging statt drei weiterer Projekte im Eigenbetrieb.
- Strengere Voreinstellungen. Container laufen nicht als root, solange du es nicht erlaubst. Das fällt Teams beim Wechsel von reinem Kubernetes auf, und zwar deshalb, weil ihre Images etwas taten, was sie nicht tun sollten.
- Operatoren, um Software auf dem Cluster unterstützt zu installieren und zu betreiben.
- Einen Supportvertrag, der für viele Käufer das eigentliche Produkt ist.
Die Editionen, eine echte Entscheidung
OpenShift Kubernetes Engine ist die schlankere, auf Open Source ausgerichtete Edition: die Plattform und der Kern, ohne die volle Entwicklerwerkzeug-Schicht.
OpenShift Container Platform ist der komplette Funktionsumfang.
Kommerziell ist der Unterschied erheblich: Ein Team, das unterstütztes Enterprise-Kubernetes will und seine CI/CD bereits hat, kauft sonst Funktionen, die es nicht nutzt. Welche Edition passt, gehört deshalb an den Anfang des Gesprächs, denn der Preisunterschied ist nicht klein.
Selbst bauen oder kaufen
Ohne das Marketing betrachtet ist das eine Make-or-Buy-Entscheidung über denselben Satz Komponenten.
Selbst bauen heisst: Ingress, Monitoring, Logging, Registry, CI und den Rest selbst auswählen, installieren, integrieren, härten und aktualisieren, auf einem Cluster, den du ebenfalls betreibst. Das sind Monate, bevor irgendetwas produktiv ist, und danach bleibt es: Jede dieser Komponenten hat einen eigenen Release-Zyklus, eine eigene Kompatibilitätsmatrix und eigene Sicherheitsmeldungen, dauerhaft.
Kaufen heisst: derselbe Satz kommt zusammengestellt, aufeinander getestet und unterstützt, und die laufende Integrationsarbeit macht jemand anderes.
Entscheidend ist, dass beide Kosten unterschiedlich skalieren. Selbst bauen ist im Wesentlichen ein fixer Aufwand an Engineering-Zeit, und der wird nicht kleiner, weil dein Cluster klein ist. Kaufen wird gemessen: OpenShift kostet pro Worker-vCPU, die Rechnung wächst also mit dem Cluster.
Daraus folgt das, was meist falsch herum angenommen wird. Unterhalb der Grössenordnung, in der du Kerne in Zehntausenden zählst, ist Kaufen in der Regel die günstigere Antwort, weil der fixe Aufwand des Selbstbauens einen kleinen Cluster genauso trifft wie einen grossen. Die Grösse, ab der sich Selbstbauen rechnet, ist erheblich, und die meisten Organisationen, die sich diese Frage stellen, sind weit davon entfernt. Darüber beginnt der Preis pro Kern zu dominieren, und die Rechnung kann kippen.
Der ehrliche Test lautet also nicht «sind wir ein Enterprise». Er lautet: wie viele Worker-Kerne, und was würde die Engineering-Zeit kosten, dasselbe zu bauen und dauerhaft am Laufen zu halten.
Wann OpenShift die richtige Antwort ist
- Wenn ein Supportvertrag Vorgabe ist. Regulierte Organisationen dürfen kritische Infrastruktur oft nicht ohne Hersteller im Rücken betreiben. Das ist der häufigste ehrliche Grund und trägt für sich allein.
- Wenn die Plattformentscheidungen getroffen sein sollen. Ingress, Monitoring, Logging, Registry und CI auf reinem Kubernetes zusammenzusetzen dauert Monate und bleibt danach eine Dauerpflicht. Das fertig zu kaufen ist ein legitimer Handel.
- Sicherheitsniveau ab Werk. Die strengeren Voreinstellungen sind genau das, was sich auf reinem Kubernetes leicht konfigurieren und ebenso leicht vergessen lässt.
- Grosse Organisationen mit vielen Teams, wo Mandantentrennung und Governance den Aufwand rechtfertigen.
Wann reines Kubernetes genügt
Ein fähiges Plattformteam, das diese Entscheidungen bereits getroffen hat, empfindet OpenShifts Vorgaben eher als Einschränkung. Eine funktionierende Plattform dorthin zu migrieren, um Funktionen zu erhalten, die du schon gebaut hast, ist teuer.
Kleine Installationen. OpenShift hat einen Ressourcen-Grundbedarf. Ein Cluster mit wenigen Diensten zahlt spürbar für die Plattformkomponenten selbst.
Kostensensible Workloads ohne Supportbedarf. Die Lizenz ist der Kern des Produkts; wer den Support nicht nutzt, bezahlt ihn trotzdem.
Wenn du genau das abwägst, geht unser Vergleich OpenShift gegen Kubernetes die Editionen und die Preisstruktur im Detail durch.
Was der Betrieb verlangt
Alles, was für Kubernetes gilt, gilt weiterhin. OpenShift ändert, wer manches davon tut, nicht ob es getan wird.
- Upgrades sind unterstützt und bleiben deine Aufgabe. Red Hat liefert Pfad und Werkzeuge. Planen, testen und dabei sein muss trotzdem jemand.
- Nodes und Betriebssystem darunter bleiben Infrastruktur mit Lebenszyklus.
- Kapazität und Quotas. Die Plattformkomponenten verbrauchen echte Ressourcen; das gehört in die Dimensionierung und nicht in die Nachbetrachtung.
- Ein Supportvertrag ist kein Betriebsteam. Er beantwortet Fragen zum Produkt. Er schaut nachts um drei nicht auf deinen Cluster.
Der letzte Punkt wird beim Kauf am häufigsten missverstanden, und genau diese Lücke füllt ein Managed Service.
Wo VSHN hineinpasst
VSHN ist Red Hat Premier CCSP Partner in der Schweiz und betreibt OpenShift seit 2016, auf Cloudscale, Exoscale, Private Cloud und On-Premises-Infrastruktur, ab CHF 44 pro vCPU mit bis zu 99.99% SLA.
Das erste nützliche Gespräch dreht sich meist darum, welche Edition passt und ob OpenShift überhaupt die richtige Form ist, denn für manche Teams lautet die ehrliche Antwort: reines Kubernetes und eine kleinere Rechnung.