Kubernetes vs. OpenShift: Technischer Vergleich fuer die Plattformwahl

TL;DR

• Kubernetes ist das Open-Source-Fundament. OpenShift ist eine Red Hat Distribution, die Kubernetes um integrierte CI/CD, Monitoring, Image Registry und striktere Security Defaults erweitert.
• OpenShift erzwingt ab Werk Security Context Constraints (SCCs), die verhindern, dass Container als Root laufen. Vanilla Kubernetes erlaubt das standardmaessig.
• Die Lizenzkosten fuer OpenShift liegen typischerweise bei 15.000-50.000 EUR pro Jahr fuer einen mittelgrossen Cluster. Managed Kubernetes kostet nur die Infrastruktur plus ggf. Management-Fee.
• Wenn du ein erfahrenes Platform-Team hast, ist Vanilla Kubernetes flexibler und guenstiger. Ohne dieses Team ist OpenShift oft der schnellere Weg in die Produktion.

Was OpenShift zu Kubernetes hinzufuegt

OpenShift basiert auf Kubernetes. Jedes Kubernetes-Manifest funktioniert auch auf OpenShift. Die Unterschiede liegen in dem, was OpenShift zusaetzlich mitbringt -- und in den restriktiveren Defaults.

Konkret fuegt OpenShift hinzu:

Integrierte Image Registry: OpenShift hat eine eingebaute Container Registry. Bei Vanilla Kubernetes musst du selbst eine betreiben (Harbor, Docker Registry) oder einen Cloud-Service nutzen (ECR, ACR, GCR).

Build-System (Source-to-Image): OpenShift kann direkt aus Source Code Container-Images bauen. Bei Kubernetes brauchst du dafuer eine separate CI/CD-Pipeline.

Routes statt Ingress: OpenShift verwendet Routes als Abstraktion fuer externen Traffic. Routes unterstuetzen TLS Termination, Weighted Routing und mehr. Kubernetes nutzt Ingress-Objekte, die einen separaten Ingress Controller erfordern.

Security Context Constraints (SCCs): Die wichtigste Differenz im Tagesgeschaeft. SCCs sind restriktiver als die Kubernetes Pod Security Standards und erzwingen z.B., dass Container nicht als Root laufen, keine privilegierten Capabilities haben und keine Host-Namespaces nutzen duerfen.

Operator Hub: Ein kuratierter Marktplatz fuer Kubernetes Operators, der die Installation von Datenbanken, Monitoring-Stacks und anderen Infrastruktur-Komponenten vereinfacht.

Technischer Direktvergleich

Security Defaults: Der groesste praktische Unterschied

Auf einem Standard Kubernetes-Cluster kannst du ohne Weiteres einen Container als Root starten. Auf OpenShift wird das blockiert:

# Dieses Deployment funktioniert auf Kubernetes,
# wird auf OpenShift standardmaessig abgelehnt:
apiVersion: apps/v1
kind: Deployment
metadata:
  name: legacy-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: legacy-app
  template:
    metadata:
      labels:
        app: legacy-app
    spec:
      containers:
      - name: legacy
        image: registry.example.com/legacy-app:1.0
        # Kein securityContext definiert
        # -> Laeuft als Root
        # -> OpenShift blockiert das via SCC "restricted"

OpenShift-kompatible Version:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: legacy-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: legacy-app
  template:
    metadata:
      labels:
        app: legacy-app
    spec:
      securityContext:
        runAsNonRoot: true
        seccompProfile:
          type: RuntimeDefault
      containers:
      - name: legacy
        image: registry.example.com/legacy-app:1.0
        securityContext:
          allowPrivilegeEscalation: false
          capabilities:
            drop:
            - ALL

Diese restriktiveren Defaults sind ein klarer Vorteil von OpenShift. Auf Vanilla Kubernetes kannst du das gleiche Niveau erreichen, musst aber selbst Pod Security Standards oder einen Policy Engine wie Kyverno/OPA Gatekeeper konfigurieren. Mehr dazu unter Kubernetes Security Hardening.

Kostenvergleich: TCO-Betrachtung

Die reine Lizenzfrage greift zu kurz. Der faire Vergleich ist die Total Cost of Ownership (TCO):

Szenario: 3 Nodes, 10 Microservices, 1 Team

Managed Kubernetes (z.B. AKS):

• Infrastruktur: ca. 800-1.200 EUR/Monat
• Tooling (Harbor, ArgoCD, Prometheus/Grafana, cert-manager): 1-2 Wochen Setup, dann Wartung
• Personalaufwand fuer Tooling-Wartung: ca. 0,3 FTE
• Gesamtkosten/Jahr: ca. 25.000-40.000 EUR (inkl. anteiligem Personal)

OpenShift (Self-Managed):

• Infrastruktur: ca. 800-1.200 EUR/Monat
• OpenShift Subscription: ca. 15.000-25.000 EUR/Jahr
• Tooling: Integriert, weniger Wartung
• Personalaufwand: ca. 0,1-0,2 FTE (fuer Plattform-Wartung)
• Gesamtkosten/Jahr: ca. 35.000-55.000 EUR

Die Differenz wird kleiner, je weniger Kubernetes-Expertise intern vorhanden ist. Wenn du 0,5 FTE fuer die Wartung des Open-Source-Stacks brauchst, kann OpenShift guenstiger sein als die Personalkosten fuer Vanilla Kubernetes.

Fuer eine detaillierte Kostenbetrachtung von Managed Kubernetes siehe Kubernetes Hosting Kosten im Vergleich.

Developer Experience im Vergleich

Ein oft unterschaetzter Faktor: Wie fuehlt sich die taegliche Arbeit auf der jeweiligen Plattform an?

Kubernetes: Entwickler interagieren ueber kubectl und muessen Manifeste selbst schreiben. Die Lernkurve ist steiler. Dafuer ist das Wissen portabel -- wer kubectl beherrscht, kann auf jedem Kubernetes-Cluster arbeiten, unabhaengig vom Anbieter.

OpenShift: Die Web-Konsole bietet eine grafische Uebersicht ueber Deployments, Builds und Logs. Die oc-CLI ist ein Superset von kubectl mit zusaetzlichen Befehlen wie oc new-app, das eine Anwendung aus einem Git-Repository in einem Schritt baut und deployt. Das reduziert den Einstiegsaufwand erheblich.

# OpenShift: Anwendung direkt aus Git deployen
oc new-app https://github.com/example/nodejs-app.git \
  --name=my-node-app \
  --strategy=docker

# Kubernetes: Gleiches Ergebnis erfordert mehrere Schritte
# 1. Dockerfile schreiben
# 2. Image bauen (lokal oder in CI)
# 3. Image in Registry pushen
# 4. Deployment-Manifest schreiben
# 5. kubectl apply

Fuer Teams, die gerade erst mit Container-Orchestrierung anfangen, ist die niedrigere Einstiegshuerde von OpenShift ein relevanter Faktor. Fuer erfahrene Teams, die bereits Helm Charts und GitOps-Workflows nutzen, ist dieser Vorteil weniger relevant. Einen guten Einstieg bietet Helm Charts Einfuehrung.

Wann Vanilla Kubernetes die bessere Wahl ist

• Du hast ein Platform Engineering Team mit Kubernetes-Erfahrung.
• Du willst maximale Flexibilitaet bei der Wahl deiner Tools (z.B. Cilium statt OpenShift SDN, Linkerd statt Istio).
• Du betreibst Multi-Cloud und willst keinen Vendor Lock-in.
• Dein Budget ist begrenzt und du kannst die Tooling-Wartung intern stemmen.
• Du nutzt bereits einen Managed Kubernetes Service (AKS, EKS, GKE) und willst den Cloud-nativen Stack.

Wann OpenShift die bessere Wahl ist

• Dein Team hat wenig Kubernetes-Erfahrung und braucht eine integrierte Loesung.
• Du brauchst Enterprise Support mit SLAs fuer kritische Workloads.
• Compliance-Anforderungen (BSI, ISO 27001) erfordern strenge Security Defaults ab Werk.
• Du betreibst viele Legacy-Anwendungen, die das Build-System (Source-to-Image) nutzen koennen.
• Dein Unternehmen ist bereits im Red Hat Ecosystem (RHEL, Ansible, Satellite).

Upgrade-Strategie: Wie aufwendig sind Cluster-Updates?

Ein Punkt, der bei der Plattformwahl oft zu spaet bedacht wird: Kubernetes-Cluster muessen regelmaessig aktualisiert werden. Minor Versions erscheinen alle 4 Monate, und jede Version wird nur 14 Monate lang mit Security Patches versorgt.

Managed Kubernetes (AKS, EKS, GKE): Der Cloud-Anbieter uebernimmt die Control Plane Updates. Worker Nodes musst du selbst aktualisieren, was in der Regel ueber Node Pool Replacement oder Rolling Node Upgrades funktioniert. Der Aufwand ist ueberschaubar, erfordert aber Planung und Testing.

OpenShift: Red Hat liefert getestete Update-Pfade ueber den Cluster Version Operator. Du gibst den Ziel-Channel an (z.B. stable-4.15) und OpenShift fuehrt ein orchestriertes, komponentenweises Update durch. Das ist komfortabler als manuelle Updates, aber du bist an Red Hats Release-Zeitplan gebunden und kannst nicht sofort auf die neueste Kubernetes-Version zugreifen.

Self-managed Kubernetes: Der aufwendigste Fall. Du musst etcd, API Server, Controller Manager, Scheduler und kubelet einzeln aktualisieren, in der richtigen Reihenfolge, mit den richtigen Kompatibilitaetsgarantien. Tools wie kubeadm automatisieren das teilweise, aber das Risiko bei Fehlern ist hoeher.

Die Faustregel: Je weniger Operations-Erfahrung im Team, desto wertvoller sind die automatisierten Update-Pfade von Managed Services oder OpenShift.

Migration zwischen den Plattformen

Die gute Nachricht: Da OpenShift auf Kubernetes basiert, sind Standard-Kubernetes-Manifeste portabel. Die Einschraenkung: OpenShift-spezifische Ressourcen (Routes, BuildConfigs, DeploymentConfigs) sind nicht auf Vanilla Kubernetes uebertragbar.

Wenn du Portabilitaet maximieren willst:

1. Verwende Kubernetes-Standard-Ressourcen (Deployments, Services, Ingress) statt OpenShift-spezifische (DeploymentConfig, Route).
2. Packe deine Anwendungen in Helm Charts oder Kustomize Overlays.
3. Halte Security Contexts explizit in deinen Manifesten, statt dich auf OpenShift SCCs zu verlassen.

# Test: Kann dein Deployment auf beiden Plattformen laufen?
# Dry-run auf Kubernetes
kubectl apply --dry-run=server -f deployment.yaml

# Dry-run auf OpenShift
oc apply --dry-run=server -f deployment.yaml

Fuer eine ausfuehrliche Betrachtung der Migration siehe Cloud-Native Migration.

Entscheidungsmatrix

Beantworte diese vier Fragen, um eine fundierte Entscheidung zu treffen:

Wenn du bei 3 oder mehr Fragen in Richtung Kubernetes antwortest, ist das wahrscheinlich die richtige Wahl. Dasselbe gilt umgekehrt fuer OpenShift.

Haeufige Fragen

Kann ich OpenShift-Workloads auf Kubernetes migrieren?

Ja, solange du Standard-Kubernetes-Ressourcen verwendest. OpenShift-spezifische Objekte (BuildConfig, Route, DeploymentConfig) muessen durch ihre Kubernetes-Aequivalente ersetzt werden (CI/CD Pipeline, Ingress, Deployment).

Ist Rancher eine Alternative zu OpenShift?

Rancher ist ein Multi-Cluster-Management-Tool, kein Kubernetes-Distribution wie OpenShift. Es verwaltet beliebige Kubernetes-Cluster (RKE, EKS, AKS) und bietet eine zentrale UI, Monitoring und RBAC. Es hat niedrigere Kosten als OpenShift, aber weniger integrierte Funktionen. Siehe Rancher vs. Kubernetes.

Was ist mit OKD (OpenShift Community Edition)?

OKD ist die Open-Source-Variante von OpenShift. Sie bietet viele der gleichen Funktionen ohne Lizenzkosten, aber ohne Red Hat Support. Fuer Test- und Entwicklungsumgebungen ist OKD eine gute Option. Fuer Produktion fehlt der Enterprise Support, den viele Organisationen fuer kritische Workloads benoetigen.

Unterstuetzen beide Plattformen GPU-Workloads?

Ja. Kubernetes und OpenShift unterstuetzen NVIDIA GPU Operator fuer GPU-Workloads. OpenShift hat den Vorteil, dass der Operator ueber den integrierten Operator Hub installierbar ist. Bei Kubernetes musst du den Operator manuell deployen. Details unter Kubernetes GPU Cluster.

Wie sieht es mit Compliance (BSI, DSGVO) auf beiden Plattformen aus?

Beide Plattformen lassen sich DSGVO- und BSI-konform betreiben. OpenShift hat den Vorteil strikterer Defaults (SCCs, integriertes Audit Logging), was den initialen Aufwand reduziert. Auf Vanilla Kubernetes musst du RBAC, NetworkPolicies und Encryption at Rest selbst konfigurieren. Der Aufwand ist ueberschaubar, aber er muss aktiv geleistet werden. Eine detaillierte Anleitung dazu unter Kubernetes Compliance: DSGVO und BSI-Grundschutz.

Die Plattformwahl ist keine rein technische Entscheidung. Sie haengt von Team-Skills, Budget, Compliance-Anforderungen und der bestehenden Infrastruktur ab. Wenn du eine unabhaengige Bewertung fuer deine konkrete Situation brauchst, melde dich unter /kontakt.