OpenShift-Migration: auf OpenShift, zwischen Clustern und wieder weg

Update, September 2026: Dieser Artikel handelte ursprünglich von der Migration von OpenShift 3 auf 4. Er deckt jetzt OpenShift-Migrationen allgemein ab, weil Leserinnen und Leser genau danach suchen. Der Wechsel von 3 auf 4 steht weiter unten.

Die meisten, die nach einer OpenShift-Migration suchen, wechseln nicht die Version. Sie holen eine Anwendung von reinem Kubernetes auf OpenShift, fassen Cluster zusammen, oder überlegen, ob sie OpenShift wieder verlassen. Dieser Artikel deckt alle drei Fälle ab, den Wechsel von 3 auf 4 eingeschlossen.

Was OpenShift ist, in einem Absatz

Red Hat OpenShift ist eine Kubernetes-Distribution: Kubernetes plus die Teile, die jeder produktive Cluster ohnehin braucht, gemeinsam gepflegt und von Red Hat unterstützt. Dazu gehören die Container-Runtime, eine Image-Registry, Build-Werkzeuge, Monitoring, Logging und ein klarer Ansatz für Security. Den ausführlichen Vergleich findest du unter was eine Kubernetes-Distribution ist, und die kurze Fassung unter warum OpenShift.

(Bild: © Red Hat https://www.openshift.com/learn/what-is-openshift)

Von Kubernetes auf OpenShift migrieren

Deine Manifeste laufen grösstenteils weiter. Deployments, Services, ConfigMaps und PersistentVolumeClaims sind dieselben API-Objekte. Was sich ändert, ist alles drum herum.

Security Context Constraints. Das ist der Punkt, der Teams überrascht. OpenShift führt Container standardmässig nicht als root aus, und ein Helm-Chart, das nie einen User deklariert hat, startet nicht. Die Lösung ist in der Regel ein securityContext im Chart und nicht eine privilegierte SCC im Cluster. Diese Änderung lohnt sich sauber gemacht.

Routes und Ingress. OpenShift hat ein eigenes Route-Objekt und akzeptiert ebenso Standard-Ingress. Bei Ingress zu bleiben ist die portable Wahl, und die empfehlen wir, solange du keine Route-Funktion konkret brauchst.

Builds und Registries. Wenn du Images im Cluster baust, bringt OpenShift BuildConfigs und eine interne Registry mit. Wenn deine Pipeline anderswo baut, lass sie dort: nichts zwingt dich in die Werkzeuge des Clusters.

Operators. Der grösste Teil der Plattform wird von Operators verwaltet, auch ihre eigenen Komponenten. Day-2-Arbeit, die du auf Kubernetes selbst skriptest, etwa Updates und Backups, übernimmt hier oft ein Operator.

Eine Migration läuft dann ungefähr so ab: Workloads inventarisieren, danach einordnen, wie stark sie sich gegen die Punkte oben sperren, den Ziel-Cluster aufsetzen, die zustandslosen Workloads verschieben, die Daten verschieben, DNS umstellen. Der spannende Teil sind nie die Manifeste, sondern die Daten und die Umstellung.

Zwischen OpenShift-Clustern migrieren

Cluster zusammenfassen, in eine andere Cloud ziehen, oder einen Cluster verlassen, dessen Version aus dem Support gefallen ist. Red Hat liefert Werkzeuge, die sowohl die Kubernetes-Ressourcen als auch die Inhalte der Persistent Volumes verschieben, mit Object Storage als Zwischenstation. Welches Werkzeug das gerade ist, hat mehrfach gewechselt: schau darum in die Dokumentation von Red Hat statt in einen Artikel.

Von OpenShift 3 auf OpenShift 4 migrieren

Einen direkten Upgrade-Pfad von 3 auf 4 gibt es nicht: die Plattform wurde neu gebaut, und der Wechsel ist eine Migration auf einen neuen Cluster.

1. Einen neuen Cluster mit OpenShift 4 aufsetzen.
2. Ihn so konfigurieren, wie der alte es bereitgestellt hat.
3. Einen Migrationsplan schreiben, inklusive Umgang mit den Daten jeder Anwendung.
4. Den Plan ausführen, Anwendung für Anwendung.
5. DNS oder Load Balancer auf den neuen Cluster umstellen.

Geh vorher Storage, Netzwerk, Logging, Security und Monitoring durch: dort unterscheiden sich die beiden Versionen. OpenShift 3 ist seit 2021 aus dem Support. Wenn du noch darauf läufst, ist die Frage also nicht ob, sondern wohin.

Von OpenShift weg migrieren

Auch danach wird gesucht, und die Frage ist berechtigt. Wenn die Lizenzkosten von OpenShift nicht dem entsprechen, was du davon nutzt, passt reines Kubernetes mit einer verwalteten Control Plane womöglich besser. Dieselbe Portabilität, die den Weg hinein möglich macht, macht auch den Weg hinaus möglich. Aufgeben musst du das, was du bisher mitbekommen hast: die unterstützten Integrationen, die Security-Voreinstellungen, einen einzigen Ansprechpartner für den ganzen Stack. Das baust und pflegst du danach selbst.

Wir sagen es dir, wenn das für dich die bessere Antwort ist. Wir betreiben beides.

Wo VSHN hilft

VSHN ist Red Hat Premier Certified Cloud & Service Provider (CCSP) und betreibt seit 2016 Managed OpenShift unter der Marke APPUiO, on-premises und in der Cloud deiner Wahl. Wir machen die Migration und danach den Betrieb rund um die Uhr. Die Leute, die den Wechsel planen, tragen also auch das Ergebnis.

Wie so ein Wechsel in einem regulierten Umfeld aussieht, beschreibt die Success Story der acrevis Bank.

Wo du OpenShift betreiben kannst

Wir betreiben es auf zwei Arten: als dediziertes Managed OpenShift auf deinem eigenen Cluster, on-premises oder in der Cloud deiner Wahl, und als geteilte Public-Cloud-Plattform über APPUiO. Was passt, hängt davon ab, wie viel vom Cluster du für dich allein brauchst.

Buche ein Gespräch, wir gehen deine Workloads durch und sagen dir, was der Wechsel konkret bedeutet.