OpenShift ist kein Gegenmodell zu Kubernetes, sondern eine Kubernetes-Distribution von Red Hat: Kubernetes im Kern, dazu ein eigenes Betriebssystem für die Nodes, eine Weboberfläche, strengere Sicherheitsvorgaben ab Werk, eine eingebaute Image-Registry, zusätzliche Objekttypen und kommerzieller Support mit festen Lebenszyklen. Kubernetes allein ist der offene Kern, um den du diese Teile selbst zusammenstellst. Die Entscheidung lautet also nicht „OpenShift oder Kubernetes“, sondern: Kaufst du eine fertig integrierte Plattform mit Herstellerverantwortung, oder baust und pflegst du die Plattform um Kubernetes selbst?
Ich betreibe selbst Standard-Kubernetes mit k3s, kein OpenShift, und habe das Kubernetes-Praxisbuch bei Rheinwerk geschrieben (2024). Diesen Vergleich stütze ich deshalb auf die Dokumentation von Red Hat und des Community-Projekts OKD, nicht auf eigenen OpenShift-Betrieb. Alle meine Beiträge zu Kubernetes findest du gesammelt auf der Seite Kubernetes.
Was OpenShift zu Kubernetes hinzufügt
Red Hat beschreibt OpenShift als Plattform, die von Kubernetes als Orchestrierung angetrieben wird, und listet, was darüber hinaus dazugehört. Die Unterschiede, die im Alltag am meisten spüren:
Wichtig für den Alltag: Weil OpenShift eine zertifizierte Kubernetes-Distribution ist, laufen normale Kubernetes-Manifeste und kubectl dort ebenfalls. Die OKD-Dokumentation sagt es so: OKD-spezifische Objekte wie Route oder BuildConfig „bauen auf Standard-Kubernetes-Grundbausteinen auf“. Wer sie nutzt, bindet sich allerdings an OpenShift.
Der größte Unterschied im Alltag: Sicherheit ab Werk
Ein Unterschied, den du beim Wechsel auf OpenShift sofort merkst, sind die Security Context Constraints (SCC). Sie legen fest, mit welchen Rechten ein Pod laufen darf. In der Standardeinstellung bekommt ein Pod eine Benutzer-ID aus einem Bereich, den OpenShift dem Namespace zuweist, statt der ID, die im Image steht. Ein Image, das darauf angewiesen ist, als root oder als bestimmter Benutzer zu laufen, startet dann nicht oder kann nicht in seine Verzeichnisse schreiben. Laut aktueller OKD-Dokumentation ist für neue Installationen restricted-v3 die strengste mitgelieferte SCC und der Standard für angemeldete Nutzer.
Das ist kein Mangel, sondern Absicht: OpenShift zwingt dich zu Images, die ohne Root-Rechte laufen. In Standard-Kubernetes erreichst du Ähnliches mit den Pod Security Standards, musst sie aber selbst festlegen, je Namespace oder clusterweit. Wie das geht, zeige ich in Pod Security Standards in Kubernetes.
Routes, Ingress und Gateway API
OpenShift hat mit der Route ein eigenes Objekt, um Anwendungen nach außen zu veröffentlichen, umgesetzt von einem HAProxy-basierten Router. Normale Ingress-Objekte versteht OpenShift ebenfalls und erzeugt daraus Routes. Die aktuelle OKD-Dokumentation beschreibt außerdem, wie du die Gateway API aktivierst, den Nachfolger des Ingress. Wenn du Portabilität willst, schreibst du Ingress- oder Gateway-API-Objekte statt Routes. Den Unterschied zwischen Ingress und Gateway API erkläre ich in Kubernetes Gateway API: Ingress-Nachfolger.
OpenShift-Varianten und OKD
OpenShift gibt es selbst betrieben und als Managed-Service. Red Hat nennt für den Selbstbetrieb drei Stufen: OpenShift Kubernetes Engine („Basisfunktionen von Enterprise-Kubernetes“), OpenShift Container Platform (mit Betriebs- und Entwicklerwerkzeugen) und OpenShift Platform Plus, die zusätzlich unter anderem Advanced Cluster Management, Advanced Cluster Security, OpenShift Data Foundation Essentials und Quay enthält. Daneben gibt es OpenShift Virtualization Engine nur für virtuelle Maschinen. Als Managed-Service läuft OpenShift unter anderem bei AWS (ROSA), Microsoft Azure (Azure Red Hat OpenShift), als OpenShift Dedicated und auf IBM Cloud.
OKD ist die Community-Distribution von OpenShift, technisch eng verwandt, ohne Red-Hat-Subscription und ohne Herstellersupport. Die OKD-Website beschreibt es selbst als „sehr meinungsstarke Bereitstellung von Kubernetes“. Die aktuelle OKD-Version 5.0 (Stand Oktober 2026) bringt laut ihren Release-Daten Kubernetes 1.36 mit, während das Kubernetes-Projekt bereits bei 1.37 ist. Das ist typisch: Eine integrierte Plattform folgt dem Upstream mit etwas Abstand, weil jede Version zusammen mit allen Komponenten getestet wird.
Was OpenShift kostet
Red Hat veröffentlicht für die selbst betriebenen Varianten keine festen Listenpreise. Auf der Preisseite steht, dass der Preis von Größe und Subscription abhängt, und für Details wird auf den Vertrieb verwiesen. Ehrlich gerechnet stehen sich zwei Kostenblöcke gegenüber: bei OpenShift die Subscription, bei Standard-Kubernetes die Arbeitszeit für Integration, Updates und Sicherheitsvorgaben, die dein Team selbst leistet. Wie sich die Kosten eines Clusters zusammensetzen, rechne ich in Kubernetes Kosten: was ein Cluster kostet durch.
Ein Punkt, der in Preisvergleichen oft fehlt, sind die Lebenszyklen. Red Hat gibt für jede OpenShift-Version eine Wartung bis 18 Monate nach Erscheinen an, für Versionen mit gerader Nummer mit Extended Update Support bis zu 24, 36 oder 48 Monate, je nach Subscription teils enthalten, teils als Zusatz. Upstream-Kubernetes bekommt je Version etwa ein Jahr lang Patches. Wer selten aktualisieren kann oder will, kauft mit OpenShift also auch Zeit.
Wann OpenShift passt und wann Kubernetes
OpenShift passt eher, wenn
- dein Unternehmen ohnehin auf Red Hat setzt, etwa mit Red Hat Enterprise Linux und bestehenden Support-Verträgen,
- Regulierung oder Einkauf einen Hersteller mit Supportvertrag und festen Lebenszyklen verlangen,
- mehrere Teams eine einheitliche Plattform mit Weboberfläche und Sicherheitsvorgaben ab Werk brauchen, und
- kein eigenes Plattform-Team die Integration von Monitoring, Registry, Policies und Updates übernehmen soll.
Standard-Kubernetes passt eher, wenn
- du ein kleines Team bist und die Subscription im Verhältnis zur Clustergröße schwer wiegt,
- du Wissen im Team hast oder aufbauen willst und die Werkzeuge selbst wählen möchtest,
- du einen Managed-Kubernetes-Dienst eines Cloud-Anbieters nutzen willst, oder
- du einen schlanken Cluster brauchst, etwa mit k3s auf gemieteten Servern, wie ich ihn in Kubernetes auf Hetzner: k3s in Produktion beschreibe.
Für die meisten kleinen Teams und Selbstständigen, für die ich schreibe, ist OpenShift überdimensioniert. Für ein größeres Unternehmen mit Red-Hat-Landschaft und Compliance-Anforderungen kann es genau die richtige Wahl sein. Welche Betriebsmodelle es grundsätzlich gibt, ordne ich in Kubernetes on-premise oder Cloud? ein.
Häufige Fragen
Ist OpenShift Kubernetes?
Ja. OpenShift ist eine zertifizierte Kubernetes-Distribution mit zusätzlichen Komponenten. Kubernetes-Manifeste und kubectl funktionieren dort, OpenShift-eigene Objekte wie Route oder BuildConfig dagegen nicht in anderen Distributionen.
Was ist OKD?
OKD ist die Community-Distribution von OpenShift, technisch eng verwandt. Sie ist ohne Subscription nutzbar, aber ohne Support von Red Hat. Die aktuelle Version 5.0 basiert auf Kubernetes 1.36.
Gibt es OpenShift kostenlos?
OKD ist kostenlos. Für OpenShift selbst bietet Red Hat Testzugänge an, der Betrieb in Produktion läuft über eine Subscription, deren Preis von Größe und Variante abhängt. Feste Listenpreise für den Selbstbetrieb veröffentlicht Red Hat nicht.
Kann ich von Kubernetes auf OpenShift wechseln und zurück?
Anwendungen, die nur Standard-Kubernetes-Objekte nutzen, laufen grundsätzlich auf beiden. Hürden sind meist Images, die Root-Rechte erwarten, und auf OpenShift-Seite eigene Objekte wie Routes oder BuildConfigs. Wer Portabilität will, bleibt bei Standard-Objekten und Images, die ohne Root laufen.
Ist OpenShift sicherer als Kubernetes?
Ab Werk strenger eingestellt, ja: Pods laufen standardmäßig mit eingeschränkten Rechten. Ein gut eingerichteter Kubernetes-Cluster mit Pod Security Standards, RBAC und Network Policies erreicht ein vergleichbares Niveau, muss aber bewusst so aufgesetzt werden.
Wie du weitermachst
Wenn du dich für Standard-Kubernetes entscheidest, sind die Sicherheitsgrundlagen der nächste Schritt: Pod Security Standards in Kubernetes und Kubernetes RBAC: Rollen und Rechte. Wenn du noch beim Betriebsmodell bist, lies Kubernetes im Mittelstand: Betriebsmodell.
Wenn du die Entscheidung für dein Unternehmen durchsprechen willst, findest du auf meiner Seite Kubernetes-Experte: Beratung und Betrieb, wie ich dabei helfe.
Die Grundlagen, auf denen beide Plattformen aufbauen, erkläre ich in meinem Kubernetes-Praxisbuch bei Rheinwerk. Red Hats eigene Einordnung findest du im Beitrag Red Hat OpenShift vs. Kubernetes, das Community-Projekt unter okd.io.
