Kubernetes vs OpenShift: Lohnt sich die Red-Hat-Plattform 2026?

Robin Werner, Kubernetes-Consultant bei Pexon Consulting | 12 Min. Lesezeit | 29.08.2026

TL;DR

Kubernetes vs OpenShift entscheidet sich 2026 selten an Features, sondern an Lizenzbudget, On-Prem-Pflicht und Support-SLA. Für die meisten Cloud-First-Mittelständler reicht Vanilla-Kubernetes auf AKS oder EKS plus eigene Tooling-Schicht. OpenShift lohnt sich bei KRITIS-On-Prem, strikten 24/7-Verträgen oder bestehender Red-Hat-Landschaft. Pexon Consulting klärt das in einem 1-Wochen-Decision-Sprint zwischen 6 und 10k EUR.

Warum die OpenShift-Frage 2026 teurer geworden ist

Red Hat verkauft OpenShift als „Enterprise-Kubernetes“. Das klingt nach Sicherheit. In der Praxis ist es eine Make-or-Buy-Entscheidung für die gesamte Plattform-Schicht über dem Orchestrator.

Ein typisches Muster im DACH-Mittelstand: Der CIO bekommt ein Angebot über OpenShift Container Platform für 12 Worker-Nodes. Die Subscription allein landet bei grob 96-180k USD/Jahr, je nach Edition und Support-Stufe. Parallel liegt ein Gegenangebot auf dem Tisch: AKS oder EKS, Control-Plane gratis bzw. rund 73 USD/Monat, Tooling aus Argo CD, Cert-Manager und Ingress-NGINX. Beide Lösungen orchestrieren Container. Nur eine davon belässt euch die Wahl der Bausteine.

Wir sehen die Diskussion wöchentlich, besonders wenn Banken, Energieversorger oder Fertiger On-Prem verlangen. Dann ist OpenShift oft die reifere Antwort. Bei Cloud-First-Setups ohne Red-Hat-Fußabdruck ist es häufig Überbau.

Update August 2026: OpenShift Container Platform 4.22 ist seit 9. Juni 2026 die aktuelle GA-Linie. Parallel endete am 25. August 2026 die Maintenance-Phase für OpenShift 4.18. Wer noch auf 4.18 steht, braucht jetzt einen Upgrade-Pfad (EUS oder Sprung auf 4.20/4.22). Upstream Kubernetes liegt bei 1.35.8 bzw. 1.36.4 (Patches vom 20. August 2026); 1.34 ist seit 27. August 2026 im Maintenance-Mode. Das Repo kubernetes/kubernetes hat Stand 29.08.2026 rund 125.567 Stars.

Was OpenShift technisch wirklich ist

OpenShift ist kein Ersatz für Kubernetes. Es ist eine opinionierte Distribution darauf, mit festem Betriebssystem (RHCOS), festem Operator-Modell und fest verdrahteten Defaults für Security und Lifecycle.

Unter der Haube: Kubernetes-API, CRI-O statt containerd als Default-Runtime, Operator Lifecycle Manager, Security Context Constraints (SCC) statt nur Pod Security Admission, integrierte Image-Registry, HAProxy-basierter Router, OpenShift Pipelines (Tekton) und oft OpenShift GitOps (Argo CD). Die Developer-Console ist kein Nice-to-have, sondern Teil des Verkaufsarguments.

Vanilla Kubernetes auf AKS oder EKS liefert euch die Control-Plane und Nodes. Ingress, Registry, CI/CD, Policy und Observability baut ihr selbst. Das ist kein Nachteil, wenn ihr ein Platform-Team habt. Es ist ein Nachteil, wenn drei Leute nebenher „Kubernetes mitbetreiben“ sollen.

Im Alltag merkt ihr den Unterschied an vier Stellen: Routes statt klassischem Ingress, DeploymentConfig ist historisch (heute meist Deployments), Projects statt nackter Namespaces, und SCC-Bindungen, die Images ablehnen, die unter Vanilla-K8s „einfach liefen“. Teams unterschätzen genau diesen Reibungsverlust bei der ersten Migration.

# Vanilla Kubernetes: Pod Security Admission auf Namespace-Ebene
kubectl label namespace production 
  pod-security.kubernetes.io/enforce=restricted 
  --overwrite

# OpenShift: Security Context Constraint prüfen
oc get scc restricted-v2 -o yaml | grep -E 'allowPrivilegeEscalation|runAsUser'
oc adm policy who-can use scc restricted-v2

Der Unterschied ist nicht „sicher vs. unsicher“. Der Unterschied ist: OpenShift erzwingt Defaults. Vanilla-K8s lässt euch Defaults vergessen, bis der Audit kommt.

Unsere klare Empfehlung: Wenn ihr OpenShift nur wegen „Security out of the box“ kauft und gleichzeitig kein On-Prem und kein Red-Hat-Stack habt, prüft zuerst Policy-as-Code auf Vanilla-K8s. Oft reicht das, und ihr spart die Subscription.

Vanilla Kubernetes im Alltag: Stärken und blinde Flecken

Vanilla-Kubernetes gewinnt, wenn Flexibilität und Cloud-Innovation wichtiger sind als ein fertiges Paket. AKS, EKS und GKE liefern euch Control-Plane-HA, Node-Pools und Identity-Hooks. Den Rest komponiert ihr: Argo CD oder Flux, Ingress-NGINX oder Traefik oder Gateway API, Prometheus-Stack, External Secrets, Kyverno oder Gatekeeper.

Das funktioniert gut, wenn mindestens eine Person Platform-Verantwortung trägt und die Tooling-Auswahl dokumentiert ist. Es scheitert, wenn jedes Team seinen eigenen Ingress und seine eigene Registry baut. Dann zahlt ihr OpenShift-Preise in interner Reibung, ohne OpenShift-Support zu bekommen.

Stärken, die in Projekten zählen: null Lizenzkosten für den Orchestrator, freie Tool-Wahl, direkter Zugriff auf Hyperscaler-Features (GPU-Pools, managed Add-ons, Spot/Priority-Nodes), großer Talent-Pool in DACH.

Blinde Flecken: Update-Disziplin liegt bei euch (auch wenn der Provider Control-Plane-Patches liefert), Security-Baseline muss aktiv gepflegt werden, und On-Prem-Self-Hosted ohne Distribution wird schnell zum Eigenbau-Abenteuer. Mehr zur Betriebsmodell-Frage in der Kubernetes-Beratung-Einordnung.

Bevor die TCO-Rechnung Sinn ergibt, lohnt ein Blick auf die Alternativen im selben Segment: SUSE Rancher Prime und die gemanagten OpenShift-Varianten ARO und ROSA folgen jeweils eigenen Lizenzmodellen. Die Unterschiede haben wir auf unserem Vergleichsportal in OpenShift vs Rancher: Lizenz, Betrieb und Lock-in zusammengestellt.

Kosten und TCO: wo die Rechnung kippt

Lizenzkosten sind der sichtbare Teil. Der unsichtbare Teil ist Plattform-Engineering-Zeit.

Red Hat veröffentlicht keine festen List-Preise auf der Website. Marktschätzungen für 2026 liegen bei etwa 1.000-2.500 USD pro 2-Core-Pack und Jahr für OpenShift Container Platform, abhängig von Edition (Container Platform vs. Platform Plus) und Support (Standard vs. Premium). Ein 16-Core-Node landet damit grob bei 8.000-20.000 USD/Jahr nur für die Subscription. Managed-Varianten wie ROSA (AWS) oder ARO (Azure) addieren stündliche Plattform-Gebühren auf die Worker-Nodes.

Dazu kommen in beiden Fällen Compute, Storage und Netzwerk. Der faire Vergleich ist TCO über 36 Monate inklusive 0,5-1,5 FTE für Plattform-Arbeit. OpenShift reduziert den Tooling-Aufwand. Es ersetzt kein Platform-Team komplett.

Bei 3-5 Nodes lohnt sich OpenShift wirtschaftlich fast nie. Die Subscription frisst den Budgetrahmen, bevor der erste Workload produktiv ist. Ab etwa 15-20 Nodes und klarer On-Prem- oder Compliance-Pflicht ändert sich die Rechnung.

Wir raten aktuell davon ab, OpenShift nur als „Premium-AKS“ zu kaufen. Wenn ihr Cloud-First seid und Microsoft oder AWS schon nutzt, ist der günstigere Weg meist Managed Kubernetes plus GitOps. Die Plattform-Lizenz spart ihr. Die Platform-Engineering-Stunden spart ihr nicht.

Ein zweiter Kostenhebel: Managed OpenShift (ROSA, ARO). Die Rechnung wandert von Jahres-Subscription zu vCPU-Stunden. Für Teams ohne On-Prem-Zwang wirkt das flexibler. Es bleibt trotzdem teurer als Vanilla Managed Kubernetes. Rechnet immer drei Jahre, nicht den ersten Monat.

Security, Compliance und Talent-Pool

OpenShift gewinnt Audits oft früher, weil SCC, Non-Root-Defaults und zertifizierte Operatoren dem Auditor eine fertige Story liefern. Vanilla-K8s kann dieselbe Härte erreichen. Ihr müsst sie aber selbst bauen und dokumentieren: Pod Security Standards, NetworkPolicies, Image-Signing, Admission-Controller, CIS-Benchmarks.

Für regulierte Branchen (Banking, Energie, KRITIS) ist das kein Feature-Duell, sondern eine Nachweisfrage. Wer schon RHEL, Satellite und Red-Hat-Support-Verträge hat, bekommt mit OpenShift eine konsistente Eskalationskette. Wer Azure-first und Entra-ID-zentriert arbeitet, baut dieselbe Nachweiskette oft schneller auf AKS mit Policy-as-Code. Mehr zur Baseline: Kubernetes Security Hardening nach CIS und NIS2.

Der Talent-Markt in DACH spricht klar für Vanilla-Kubernetes. OpenShift-Erfahrung ist seltener und teurer. Upstream-Kenntnisse (Deployments, Helm, GitOps, Observability) sind breiter verfügbar. OKD, die Community-Distribution, hat Stand 29.08.2026 rund 2.110 GitHub-Stars. Das ist ein Bruchteil der Upstream-Community.

On-Prem-Souveränität ohne OpenShift ist möglich, aber der Betriebsaufwand steigt. Wer Daten und Control-Plane im eigenen Rechenzentrum halten muss, sollte die Optionen gegen Kubernetes on-premise DSGVO-konform legen, bevor die Subscription unterschrieben ist.

Entscheidungsmatrix: wann Vanilla, wann OpenShift

Vanilla Kubernetes (AKS/EKS/GKE plus Tooling) ist die richtige Wahl, wenn:

1. Cloud-First oder Cloud-only ohne On-Prem-Pflicht
2. Engineering-Team kann Ingress, GitOps und Policy selbst betreiben
3. Subscription-Budget für Plattform-Lizenzen eng ist
4. Maximale Flexibilität bei Service-Mesh, Ingress und CI/CD zählt
5. Hyperscaler-Innovationen (GPU-Pools, KEDA, Managed Add-ons) direkt genutzt werden sollen

OpenShift ist die richtige Wahl, wenn:

1. On-Prem oder Hybrid mit hohen Compliance-Anforderungen (KRITIS, Defence, Behörden)
2. 24/7-Enterprise-Support mit vertraglicher Eskalation Pflicht ist
3. Red Hat (RHEL, Ansible, Satellite) bereits die Betriebsbasis dominiert
4. Das Operations-Team klein ist und „out of the box“ wichtiger als Flexibilität
5. Image-Registry, Pipelines und Developer-Console als Paket gewünscht sind

Drei Konstellationen, in denen wir OpenShift trotz Preis empfehlen:

On-Prem mit Compliance-Druck. Cloud ist ausgeschlossen oder nur als Burst erlaubt. OpenShift on-prem ist reifer als ein selbst zusammengebautes kubeadm-Setup.

Strikte Support-Verträge. Banken und Versicherungen brauchen oft einen Vendor mit Eskalations-SLA. Red Hat liefert das. Bei Vanilla-K8s konstruiert ihr Support über Cloud-Provider plus Integratoren.

Bestehende Red-Hat-Landschaft. Wenn RHEL schon Standard ist, sind Operations-Patterns, Patch-Zyklen und Skills konsistent. Dann ist OpenShift logische Erweiterung, kein Fremdkörper.

Unsere klare Empfehlung für die meisten Mittelstands-Cloud-Setups: Vanilla AKS oder EKS plus eigene Tooling-Schicht. Wirtschaftlicher, und nicht weniger sicher, wenn Policy-as-Code ernst gemeint ist. Welcher Hyperscaler danach kommt, klärt ihr getrennt: AKS vs EKS vs GKE.

Was 2026 bei der Plattformwahl neu ist

Die Feature-Liste ändert sich schneller als die Entscheidungsheuristik. Trotzdem zählen drei Frische-Punkte für die aktuelle Bewertung.

Erstens: OpenShift 4.22 (GA 9. Juni 2026) ist die Linie, auf die neue Cluster sollten. Wer auf 4.18 hängt, hat seit 25. August 2026 nur noch Extended Update Support, kein normales Maintenance-Fenster mehr. Odd-numbered Releases wie 4.19 haben kein EUS. Upgrade-Planung ist Pflicht, kein Nice-to-have.

Zweitens: Upstream Kubernetes 1.34 ist seit 27. August 2026 im Maintenance-Mode (EOL 27. Oktober 2026). Managed-Anbieter wie AKS, EKS und GKE tragen euch das Lifecycle-Management teilweise ab. Self-managed OpenShift und Self-hosted Vanilla-K8s tragen es selbst.

Drittens: Managed OpenShift (ROSA, ARO, OpenShift Dedicated) verschiebt die Rechnung von CapEx-Subscription zu OpEx pro vCPU-Stunde. Das hilft Teams ohne On-Prem-Zwang, die trotzdem OpenShift-Defaults wollen. Es macht OpenShift aber nicht billig. Es macht die Rechnung nur anders sichtbar.

Wer die Plattformwahl an Features von gestern festmacht, zahlt morgen doppelt: einmal Lizenz, einmal Migration. Entscheidet nach Betriebsmodell, Compliance und Teamgröße. Features folgen.

Praktischer Check vor dem Einkauf: Schreibt auf eine Seite, welche Workloads in 12 Monaten wirklich produktiv müssen, ob On-Prem Pflicht ist, und wie viele Personen Platform-Arbeit tragen. Wenn die Antwort „Cloud, drei Apps, ein DevOps-Generalist“ lautet, ist OpenShift fast immer zu schwer. Wenn die Antwort „On-Prem, Audit in Q1, kein Hyperscaler“ lautet, ist OpenShift oft die kürzere Strecke.

Pexon Decision-Sprint und Investment

Pexon Consulting (rund 80 Mitarbeitende, Deutschland, Fokus Azure/AWS/GCP und Kubernetes-Betrieb) liefert die Klärung als Festpreis-Sprint, nicht als endlose Folienlage.

1-Wochen-Decision-Sprint: 6-10k EUR Festpreis. Output: klare Empfehlung Vanilla vs. OpenShift mit Begründung, TCO über 36 Monate, Risiko- und Talent-Einschätzung, Sprint-Roadmap für die nächsten 90 Tage.

Wenn ihr schon wisst, dass ihr Experten für Aufbau oder Härtung braucht: Kubernetes-Beratung und Platform-Engineering sind die Hub-Seiten.

Häufig gestellte Fragen

Was kostet OpenShift bei einem 12-Node-Cluster?

Als Richtwert 2026: bei 16 Cores pro Node und 1.000-2.500 USD je 2-Core-Pack landet die Subscription grob bei 96-240k USD/Jahr, je nach Edition und Support. Plus Compute, Storage und Netzwerk. Red Hat quotiert final immer projektbezogen.

Können wir später von Vanilla Kubernetes zu OpenShift migrieren?

Ja, aber plant 3-6 Wochen Engineering pro Cluster. Workloads müssen oft an SCC, Routes statt Ingress und Image-Registry-Pfade angepasst werden. Eine saubere Migration ist machbar, eine „wir schieben die Namespace einfach rüber“-Story nicht.

Kubernetes vs OpenShift: was ist sicherer?

Bei Standard-Cloud-Setups nicht messbar zugunsten von OpenShift. OpenShift liefert strengere Defaults. Vanilla-K8s plus Policy-as-Code erreicht dasselbe Niveau, wenn das Team die Baseline pflegt. Der Audit gewinnt, wer Nachweise hat, nicht wer das teurere Logo zeigt.

Wann ist AKS Hybrid oder Azure Stack besser als OpenShift on-prem?

Wenn euer Stack ohnehin Microsoft-zentriert ist (Entra ID, Arc, Defender) und On-Prem nur eine Erweiterung der Azure-Welt sein soll. Bei reinem Red-Hat- oder Multi-OS-Umfeld bleibt OpenShift meist die reifere On-Prem-Antwort.

Lohnt sich OpenShift bei sehr kleinen Setups (3-5 Nodes)?

Wirtschaftlich meist nein. Die Subscription ist unverhältnismäßig hoch. Vanilla AKS oder EKS ist der pragmatische Start. OpenShift erst evaluieren, wenn Cluster-Größe, Compliance oder Red-Hat-Footprint die Rechnung tragen.

Nächster Schritt

Wenn euer Team zwischen Vanilla-Kubernetes und OpenShift schwankt: 30-Minuten-Call. Wir skizzieren, ob ein Decision-Sprint sinnvoll ist oder ob die Antwort schon klar ist.

Verwandte Themen