OpenShift-Alternativen: Ausstieg, Ersatz und Migrationspfad

Kubernetes-Plattform nach OpenShift oder Rancher neu aufstellen? WZ-IT baut und betreibt die Zielplattform auf Proxmox, Bare Metal oder als Hosting in Deutschland. Kubernetes-Angebot ansehen

Wer OpenShift verlässt, verlässt selten Kubernetes, sondern eine Plattformschicht aus Operatoren, Routes, Security Context Constraints, Builds und Registry. Der Leitfaden zeigt, wie die Lizenzmenge gezählt wird und was veröffentlichte Preise hergeben, was OpenShift mitbringt und beim Wechsel zu ersetzen ist, welche Alternativen zu welchem Fall passen und wie der Migrationspfad aussieht. Er endet in einer Entscheidungstabelle. Stand Oktober 2026.

Inhaltsverzeichnis

• OpenShift-Kosten und Lizenzmenge
• Was OpenShift mitbringt und was zu ersetzen ist
• Alternativen im Überblick
• Rancher verlassen
• Migrationspfad: Routes, SCC, BuildConfigs, Operatoren
• Entscheidungstabelle
• VMware-Alternative als Randthema
• Unser Vorgehen bei WZ-IT
• Stand und Methodik
• Weiterführende Guides

OpenShift-Kosten und Lizenzmenge

Ob Lizenzkosten, der Betrieb der Plattformschicht oder ein Standortwunsch den Ausschlag geben, bestimmt die Alternative. Für die Kosten gilt: Für selbst gemanagtes OpenShift nennt Red Hat keinen Betrag, die Preisseite schreibt: „Die Preise variieren je nach ausgewählter Größe und Subskription." Die Menge lässt sich aber zählen. Nach dem Subskriptions-Guide ist ein Kernpaar 2 physische Kerne oder 4 vCPUs; für Bare-Metal-Server gibt es alternativ eine Node-Subskription je physischem Server, unabhängig von Sockets und Kernen. Subskriptionen brauchen die Rechenknoten, Control-Plane- und Infrastrukturknoten brauchen keine, solange darauf keine Anwendungen laufen. Der Support-SLA ist Standard (8x5) oder Premium (24x7).

Die Rechnung: Kernpaare = Summe der vCPUs aller Rechenknoten geteilt durch 4. Beispiel: 12 Worker mit je 16 vCPU sind 192 vCPUs und 48 Kernpaare, die drei Control-Plane-Knoten zählen nicht. Mit dem Betrag aus dem eigenen Angebot ergeben sich die Jahreskosten.

OpenShift als Dienst nennt Preise: Azure Red Hat OpenShift (Preise) und Red Hat OpenShift Service on AWS (Preise) berechnen 0,171 USD je Stunde je 4 Worker-vCPU, bei ROSA unabhängig von der Region. Dazu kommen die Infrastruktur und bei ROSA mit Hosted Control Planes 0,25 USD je Stunde und Cluster; Verträge über 1 oder 3 Jahre senken den Worker-Anteil laut AWS um 33 bis 55 Prozent. Red Hat nennt Reserved Instances ab 0,076 USD je Stunde (4-vCPU-Vertrag, 3 Jahre). On-demand ergibt das je Jahr:

Rechenweg: 0,171 USD × 8.760 Stunden = 1.497,96 USD je 4 vCPU und Jahr, ohne Infrastruktur und Rabatte, Abruf 28.10.2026. Fragen an jedes Angebot, auch an das von SUSE für Rancher Prime, dessen Produktseite keinen Preis nennt:

• Welche Knoten zählen, auch Control-Plane- und Infrastrukturknoten?
• Welche Einheit gilt, mit welcher Umrechnung?
• Reicht OpenShift Kubernetes Engine statt Container Platform?
• Welche Zusatzprodukte sind im Einsatz: Advanced Cluster Management, Advanced Cluster Security, Quay, Data Foundation?
• Laufzeit, Kündigungsfrist und Preisbindung bei Verlängerung?

Was OpenShift mitbringt und was zu ersetzen ist

Laut Preisseite liefert OpenShift Kubernetes Engine das Kubernetes-Fundament auf Red Hat Enterprise Linux CoreOS. Container Platform ergänzt Entwicklungskonsole, Serverless, Service Mesh, Pipelines und GitOps. Platform Plus ergänzt Advanced Cluster Management, Advanced Cluster Security, Data Foundation Essentials und Quay. Pipelines und GitOps sind portabel: Pipelines basieren auf Tekton, GitOps nutzt Argo CD. Die übrigen Bausteine sind OpenShift-spezifische API-Objekte und Plattformkomponenten:

DeploymentConfigs sind seit OpenShift 4.14 deprecated, die Dokumentation empfiehlt Deployments, solange keine Funktion nur DeploymentConfigs bietet. Die Umstellung lohnt sich daher auch beim Bleiben. SCC und Pod Security Admission sind in OpenShift zwei unabhängige Mechanismen: Workloads müssen beide erfüllen.

Alternativen im Überblick

Konsole, integrierte Registry und Builds in der Form von OpenShift bringen nur OpenShift selbst und OKD mit; bei den übrigen Optionen werden diese Werkzeuge ergänzt oder entfallen. Beim Wechsel vom Herstellersupport zum Eigenbetrieb gehen Upgrades und die Reaktion auf Sicherheitslücken in die eigene Verantwortung, es sei denn, ein Dienstleister übernimmt sie. Die Wahl der Distribution erklärt der Guide k3s vs. RKE2 vs. Talos.

Rancher verlassen

Rancher Manager ist laut Dokumentation ein Werkzeug, um Cluster bei beliebigen Anbietern bereitzustellen und zu betreiben, RKE2 die zugehörige Distribution. Beide stehen unter Apache-2.0 (Rancher, RKE2); SUSE verkauft die Subskription als SUSE Rancher Prime. Ein Ausstieg aus Rancher heißt deshalb nicht, die Cluster neu zu bauen. Laut der Rancher-Dokumentation laufen die Workloads in verwalteten Clustern weiter, wenn Rancher gelöscht wird. Importierte Cluster bleiben unverändert erreichbar, bei von Rancher bereitgestelltem RKE2 oder k3s braucht es den Authorized Cluster Endpoint und eine bereits heruntergeladene kubeconfig. Gehostete Cluster eines Cloud-Anbieters bleiben über dessen Zugangsdaten erreichbar; die Dokumentation sieht für sie kein Abkoppeln von Rancher vor. Beim Entfernen verschwinden auch Fleet und der Rancher-Webhook; CRDs und eigene Namespaces werden von Hand entfernt, und ein anderes Werkzeug muss GitOps übernehmen. Ob ein Betrieb ohne Herstellersupport tragbar ist, ist eine Betriebsfrage und keine Lizenzfrage.

Migrationspfad: Routes, SCC, BuildConfigs, Operatoren

Die Reihenfolge folgt den Abhängigkeiten, nicht der Zahl der Objekte. Das Inventar:

# OpenShift-spezifische Objekte zählen
for r in routes.route.openshift.io deploymentconfigs.apps.openshift.io \
         buildconfigs.build.openshift.io imagestreams.image.openshift.io \
         subscriptions.operators.coreos.com; do
  printf "%-45s %s\n" "$r" "$(oc get "$r" -A --no-headers 2>/dev/null | wc -l)"
done

# Pods nach Security Context Constraint
oc get pods -A -o json | jq -r '.items[] | (.metadata.annotations["openshift.io/scc"] // "none")' | sort | uniq -c | sort -rn

# Routes nach TLS-Terminierung und nach HAProxy-Annotationen
oc get routes -A -o json | jq -r '.items[] | (.spec.tls.termination // "none")' | sort | uniq -c
oc get routes -A -o json | jq -r '.items[] | (.metadata.annotations // {}) | keys[] | select(startswith("haproxy.router.openshift.io"))' | sort | uniq -c | sort -rn

1. Pod Security. Pods unter anyuid oder privileged brauchen ein Image, das ohne Root läuft, oder ein begründetes Namespace-Profil. Sobald die Workloads in einem Testcluster laufen, zeigt kubectl label --dry-run=server --overwrite ns <namespace> pod-security.kubernetes.io/enforce=restricted, welche laufenden Pods gegen den Standard restricted verstoßen (Kubernetes-Dokumentation). Erledigt, wenn jeder Namespace ohne Verstöße unter seinem Profil läuft.
2. Routes. Nach TLS-Modus sortieren: Edge wird ein HTTPS-Listener mit HTTPRoute, Re-Encrypt zusätzlich eine BackendTLSPolicy (Standard-Kanal seit Gateway API v1.4.0), Passthrough eine TLSRoute (seit v1.5.0). Die HAProxy-Annotationen für Timeouts oder HSTS haben je Implementierung ein eigenes Gegenstück. Die Guides Gateway API vs. Ingress und ingress-nginx zu Gateway API beschreiben die Umstellung. Erledigt, wenn jede Route ein Gegenstück mit gleichem TLS-Modus hat.
3. DeploymentConfigs, Builds, Images. DeploymentConfigs werden Deployments, Trigger übernimmt GitOps oder die CI. BuildConfigs wandern in die CI-Pipeline, ImageStream-Referenzen werden Tags oder Digests in einer Registry außerhalb des Clusters. Erledigt, wenn kein Manifest mehr auf DeploymentConfig, BuildConfig oder ImageStream verweist.
4. Operatoren. Je Subscription gibt es ein Upstream-Chart oder einen Operator, der per GitOps installiert wird. Operatoren ohne Upstream-Pendant entscheiden über Bleiben oder Wechseln. Erledigt, wenn jede Subscription ein Gegenstück hat oder bewusst entfällt.
5. Parallelbetrieb und Cutover. Daten, Parallelbetrieb, Umschaltung und Rückfallweg folgen den Phasen 3 bis 6 aus dem Ausstiegsleitfaden; Backups mit Velero beschreibt der Backup-Guide.

Entscheidungstabelle

VMware-Alternative als Randthema

Red Hat OpenShift Virtualization Engine ist laut Subskriptions-Guide ein reines Bare-Metal-Angebot für VM-Workloads, ohne Container-Anwendungen. Wer VMs ablöst und keine Container-Strategie hat, vergleicht Proxmox mit einer Kubernetes-Plattform. WZ-IT ist Proxmox Authorized Reseller. Details: VMware-Alternativen, Kubernetes auf Proxmox und Proxmox vs. Kubernetes.

Unser Vorgehen bei WZ-IT

Am Anfang steht das Inventar der OpenShift- oder Rancher-spezifischen Objekte (Befehle im Abschnitt Migrationspfad). Die Zielplattform baut und betreibt WZ-IT: Managed Kubernetes auf Proxmox, Bare Metal oder als Hosting in Deutschland kostet ab 590 € netto je Cluster und Monat inklusive 3 Worker-Nodes, jeder weitere Worker-Node 129,90 €. Beim Hosting kommen die Cluster-Basis ab 129,90 € und Worker-Nodes ab 64,90 € hinzu. Den Umbau OpenShift-spezifischer Objekte besprechen wir nach dem Inventar. Stand Oktober 2026.

Stand und Methodik

Stand: 28.10.2026. Lizenzregeln, Editionen und Preise stammen von den verlinkten Herstellerseiten und wurden an diesem Tag gelesen. Für selbst gemanagtes OpenShift und für SUSE Rancher Prime nennen die Hersteller dort keine Preise, deshalb gibt es dafür keine Rechnung. Die Jahreswerte für ROSA und ARO gelten on-demand in USD ohne Infrastruktur und Rabatte. Die OpenShift-Dokumentation ist Version 4.22, OKD-Seiten zeigen die jeweils aktuelle Version. Die Entscheidungstabelle ist eine Regel für die erste Einordnung und ersetzt das Inventar nicht.

Weiterführende Guides

• k3s vs. RKE2 vs. Talos und Talos Linux auf Proxmox
• Gateway API vs. Ingress und ingress-nginx zu Gateway API migrieren
• EKS, AKS oder GKE verlassen für OpenShift als Dienst bei den Hyperscalern
• Kubernetes-Backup und Cluster übernehmen: Audit-Checkliste

Aufbau und Betrieb der neuen Plattform beschreibt das Kubernetes-Angebot. Für VM-Workloads steht Kubernetes auf Proxmox bereit, den laufenden Betrieb beschreiben Managed Kubernetes und die Service Levels.