© Nattanan Srisut, 123RF

Red Hat verbindet seine Zukunft mit einer Reihe von Produkten – eines davon ist ohne Zweifel Open Shift. Nun schickt der Hersteller die brandneue Version Open Shift 4 ins Rennen. Das Linux-Magazin untersucht, für wen sich ein Upgrade oder der Einstieg auf diesem Level lohnt.

Kubernetes – noch lange ist kein Ende für Googles Container-Orchestrierer abzusehen. Das zeigt sich nicht zuletzt in nackten Zahlen: Im Mai 2019 fand in Barcelona die Kubecon statt, gewissermaßen die Hausmesse der Linux Foundation in Sachen Container. Laut Angaben der Veranstalter zählte man 7700 Teilnehmer – ein Wert, den auch Open Stack bei seinen Summits auf dem Höhepunkt des Hype erreichte. Klar ist unter diesen Voraussetzungen, dass kein Hersteller das Thema Kubernetes auslassen kann: Jeder fürchtet, sonst als altbacken und nicht auf der Höhe der Zeit zu gelten.

Das kann sich gerade ein Urgestein wie Red Hat nicht leisten, weshalb die Verantwortlichen in Raleigh frühzeitig Open Shift an den Start brachten. Das ist eine PaaS-Plattform, die, so das Versprechen des Herstellers, besonders leicht auszurollen und zu betreiben ist. Kürzlich warf Red Hat nun Open Shift 4 auf den Markt. Und natürlich sprudelt diese Version mal wieder vor neuen Features. Natürlich ist sie auch viel besser als alle ihre Vorgänger zusammen – glaubt man Red Hats PR-Abteilung.

Jedoch: Hält das Produkt tatsächlich, was der Hersteller verspricht? Und wie passt Open Shift in die Cloudstrategie der roten Hüte? Eben diesen Fragen widmet sich der vorliegende Artikel ausführlich.

Das Konzept

Es ist sinnvoll, sich zuvor noch mal kurz mit der Idee hinter dem Produkt selbst zu beschäftigen. Denn Open Shift unterscheidet sich deutlich von den üblichen Boxed Products. Red Hat beschreibt das Werkzeug als “Platform as a Service” – es geht also um PaaS. Und das wiederum ist ein Verweis auf eine Entwicklung innerhalb der IT, die seit Jahren schleichend vonstatten geht: Die Fragmentierung der einzelnen Schichten eines Setups. Bezog ein Kunde früher seine gesamte Umgebung noch aus einer Hand, hat er es heute meist mit mehreren Dienstleistern zu tun. Die Herausforderung besteht darin, mit standardisierten Schnittstellen den verschiedenen Anbietern die Zusammenarbeit zu ermöglichen.

Was in der Theorie kompliziert klingt, ist in der Praxis viel leichter. Unten stehen die Plattform-Anbieter, denn auch in Zeiten von Serverless Computing muss irgendwer die Server betreiben, die dem Kunden den Verzicht auf Server ermöglichen. Die Provider kommen meist mit irgendeiner Form von IaaS – also Infrastructure as a Service – um die Ecke, oft kombiniert mit ein paar As-a-Service-Angeboten wie Database as a Service. Denn, und das haben auch die Anbieter erkannt: Wer nur eine Webapplikation betreibt, der will sich nicht um den Betrieb einer Datenbank kümmern.

Nun ist es allerdings so, dass klassisches IaaS meist auf vollvirtualisierten VMs aufbaut – und die kommen mit reichlich Overhead daher.

Alles auf Docker

Dieses Problem hat Docker vor Jahren erkannt. Kurzerhand stellte man auf der Basis ohnehin vorhandener Kernelfunktionalität den VMs Container zur Seite. Die kommen mit viel weniger Overhead aus und bieten die Möglichkeit, Applikationen in Cloud-Native-Manier zu schreiben – also dem Gegenteil des konventionellen, konsolidierenden Ansatzes: Applikationen sind hier nicht mehr ein großer Monolith. Stattdessen teilen sie sich in Microservices auf, die über viele Container verteilt sind.

Damit das klappt, muss es allerdings eine Instanz geben, die jene Container verwaltet. Googles Kubernetes hat sich hier zu dem Quasi-Marktführer entwickelt. Entsprechend ist Kubernetes die Schicht, die auf klassischen IaaS-Angeboten aufsetzt und damit den effizienten Betrieb von Apps im Cloud-Native-Stil ermöglicht (Abbildung 1).

Abbildung 1: Kubernetes ist Teil der “agilen Revolution” und ermöglicht den Betrieb von Cloud-Native-Anwendungen. © Kubernetes

Die meisten Entwickler von Applikationen werden sich mit Kubernetes und dem Betrieb der Plattform selbst aber gar nicht beschäftigen wollen. Gewollt ist viel eher eine Art Kubernetes as a Service, ein Produkt, das per Mausklick auf vordefinierter Infrastruktur ein Kubernetes ausrollt und den Betrieb von eigenen Applikationen darin so leicht wie möglich gestaltet.

Und exakt das ist die Nische, in die Red Hat mit seinem Open Shift vordringen möchte. Zumindest aus heutiger Sicht – denn als PaaS-Plattform existiert Open Shift bereits seit über acht Jahren. Den radikalen Schwenk hin zu Kubernetes vollzog Red Hat aber erst, als dieses reif und erprobt genug für den produktiven Einsatz war.

Klar: Auch alle anderen Teile des modernen RZ bilden die roten Hüte in Produkten ab. Wer Open Stack betreibt, nutzt Red Hat Open Stack Platform. Wer Cloud Forms braucht, bekommt auch das als Boxed Product. Ohnehin dient allen Produkten Red Hat Enterprise Linux als Basis.

Drei Varianten

Red Hat bietet Open Shift noch immer in drei Varianten an. Die Open Shift Container Platform ist das Produkt, das Admins problemlos im eigenen Rechenzentrum ausrollen können. Wer stattdessen ein von Red Hat verwaltetes Open Shift in AWS will, greift lieber zu Open Shift Dedicated. Und davon wiederum hebt sich Open Shift Online ab, das Red Hat ebenfalls hostet. Über Open Shift Online bekommen die Anwender bei Bedarf auch Zugriff auf eine Open-Shift-Plattform und zahlen nur, was sie tatsächlich auch an Ressourcen benötigen.

Auf die Vor- und Nachteile der einzelnen Varianten geht der Artikel später noch detailliert ein. Im Fokus steht vorerst jedoch die On-Premises-Variante, also die Open Shift Container Platform.

Plattform aus einem Guss

Hier legt der Hersteller besonderen Wert darauf, dem Kunden das Gefühl einer Plattform aus einem Guss zu vermitteln. Das heißt: Für alle Arbeitsschritte gibt es ein Red-Hat-Werkzeug. Der Kunde muss also neben dem offiziellen Teil der Installation keine zusätzliche Handarbeit mehr leisten. Konkret funktioniert das so: Die roten Hüte unterscheiden zwischen Installer-basierten Setups und Anwender-basierten Setups.

Der Installer-Ansatz ist allerdings deutlich stärker automatisiert – und deckt aktuell auch nur einen Sonderfall ab: Wer Open Shift unter AWS betreiben will, kann dafür den Red Hat Open Shift Cluster Manager unter [1] nutzen und direkt in AWS ein Open Shift ausrollen. Das ist komfortabel, denn der Cluster Manager braucht lediglich gültige AWS-Credentials. Der Rest passiert vollautomatisch. Was auch Hochverfügbarkeit und andere essenzielle Details umfasst.

Etwas irritierend ist, dass Red Hat ähnlichen Komfort nicht auch auf anderen Cloudplattformen anbietet. Selbst hat man schließlich Open Stack als FL/OSS-Cloudlösung im Portfolio, und neben AWS gibt es ja auch noch Microsofts Azure und Googles GKE. Letztere immerhin sollen ab Open Shift 4.2 beziehungsweise im Falle von Open Stack ab Open Shift 4.3 zur Verfügung stehen.

Weniger automatisch geht es beim User-provisioned-Ansatz zu. Hier lädt der Admin sich zunächst ein Installationsprogramm herunter, das neben Linux zurzeit auch Mac OS unterstützt. Über dieses Installationsprogramm erschafft der Admin dann einen Bootstrap-Knoten. Der wiederum ist die Keimzelle der künftigen Open-Shift-Installation.

Ob es sich dabei um echtes Blech, um eine VM in Azure oder um eine KVM-VM auf dem privaten Open Stack handelt, ist aus Open-Shift-Sicht zunächst irrelevant – auf all diesem Plattformen werkelt die Installationsroutine problemlos.

Das Werkzeug, das dabei zum Einsatz kommt, ist übrigens neu: Ignition ist eines der Tools, die direkt aus Core OS kommen (der Artikel geht auf das Thema der von Core OS geerbten Komponenten später noch ein). Ignition ist ein Werkzeug, das auf den Control-Plane-Servern der Open-Shift-Installation läuft und die Installation neuer Systeme ermöglicht.

RHEL oder Core OS?

Beim Ausrollen einer neuen Open-Shift-Umgebung begegnet der Admin erstmals einer der zentralen Neuerungen bei 4.1 – nein, das ist kein Tippfehler: Open Shift 4.0 hat es offiziell nie gegeben, was Red Hat im Moment als Open Shift 4 vermarktet, hat von Anfang an die Versionsnummer 4.1. Zum ersten Mal tritt in der 4er Serie von Open Shift jedenfalls Red Hat Enterprise Linux Core OS auf den Plan. Klingt vertraut, nicht wahr? Tatsächlich hat Red Hat ja vor einigen Monaten Core OS gekauft. Nun wird klar warum: In Open Shift gilt das Produkt mit dem nun etwas sperrigen Namen fortan als die erste Wahl für das Betriebssystem auf den Knoten der Cloud.

Wobei der Linux-Marktführer ausdrücklich darauf hinweist, dass auch Red Hat Enterprise Linux möglich ist – solange es sich um RHEL 7 handelt. Den Umgang mit RHEL 8 beherrscht Open Shift offensichtlich noch nicht. Sonderlich viel Sinn ergibt ein solches Setup aber auch nicht. Sinn und Zweck von Containern ist es ja gerade, das Hauptsystem so sauber wie möglich zu halten. Sauber bedeutet in diesem Kontext eben auch wartungsfrei – und ein System, auf dem außer einem Kernel, ein paar basalen Bibliotheken und einer Container-Runtime nichts läuft, ist sehr viel leichter zu pflegen als ein ausgewachsenes RHEL.

Die Core-OS-Entwickler haben das bereits vor Jahren erkannt und etablierten ihre Distribution als leichtfüßiges Container-Betriebssystem ohne Brimborium. Indem Red Hat Core OS erst gekauft hat und es jetzt als bevorzugtes System für Nodes in Open Shift etabliert, geht es eben diesen Weg konsequent weiter.

Auch kommt quasi ganz nebenbei noch ein praktischer Effekt hinzu, der schon bei Core OS wichtig war: Kubelet gehört bei Core OS nämlich fest dazu, wird also in der Basisinstallation bereits ausgerollt. Kubelet ist genau der Dienst, der aus einem beliebigen Linux-System einen Kubernetes-Knoten mit der Möglichkeit macht, dort Container zu starten.

Noch mehr Teile aus Core OS

Nicht nur Core OS selbst übernimmt Red Hat aus der Akquise. Was vielen Beobachtern gar nicht klar ist: Core OS war nicht nur eine Distribution, sondern auch eine Firma. Und die hatte neben Core OS selbst noch einige andere Komponenten in Arbeit, die nun ebenfalls konsequent ihren Weg in Open Shift finden: Tectonic etwa war die von Core OS entwickelte Management-Schicht für Kubernetes, die in Open Shift 4 einige Red-Hat-Eigenbauten kurzerhand ersetzt. Der Open Shift Cluster Manager, den der Artikel eingangs bereits erwähnt hat, ist beispielsweise eine Tectonic-Komponente.

Ein weiteres Beispiel für Auswechslungen ist Quay, die für Core OS entwickelte Container-Registry, die nun ebenfalls Einzug in die neue Open-Shift-Version hält und damit eine weitere Red-Hat-Eigentwicklung (die alte Registry) ersetzt. Red Hat straft damit jene Beobachter Lügen, die das Unternehmen in den letzten Jahren auf einer kopflosen Einkaufstour wähnten: Die Kubernetes-Implementierung früherer Open-Shift-Versionen sowie die alte Registry hatte man offenbar bereits als Schwachpunkte identifiziert.

Durch den Core-OS-Zukauf kamen potentere Komponenten hinzu, die sukzessive die Nachfolge der alten Produkte antreten. Was sich auf die Arbeit der Admins gar nicht so sehr auswirken dürfte, wird hinter den Kulissen zu mehr Stabilität und Performance führen.

Zusammen mit Core OS bekommt Open Shift für die Nodes der Installation auch einen neuen Ausrollmechanismus für Updates. Künftig ist es möglich, die Knoten der Installation ebenso aus Open Shift heraus zu managen wie die zur eigenen, virtuellen Umgebung gehörenden Container. Möglich machen das die Over-the-Air-Updates: Änderungen auf den Systemen spielt Open Shift mittels »rpm-ostree« atomar und automatisch ein (Abbildung 2).

Abbildung 2: Updates aus der Luft versprechen die Open-Shift-Entwickler in Version 4 – die Funktionalität erbt Open Shift weitestgehend von Core OS, in Open Shift ist sie aber in das dortige GUI integriert. © Red Hat

Open Shift ist eine Kubernetes-Distribution

An dieser Stelle ergibt sich eine gute Gelegenheit, einmal kurz über Grundsätzliches bei der Open Shift Container Platform zu reden. Der Hersteller preist sein Produkt als “PaaS-Plattform auf Kubernetes-Basis” an. Zuallererst ist Open Shift also eine Kubernetes-Distribution. Es hat viele Dinge mit Konkurrenzprodukten wie Suses Container-as-a-Service (CaaS) gemein. Das primäre Ziel bei Open Shift ist es, dem Admin möglichst flott eine Kubernetes-Installation zu beschaffen. Auf der betreibt er dann seine Workloads auf Basis von Containern.

Aber man ahnt es schon: Red Hat reichert das Produkt mit einigen Funktionen links und rechts von Kubernetes an, die in einer originalen Kubernetes-Installation fehlen. Das ist die Special Sauce, mit der der Hersteller seine Kunden für sich gewinnen will.

Hallo CRI-O!

Das wird an kaum einer Stelle so deutlich wie beim Wechsel von Docker hin zu CRI-O, den Open Shift 4 vollzieht. Zur Erinnerung: Docker ist eigentlich eine Kombination aus einem Userspace-Daemon und einem Format für Disk-Images. Startet der Admin einen Docker-Container, kombiniert der Docker-Daemon unter der Haube verschiedene Kernelfunktionen. So erreicht er, dass die in einem Container vorhandenen Daten und Dienste vom Rest des Systems getrennt sind. Zum Einsatz kommen etwa Namespaces und C-Groups. Andere Container-Ansätze nutzen allerdings auch keine anderen Technologien: LXC etwa fußt unter der Haube auf exakt denselben Funktionen.

Warum ging dem Kubernetes-Hype dann aber ein Docker-Hype voraus? Einerseits weil es Docker gelungen ist, Container von dem Verdacht zu befreien, sie seien langweilig, und sie wieder ins Zentrum der Aufmerksamkeit zu hieven. Lösungen wie etwa Open VZ oder LXC hatten das Thema über Jahre hinweg im Dornröschenschlaf gehalten. Dank Docker und dessen Marketing-Abteilung hatten Container plötzlich wieder eine Chance am Markt.

Andererseits ist es Docker gelungen, rund um seine Lösung schnell ein großes Ökosystem zu etablieren. Dazu trug der Dockerhub maßgeblich bei, auf dem bald auch alle relevanten Distributoren Basisabbilder ihrer Systeme zur Verfügung stellten. Red Hat hat diese Entwicklung aber von Anfang an mehr oder minder kritisch beäugt. Denn Red Hat konnte kein Interesse daran haben, dass eine andere Firma den Container-Markt fast im Alleingang unter die eigenen Fittiche bringt. Obendrein war man auch mit vielen Entscheidungen auf der Technik-Seite bei Docker nicht einverstanden.

So entschieden sich die roten Hüte schließlich dazu, ein Konkurrenzprodukt an den Start zu bringen, nämlich das CRI-O-Format. CRI steht für das “Kubernetes Container Runtime Environment”. Es ist eine Art Sonderformat für Container, das speziell auf die Verwendung im Kubernetes-Kontext ausgerichtet ist. CRI-O ist ein offenes Format der Open Container Initiative (OCI), der übrigens auch Docker selbst angehört.

In Open Shift 4 macht Red Hat Ernst mit der Docker-Ablösung: War CRI-O zuvor nur als Alternative zu Docker verfügbar, ist es jetzt genau umgekehrt. CRI-O ist also das in Open Shift 4 genutzte Standardformat, während Docker nur als Fallback zur Verfügung steht.

Mächtiges Werkzeug: Das Operator-Framework

Gar nicht neu in Open Shift 4.1 ist das Operator-Framework, denn das war in Open Shift 3.11 bereits enthalten. Wieder übernimmt Open Shift hier eine von den Core-OS-Entwicklern erdachte Komponente – und was für eine! Denn das Operator-Framework richtet sich spezifisch an die Administratoren von Kubernetes-Clustern, nicht an die Benutzer. In Kurzform ist sein Versprechen, dass der Administrator sich per Operator-Framework alle Dienste auf sein System holt, die er für den effizienten Kubernetes-Betrieb braucht.

Das geht folgendermaßen: Als native Kubernetes-Applikation firmiert in der Lösung eine Applikation, die einerseits selbst als Container unter Kubernetes läuft, andererseits aber über das Kubernetes-eigene API gesteuert wird. In Kubernetes gibt es dafür die Controller – ein Controller ist eine Erweiterung des API von Kubernetes selbst.

Ein alltägliches Beispiel wären Instanzen etwa von Prometheus und seines Alertmanagers, die der Admin über das Kubernetes-API steuert, die über dieses API aber auch Daten aus Prometheus liefern. Der Kleber, der nötig ist, um diese Kontrolle in den Container hinein und den Datenfluss aus ihm heraus zu gewährleisten, ist das Fundament des Operators-Prinzips, das Red Hat aus Core OS übernommen hat.

Hinzu gesellt sich dann ein Operations Lifecycle Manager (OLM), der den Betrieb der Operators steuert. Und weil es nicht sinnvoll wäre, jeden Admin seine eigenen Operator konstruieren zu lassen, haben Core OS und Red Hat da gleich mal rein zufällig etwas vorbereitet: Zusammen mit AWS, Google und Microsoft brachte man kürzlich die Plattform Operaturhub.io in Stellung, also so etwas wie einen Dockerhub, aber eben für Open-Shift-Operators. Hier bieten Hersteller fertige Operators an, Nutzer haben in einem separaten Bereich aber auch die Option, ihre Operators anderen zur Verfügung zu stellen.

Komplettes Lifecycle-Management

Um die Dimension zu verstehen, die Open Shift 4.1 durch Operators bietet, genügen zwei Beispiele: Einerseits ist es etwa völlig problemlos möglich, über Dienste wie Consul neue Kubernetes-Pods in eine laufende Prometheus-Instanz zu übernehmen. Ab dem Augenblick, ab dem ein Pod läuft, schreibt der Prometheus-Operator für diesen also Daten mit und macht sie sodann per Kubernetes-API verfügbar.

Auch das automatische Starten neuer Pods ist kein Problem, etwa wenn die von Prometheus erhobenen Metrikdaten Notstand signalisieren: Geht dem System in seiner aktuellen Konfiguration die Puste aus, lassen sich auf Basis von Operatoren etwa neue Worker-Container starten. Die anliegende Last verteilt sich dann auf mehr Instanzen der Dienste der Anwendung, und die Gefahr von schlechter Performance ist gebannt.

So ist es per Operator also möglich, den gesamten Lebenszyklus von Pods und Containern über das Kubernetes-API zu steuern. Am Ende ergibt sich eine Orchestrierungs- und Automationsvielfalt, die denen etwa in großen Public Clouds in nichts nachsteht – aber eben auf Containern basiert.

Die prominenten Beispiele, die dieser Artikel bereits erwähnt hat, liefert Open Shift 4.1 tatsächlich auch gleich als Operatoren mit: Metering sowie Monitoring auf Basis von Prometheus und Chargeback gehören zum Lieferumfang (Abbildungen 3 und 4).

Abbildung 3: Der Operatorhub ermöglicht es in Open Shift 4.1, Operators per Mausklick zu installieren – wie hier Prometheus. © Red Hat

Abbildung 4: Operators sind Kubernetes-native Anwendungen, die direkt über das Kubernetes-API ansprechbar sind. © Red Hat

Hilfe für Entwickler mit Istio

Während der größte Teil der Neuerungen in Open Shift 4 sich zweifellos an Admins richtet, unternimmt Red Hat auch Schritte, um Entwicklern das Leben leichter zu machen. Ein Beispiel ist Istio, ein Service Mesh, das es dem Entwickler leicht macht, ein funktionierendes Netzwerk zwischen vielen Microservices derselben Applikation aufzubauen.

Dabei riegelt es automatisch beispielsweise nicht benötigte Netzwerkpfade zwischen den Diensten ab und installiert Proxyserver dort, wo sie benötigt werden (Abbildung 5). Mehr Informationen über Istio finden sich in [2].

Abbildung 5: Istio versteht sich als Full Service Mesh und stellt in einer per API abbildbaren Art Netzwerkverbindungen zwischen Containern her. © Istio

Was es kostet

Gerne würde dieser Artikel am Ende auch ausführlich auf die Kosten eingehen, mit denen Admins zu rechnen haben, wenn sie das neue Open Shift nutzen möchten. Doch wie üblich bleibt Red Hat an dieser Stelle ziemlich vage: Open Shift Online, also das von Red Hat gehostete Produkt, gibt es in der Starter-Variante zwar ohne Preisschild. Mit nur einem anlegbaren Projekt und ziemlich beschränkten Ressourcen ist das Angebot allerdings wohl eher als Testversion zu verstehen.

Wer sich entschließt die Pro-Variante zu buchen, der ist mit mindestens 50 US-Dollar pro Monat dabei, darf dafür aber immerhin bis zu zehn Projekte anlegen und bekommt daneben vom Hersteller Basissupport.

Open Shift Dedicated sowie die Open Shift Container Platform kommen komplett ohne Preisindikation daher, wer sich also für jene Produkte interessiert, ist gezwungen mit dem Red-Hat-Vertrieb direkt Kontakt aufzunehmen.

Fazit

Red Hat Open Shift ist eine Kubernetes-Distribution auf der Höhe der Zeit. Kubernetes selbst kommt in Version 1.13 – das ist zwar nicht mehr ganz neu, reicht für alltägliche Aufgaben aber völlig. Viel wichtiger als Kubernetes sind die Veränderungen links und rechts davon, die Open Shift 4.1 zu einem guten und funktionalen Produkt machen.

Da ist zunächst die Tatsache, dass Open Shift 4 Admins das Leben erheblich erleichtert. Verantwortlich dafür zeichnen vorrangig die verschiedenen Komponenten, die die Lösung aus Core OS übernimmt: Indem der Admin auf den Knoten seiner Kubernetes-Umgebung künftig Core OS ausrollt, hält er den Wartungsaufwand dort möglichst gering.

Die aus Core OS ebenfalls übernommene Kubernetes-Integration und Container-Registry tragen sehr zu erhöhter Stabilität im Vergleich mit der Vorgängerversion bei. Und Istio ist als virtueller Schnittstellenmanager so potent, dass sich seine Vorzüge im Rahmen dieses Artikels gar nicht beschreiben lassen.

Zwar schon in Open Shift 3.11 enthalten, aber doch erst jetzt so richtig und wirklich nützlich ist das Operator-Framework. Das führt eine Art umfassendes Lifecycle-Management für virtuelle Applikationen in Containern ein, das andere Kubernetes-Distributionen im Moment nicht bieten können.

Etwas befremdlich mutet hingegen der Umstand an, dass sich Red Hat Open Shift 4.1 ab Werk nicht auf Open-Stack-Clouds ausrollen lässt – ist Red Hat doch gerade auch auf jenem Markt aktiv. Entsprechend müsste man eigentlich Interesse daran haben, Open-Stack-Plattformen möglichst effizient zu verwenden. Immerhin: In einer der kommenden Open-Shift-Versionen will Red Hat das Problem lösen.

Weggefallen ist in Open Shift 4 übrigens keine wichtige Funktion. Die komplette Einbindung in CI/CD-Umgebungen wie Jenkins ist nach wie vor vorhanden und funktioniert gut, sodass Open Shift explizit auch das Wohl der Entwickler im Blick behält.

Damit wird klar: Open Shift 4 ist cool und ein Upgrade sei allen bisherigen Open-Shift-3-Anwendern wärmstens ans Herz gelegt. Wer sich im Moment grundsätzlich mit Kubernetes-Distributionen beschäftigt, sollte auch Open Shift 4 im Blick haben. Die Qualität des Tools rechtfertigt das sicherlich.