Kubernetes bietet Container-Orchestrierung. Es bietet jedoch keine Möglichkeit, Entwickler einzubinden, Sicherheitsrichtlinien clusterweit durchzusetzen oder den Lebenszyklus eines Clusters im Produktivbetrieb zu verwalten. Genau diese Lücke schliesst Red Hat OpenShift. Es zählt zu den am weitesten verbreiteten Enterprise-Kubernetes-Plattformen und taucht in nahezu jeder Diskussion über den Betrieb von Containern im grossen Massstab in regulierten oder komplexen Unternehmensumgebungen auf.
Dieser Leitfaden erklärt, was OpenShift eigentlich ist, welche Editionen und Deployment-Modelle es gibt, wie es sich von reinem Kubernetes und anderen verwalteten Kubernetes-Diensten unterscheidet, und wie Sie beurteilen können, ob es zu Ihrem Unternehmen passt.
Red Hat OpenShift ist eine Enterprise-Kubernetes-Plattform. Es kombiniert Kubernetes mit klar definierten Sicherheitsvorgaben, Entwickler-Tools, Automatisierung für den Betrieb und einer unterstützten, getesteten Distribution auf Basis von Red Hat Enterprise Linux. Während reines Kubernetes einem Team lediglich die Grundbausteine für die Container-Orchestrierung liefert, ergänzt OpenShift die Schicht, die ein Unternehmen braucht, um diese Orchestrierung sicher und wiederholbar zu betreiben: integriertes CI/CD, eingebautes Monitoring und Logging, Image-Registry-Dienste sowie rollenbasierte Zugriffskontrolle, die standardmässig aktiviert ist statt nachträglich hinzugefügt zu werden.
OpenShift gibt es in mehreren Varianten, und welche davon die richtige ist, hängt davon ab, wer die zugrunde liegende Infrastruktur verwaltet.
OCP ist die selbstverwaltete Flaggschiff-Distribution. Das Unternehmen installiert und betreibt sie auf eigener Infrastruktur, sei es on-premises, in einer Private Cloud oder auf virtuellen Maschinen in der Public Cloud. Das bietet volle Kontrolle über Cluster-Konfiguration und -Platzierung, allerdings auf Kosten des operativen Aufwands für den Betrieb.
OpenShift Dedicated ist ein Single-Tenant-Cluster, der von Red Hat verwaltet wird und auf AWS oder Google Cloud gehostet ist. Red Hat übernimmt den Cluster-Betrieb, während der Kunde eine dedizierte Umgebung behält, statt sich die Infrastruktur mit anderen Mandanten zu teilen.
ARO ist ein gemeinsam verwalteter OpenShift-Dienst für Microsoft Azure, der sowohl von Microsoft als auch von Red Hat betrieben und unterstützt wird. Er eignet sich für Unternehmen, die bereits auf Azure setzen und OpenShift nutzen möchten, ohne die Control Plane selbst zu betreiben.
ROSA ist das entsprechende verwaltete Angebot für AWS, integriert mit nativen AWS-Diensten und über AWS abgerechnet. Es eignet sich für Unternehmen mit bestehender AWS-Präsenz, die einen verwalteten OpenShift-Cluster nutzen möchten, ohne eine separate Abrechnungsbeziehung mit Red Hat einzugehen.
OpenShift Local betreibt einen minimalen Single-Node-OpenShift-Cluster auf dem Arbeitsplatzrechner eines Entwicklers. Es ist für lokale Entwicklung und Tests gedacht, nicht für Produktiv-Workloads, und ermöglicht es Entwicklern, Deployment-Manifeste und Anwendungsverhalten zu validieren, bevor sie diese in einen echten Cluster übernehmen.
Am klarsten lässt sich der Unterschied so beschreiben: Kubernetes ist die Orchestrierungs-Engine, OpenShift die vollständige Plattform, die um diese Engine herum aufgebaut ist. Reines Kubernetes überlässt Networking, Sicherheitsrichtlinien, Ingress, Image-Builds und das Lifecycle-Management des Clusters dem Betriebsteam, das diese Entscheidungen treffen und umsetzen muss, in der Regel durch Auswahl und Integration eines separaten Sets an Open-Source-Tools.
OpenShift trifft diese Entscheidungen für Sie und liefert die Integrationen bereits vorkonfiguriert. Dazu gehören Source-to-Image (S2I) Builds, die Container-Images direkt aus dem Anwendungsquellcode erzeugen, eine integrierte Container-Registry, HAProxy-basiertes Ingress-Routing sowie Sicherheitsrichtlinien wie eingeschränkte Security Context Constraints, die standardmässig aktiv sind statt optionale Erweiterungen zu sein. Ausserdem folgt OpenShift einem strukturierteren, von Red Hat kontrollierten Release-Zyklus und Support-Lebenszyklus, was für Unternehmen wichtig ist, die Verantwortlichkeit seitens des Anbieters sowie ein definiertes Zeitfenster für Patches und Support benötigen, statt sich auf den Konsens der Community zu verlassen.
Der Kompromiss betrifft die Flexibilität. Reines Kubernetes erlaubt es einem Team, genau die Toolchain zusammenzustellen, die es möchte. Die Vorgaben von OpenShift schränken diese Flexibilität ein, im Austausch für eine unterstützte, konsistente Plattform, die weniger interne Tooling-Entscheidungen erfordert, um einen produktionsreifen Zustand zu erreichen.
Unternehmen entscheiden sich für OpenShift vor allem wegen der Kombination aus Anbieter-Support und Sicherheitsniveau. Regulierte Branchen wie Banken, Versicherungen, Gesundheitswesen und der öffentliche Sektor benötigen eine Kubernetes-Distribution mit definiertem Support-Lebenszyklus, dokumentierten Compliance-Kontrollen und einem Anbieter, der zur Verantwortung gezogen werden kann. All das bietet reines Open-Source-Kubernetes von sich aus nicht.
Auch die integrierte Developer Experience spielt eine Rolle. Teams erhalten eine Web-Konsole, integriertes CI/CD über OpenShift Pipelines und Self-Service-Projektbereitstellung, ohne dieses Tooling selbst aufbauen zu müssen. Für Plattform-Teams, die viele Anwendungsteams unterstützen, verringert das den operativen Aufwand, den sie selbst entwickeln und pflegen müssten.
OpenShift dient zunehmend als Plattform für KI-Workloads in Unternehmen, nicht nur für allgemeine Anwendungscontainer. Red Hat OpenShift AI erweitert die Plattform um Tools für Modelltraining, -bereitstellung und Lifecycle-Management und läuft auf derselben Cluster-Infrastruktur und demselben Sicherheitsmodell wie die übrigen containerisierten Workloads eines Unternehmens.
Für Unternehmen, die KI-Datenplattformen aufbauen, ist das relevant, weil sich damit ein separater, paralleler Infrastruktur-Stack allein für Machine-Learning-Workloads vermeiden lässt. Datenpipelines, Model-Serving-Endpunkte und klassische Anwendungen können sich dasselbe Governance-, Netzwerk- und Zugriffskontrollmodell teilen, was sowohl den operativen Aufwand als auch die Compliance-Fläche reduziert, die unabhängig abgesichert und geprüft werden muss.
Abgesehen von den einzelnen Produktvarianten lassen sich OpenShift-Deployments grundsätzlich in drei Kategorien einteilen. Selbstverwaltete Deployments, OCP und OpenShift Platform Plus, geben dem Unternehmen die volle Kontrolle über Infrastruktur und Betrieb. Verwaltete Deployments, OpenShift Dedicated, ARO und ROSA, verlagern den täglichen Cluster-Betrieb zu Red Hat oder einem Cloud-Partner, während das Unternehmen die Verantwortung für die darauf laufenden Anwendungen behält. Entwicklerorientierte Deployments, OpenShift Local, dienen ausschliesslich dazu, einzelnen Entwicklern eine lokale Umgebung bereitzustellen, die dem Produktivverhalten nahe genug kommt, um Probleme vor dem Deployment zu erkennen.
Die meisten Unternehmen setzen letztlich auf eine Kombination: einen verwalteten oder selbstverwalteten Produktivcluster, ergänzt durch OpenShift Local für die lokale Entwicklung, damit das, was Entwickler lokal testen, der Plattform entspricht, auf der ihr Code später tatsächlich läuft.
Amazon EKS ist eine verwaltete Kubernetes-Control-Plane mit deutlich weniger eingebauten Vorgaben als OpenShift. Es bietet mehr Flexibilität, um auf AWS eine individuelle Toolchain zusammenzustellen, überlässt aber Sicherheitsrichtlinien, CI/CD und Entwickler-Tooling als Entscheidungen dem Team selbst, Aufgaben, die OpenShift von Haus aus übernimmt.
Azure Kubernetes Service ist Microsofts verwaltetes Kubernetes-Angebot, das sich in seiner Philosophie an EKS orientiert: eine schlanke Control Plane ohne die integrierte Entwicklerplattform von OpenShift. Unternehmen, die bereits tief im Azure-Ökosystem verankert sind, bevorzugen AKS mitunter wegen der engeren nativen Integration mit Azure-Diensten und nehmen dafür in Kauf, auf die eingebaute Governance von OpenShift zu verzichten.
Rancher ist eine Multi-Cluster-Management-Schicht für Kubernetes, die sich auf verschiedene Kubernetes-Distributionen aufsetzen lässt, darunter reines Kubernetes, EKS und AKS. Es konkurriert mit OpenShift im Bereich Multi-Cluster-Management und Governance, ist jedoch eine Management-Schicht und keine vollständige, vorgeprägte Plattform-Distribution, sodass für den zugrunde liegenden Cluster weiterhin eigene Sicherheits- und Tooling-Entscheidungen separat getroffen werden müssen.
Das ist derselbe Unterschied, der bereits weiter oben in diesem Leitfaden beschrieben wurde: Reines Kubernetes ist die Orchestrierungs-Engine ohne eigene Vorgaben, während OpenShift eine vollständige, unterstützte Plattform darauf aufbaut. Unternehmen, die maximale Flexibilität benötigen und bereits über tiefgehende operative Kubernetes-Erfahrung verfügen, bevorzugen mitunter reines Kubernetes mit individuell ausgewähltem Tooling. Die meisten Unternehmen ohne diese Art von Plattform-Engineering-Kapazität sind mit dem integrierten Ansatz von OpenShift besser bedient.
Die Evaluierung von OpenShift für ein Unternehmen folgt in der Regel einem konsistenten Ablauf:
Mimacom unterstützt Unternehmen bei der Evaluierung, Einführung und dem Betrieb von Red Hat OpenShift, von der ersten Plattformauswahl bis zum Produktivbetrieb und dem laufenden Betrieb. Unsere Engineering-Teams haben für Kunden in regulierten Branchen containerisierte Anwendungsplattformen und KI-Datenplattformen auf OpenShift aufgebaut und dabei Compliance-Anforderungen auf die eingebauten Kontrollen der Plattform abgebildet, statt redundantes Tooling darüber zu bauen.
Die Entscheidung für OpenShift ist im Kern keine Entscheidung über Kubernetes. Es geht vielmehr darum, wie viel Plattform-Engineering ein Unternehmen selbst aufbauen und pflegen möchte im Vergleich dazu, wie viel eine vom Anbieter unterstützte, vorgeprägte Plattform von Haus aus liefern soll. Unternehmen mit der nötigen Betriebskapazität und dem Wunsch nach voller Kontrolle können diese Plattform selbst auf Basis von reinem Kubernetes aufbauen. Die meisten Unternehmen kommen schneller und mit einer klareren Support- und Compliance-Position zum Ziel, wenn sie mit OpenShift starten.
Nein. OpenShift basiert auf Kubernetes, ergänzt es aber um eine unterstützte Distribution, integriertes Entwickler-Tooling, Standard-Sicherheitsrichtlinien und Automatisierung für den Betrieb, die reines Kubernetes von sich aus nicht mitbringt. Kubernetes ist die Orchestrierungs-Engine innerhalb von OpenShift, kein konkurrierendes Produkt.
OpenShift läuft auf allen grossen Clouds sowie on-premises. Red Hat OpenShift on AWS (ROSA) und Azure Red Hat OpenShift (ARO) sind verwaltete Angebote für die jeweilige Cloud, und OpenShift Container Platform kann selbstverwaltet auf AWS, Azure, Google Cloud oder On-Premises-Infrastruktur betrieben werden.
Ja, insbesondere durch Red Hat OpenShift AI, das die Plattform um Tools für Modelltraining und -bereitstellung auf derselben Cluster-Infrastruktur wie die übrigen Anwendungen eines Unternehmens erweitert. Dadurch können KI-Workloads dasselbe Governance- und Sicherheitsmodell nutzen wie klassische Anwendungen, statt eine separate Plattform zu benötigen.
Lassen Sie sich von Mimacom bei der Konzeption und Umsetzung Ihrer Container-Plattform unterstützen. Sprechen Sie mit unserem Team oder entdecken Sie unsere Cloud-Engineering-Services.