Kinderleichte Container

von Martin Loschwitz

Leicht, effizient und komfortabel sollen IT-Verantwortliche dank OpenShift 4.7 von Red Hat in den Genuss von Container-Orchestrierung mit Kubernetes kommen. Ob dies gelingt, entscheidet sich in der Praxis an Punkten wie Betrieb, Wartung und Sicherheit sowie den vorhandenen Kubernetes-Funktionen. Im Test bewährte sich OpenShift 4.7 zwar sehr gut, gleichzeitig brachten Abweichungen von Red Hats Vorgaben jedoch Probleme mit sich.

Es ist noch gar nicht so lange her, da wollten die meisten Administratoren nichts von Container-Virtualisierung unter Linux wissen. Projekte wie LXC oder OpenVZ hatten ihre Chance, sich in den IT-Infrastrukturen zu bewähren, und haben diese nicht genutzt – unter anderem, weil es um sie herum kein funktionierendes Ökosystem gab. Es brauchte Docker, um Schwung in den Container-Markt für Linux zu bringen, und Google, um ein Werkzeug zu bauen, das Container im Kontext einer Server-Flotte verwaltbar und orchestrierbar machte.

Komplexes Kubernetes soll einfacher werden

Heute ist Kubernetes das Standardwerkzeug für Admins, die Container über die Grenzen einzelner Server hinweg orchestrieren müssen. In Zeiten, in denen sich die IT-Landschaft wieder einmal radikal verändert und IT-Abetilungen immer öfter auch Plattformanbieter sind, ist das eine logische Entwicklung. Denn ohne eine potente Orchestrierung über die Grenzen von einzelnen Systemen hinweg wären die Plattformen, die heute üblicherweise als "Cloud" firmieren, sinnvoll gar nicht zu betreiben – dazu sind sie viel zu komplex. Dasselbe gilt mittlerweile allerdings auch für ihre Verwaltungswerkzeuge. Kubernetes ist dafür ein gutes Beispiel.

Während Kubernetes ursprünglich relativ übersichtlich war, hat die riesige Aufmerksamkeit, die die Software in den vergangenen Jahren erfahren hat, zu einer kontinuierlichen Weiterentwicklung und Erweiterung geführt. Mal eben Kubernetes aufsetzen und Faktoren wie die Integration in existierende LDAP-Verzeichnisse ad hoc richtig hinkriegen, ist alles andere als trivial, aber unabdingbar für produktive Plattformen. Kein Problem, sagen die großen Linux-Distributoren: Suse wie Red Hat haben mittlerweile eigene Distributionen von Kubernetes im Angebot. Suse mit Suse CaaS und Rancher sogar zwei, während sich Red Hat mit einem fertigen Produkt begnügt. Doch es vermarktet dieses aber ebenfalls, als handele es sich um die letzte Offenbarung, die Admins in Sachen Kubernetes jemals brauchen werden.

OpenShift muss sich fünf Fragen stellen

Daher stellen wir Red Hat OpenShift 4.7 auf den Prüfstand und orientieren uns dabei an fünf Punkten: Zunächst geht es um die Frage, wie schnell und einfach sich OpenShift aufsetzen und einrichten lässt. Das spielt eine Rolle, weil es maßgeblich den Aufwand für Admins beeinflusst und zudem in der Regel meist nicht "die eine" OpenShift-Umgebung entsteht, sondern viele Umgebungen für verschiedene Kunden (falls diese das nicht selbst erledigen). Dadurch potenzieren sich natürlich mögliche Probleme beim Setup.

Das zweite Kriterium schließt unmittelbar an diesen Faktor an und beleuchtet den Wartungsaufwand für OpenShift. Wir untersuchen, ob OpenShift dem Admin hier effektiv Arbeit abnimmt. Im dritten Schritt geht es dann um das Set der Kubernetes-Grundfunktionen und wie gut OpenShift abbildet, was Nutzer sich von Container-Orchestrierern heute wünschen. Hier soll sich zeigen, welche Funktionen Red Hat in OpenShift vorgesehen hat, die der Konkurrenz fehlen.

Die Kriterien 4 und 5 bilden zwei alte Bekannte, ohne die es im Kontext der IT der Gegenwart nicht geht, nämlich die Themen Compliance und Security. Compliance umfasst dabei neben der Integration in bestehende Infrastrukturen auch die Frage, wie gut OpenShift sich etwa für CI/ CD-Aufgaben nutzen lässt. Der Aspekt der Sicherheit geht darauf ein, wie gut OpenShift ab Werk gegen Angriffe geschützt ist und wie sich dieser Schutz noch verbessern lässt.

Variantenreiche Installation

Üblicherweise ist die Einfachheit der Installation kein Testkriterium, weil von Enterprise-Programmen heute selbstverständlich erwartet wird, dass sie sich leicht installieren und nutzen lassen. Bei einem Werkzeug wie OpenShift liegen die Dinge allerdings anders, denn hier gibt es mehrere Variablen, die den Prozess beeinflussen. Eine Variable ist, ob ein Unternehmen eine zentrale OpenShift-Instanz für sich selbst betreibt. OpenShift bietet das grundsätzlich an, weil es in Sachen Compliance und Security entsprechende Funktionen hat. Dann fällt die Arbeit der Installation nur einmal an und kleine Schnitzer wären zu verzeihen.

Im Alltag dürfte das aber nicht allzu oft vorkommen. Viele Unternehmen entscheiden sich stattdessen dafür, autarke OpenShift-Instanzen für unterschiedliche Teams zu betreiben. Und noch komplexer wird die Thematik, wenn eine Plattform lediglich als technische Grundlage für OpenShift dient, die Arbeit der Installation und der Konfiguration aber am Endanwender hängen bleibt. Ob die technische Plattform dann eine lokale OpenStack-Cloud ist, AWS, Azure oder eine andere Cloud, ist fast schon egal.

Hier entscheidet OpenShift sich jedenfalls für einen Weg, der im ersten Moment vielleicht nicht für jeden nachvollziehbar ist. Zum Einsatz kommt nämlich das Werkzeug "openshift-install" auf der Kommandozeile, mit dem sich ein kompletter Kubernetes-Cluster schnell ausrollen und auch wieder löschen lässt. Der Clou des Programms erschließt sich dem Administrator dabei erst, wenn er genauer hinschaut, denn das openshift-install-Tool beherrscht das automatische Ausrollen auf einer Vielzahl möglicher Plattformen. Will der Admin etwa OpenShift in AWS ausrollen, hinterlegt er in einer Konfigurationsdatei lediglich die AWS-Zugangsdaten. Den Rest erledigt die openshift-install-Software komplett automatisch und ohne weiteres Zutun.

Auf ähnliche Weise unterstützt OpenShift auch das Deployment auf anderen Clouds wie Azure, Googles GCP oder einem Cluster auf Basis von Red Hats eigener Virtualisierungsdistribution RHV. Open-Stack darf in der Riege der vom Installer unterstützten Plattformen freilich ebenfalls nicht fehlen und in der Tat legt der Installer alle Ressourcen in OpenStack an, wenn der Admin dafür die passende Konfiguration hinterlegt. Das umfasst ausdrücklich auch die virtuellen Instanzen für die verschiedenen Knotentypen in OpenShift, also die Master-Server für den Konsens-Algorithmus "etcd" sowie die eigentlichen Worker-Nodes.

Reduzierte Komplexität sorgt für geringere Flexibilität

Unter der Haube werkelt beim openshift-install-Tool ein Potpourri aus diversen Werkzeugen, allen voran jedoch das Automatisierungstool Ansible. Ein großer Teil der Multiplattform-Fähigkeiten kommt dann auch aus Ansible. OpenShift in einer Zielplattform auszurollen, ist mit dem Miniprogramm sehr leicht, wofür der Hersteller eigentlich eine Bestnote im Test verdient hätte. Allerdings geht die reduzierte Komplexität bei der Installation auch zulasten der Flexibilität, wenn es um die Vielfalt der OpenShift-Funktionen geht. Anhand eines Beispiels ist das gut zu erkennen: Um Red Hat OpenShift auf einem OpenStack-Cluster auszurollen, gilt es, sich zwischen verschiedenen SDN-Varianten für OpenShift zu entscheiden. OpenShift bringt grundsätzlich ein eigenes SDN mit, bietet via Kuryr aber auch die Möglichkeit, sich in ein bestehendes SDN zu integrieren.

Wirklich gut unterstützt OpenShift aktuell nur die Installation mit dem eigenen SDN, was zu geschachtelten SDN-Instanzen führt. Die elegante Lösung mit Kuryr involviert auf der OpenStack-Seite zwingendermaßen auch die in OpenStack fest integrierte Loadbalancer-as-a-Service-Komponente Octavia. Und spätestens an dieser Stelle ist es mit dem Komfort vorbei. Denn bevor der Admin OpenShift mit openshift-install in einer solchen Umgebung ausrollen kann, muss er zum Teil eigene Ansible-Templates anlegen, modifizieren und auch darüber hinaus durch einige brennende Reifen springen. Ganz so heftige Probleme begegneten uns zwar nicht bei allen Deployment-Zielen des openshift-install-Tools, dennoch bleibt es aber dabei, dass openshift-install vor allem bei Standard-Deployments von der Stange gut und zuverlässig funktioniert. Das reicht allemal für die Pflicht, aber nur bedingt für die Kür.

Teilweise noch immer händische Updates notwendig

Ist OpenShift einmal ausgerollt, ergeben sich im Alltag ab und zu ganz praktische Herausforderungen. Eine solche betrifft Admins, die gleich mehrere OpenShift-Instanzen am Bein haben. Wie bereits erwähnt gibt es mehrere Theorien dazu, wie Kubernetes generell und OpenShift im Speziellen zu nutzen ist, wenn innerhalb der Umgebung logische Barrieren nötig sind, etwa um unterschiedliche Teams sicher voneinander abzuschirmen.

Kubernetes war seitens seines Herstellers nie dafür konzipiert, wirklich mandantenfähig zu sein. Googles Empfehlung für Setups, die unterschiedliche Gruppen nutzen sollen, lautet deshalb ganz klar, mehr als eine Kubernetes-Instanz auszurollen. Diese Empfehlung gilt damit freilich auch für OpenShift, denn im Kern ist jenes ja eine Kubernetes-Installation. Folgt der IT-Verantwortliche dieser Empfehlung allerdings, hat er erheblichen Mehraufwand.

Was OpenShift nämlich zum Beispiel fehlt, ist eine zentrale Konsole, über die sich unterschiedliche OpenShift-Instanzen steuern und kontrollieren lassen. Bringt Hersteller Red Hat etwa ein Security-Announcement heraus, um auf eine Lücke hinzuweisen, muss der Administrator händisch nachhalten, dass er dieses Update überall ausgerollt hat. Das ist nicht komfortabel und auch nicht herausragend modern.

Anders verhält es sich mittlerweile bei Updates innerhalb der Major-Releases. Ein großer Kritikpunkt an OpenShift war in der Vergangenheit immer wieder, dass es beinahe unmöglich war, eine bestehende OpenShift-Installation von einer Version auf die nächste zu heben. Um des Problems Herr zu werden, hat Red Hat eine neue Komponente beigefügt, den "OpenShift Container Platform Update Service". Der macht sich den Umstand zunutze, dass OpenShift mittlerweile mit einer eigenen Ressourcen-Klasse für die Verwaltung von echtem Blech daherkommt, der sogenannten "Kubernetes Machine API".

Auf genau dieser fußt der Update-Service, der allerdings voraussetzt, dass auf den Zielsystemen Red Hat Enterprise Linux Core OS (RHCOS) läuft. Was ohnehin im Interesse des Administrators ist: Ein für den Einsatz in Kubernetes vorgesehenes System, ganz gleich, ob auf echtem Blech oder virtuell, muss "nur" Container ausführen können. Eine laufende Umgebung von "podman" ist also die einzige Voraussetzung. Es lohnt sich praktisch nicht, dafür eine RHEL-Lizenz zu verbraten.

Insgesamt präsentiert sich OpenShift durch die Kombination aus Machine-API und Update-Service heute aber besser auf Updates vorbereitet als in der Vergangenheit. Das Kriterium "Wartung und Betrieb" bringt OpenShift daher mit solider Leistung hinter sich, ohne besonders zu glänzen.

Keine Lücken bei Kubernetes-Features

Im Hinblick auf den verfügbaren Funktionsumfang gibt sich OpenShift keine Blöße. Die in Kubernetes upstream-seitig vorhandenen Features sind in OpenShift ebenfalls Teil des Pakets. Mit dem Standardlieferumfang begnügt Red Hat sich allerdings nicht und gibt OpenShift noch eine Vielzahl weiterer Konfigurationsmöglichkeiten mit auf den Weg. Das geschieht zweifelsohne auch, um sich von der Standardversion abzuheben und IT-Abteilungen einen Grund zu liefern, zahlender Kunde zu werden.

Ein gutes Beispiel dafür sind die bereits erwähnten Operators (Bild 1), die Red Hat maßgeblich entwickelt hat. Zur Vollständigkeit gehört es auch, dass der größte Teil der Operators mittlerweile schon wieder Teil des offiziellen Kubernetes ist. Red Hat verdingt sich hier also als fairer Spieler im Open-Source-Geschäft und lässt die Community an den eigenen Entwicklungen teilhaben.

Im Alltag erweisen sich Operators als ausgesprochen praktisch. Sie erlauben es Kubernetes-Nutzern, bestimmte Funktionen in der Kubernetes-API durch Templates und variable Ressourcennamen anzulegen, falls Kubernetes selbst für eine bestimmte Funktion noch keine Implementierung hat. Ein Operator könnte etwa eine Datenbank auf Basis von PostgreSQL redundant starten und dort auch gleich die Replikation konfigurieren. Operators in Kubernetes ermöglichen das schnell und unkompliziert.

Auch darüber hinaus sieht der Administrator sich wie beschrieben mit einer Vielzahl an Möglichkeiten konfrontiert, OpenShift effektiv zu nutzen. Das gilt etwa für die verfügbaren SDN-Implementierungen, bei denen OpenShift die Wahl zwischen OVN und der klassischen CNI-Implementierung von Kubernetes lässt.

Und letztlich verdient es auch der Installer, an dieser Stelle nochmals erwähnt zu werden. Denn der richtet das ausgerollte Kubernetes ab Werk so ein, dass sich verschiedene Kubernetes-Funktionen unmittelbar und ad hoc nach der Installation verwenden lassen. Direkt nach dem Deployment eines OpenShift-Clusters stand uns beispielsweise, nachdem wir DNS wie vorgegeben eingerichtet hatten, eine URL zur Verfügung, über die sich per komfortablem Webinterface PaaS-Anwendungen ausrollen liessen. Das ist eine zentrale Komponente von OpenShift, die es von Kubernetes abhebt: Red Hat integriert in OpenShift etliche fertige Container-Anwendungen (Bild 2), die sich über das zu OpenShift gehörige GUI per Mausklick ausrollen lassen. Seit OpenShift 4.7 ist diese GUI sogar in verschiedenen Sprachen verfügbar, was die Bedienung nochmals erleichtert. Das Versprechen, mit OpenShift schnell Kubernetes-Ergebnisse vorweisen zu können, hält Red Hat insofern ein.

Zahlreiche Features sorgen für Compliance

Das Thema Compliance schreibt Red Hat seit Jahren groß und OpenShift bildet da keine Ausnahme. Ab Werk lässt sich das Programm etwa nahtlos mit LDAP oder dem Active Directory verbinden, um ein "Single Source of Truth"-Konzept im Hinblick auf Benutzerdaten anzuwenden. Auch andere SSO-Optionen standen zur Verfügung, etwa die Verschmelzung mit GitHubs Login-Dienst, mit dem Google Authenticator oder mit OpenID. In Summe präsentierte sich OpenShift hier sehr kommunikativ (Bild 3).

Dasselbe gilt auch im Hinblick auf die Integration mit anderen externen Tools. So ließ sich etwa eine CI/CD-Toolchain, an deren Ende Container unmittelbar in OpenShift ausgerollt werden, ohne Probleme in der Standardedition und über die OpenShift-APIs realisieren. Entsprechende CI/CD-Systeme lassen sich allerdings auch direkt aus Open-Shift heraus betreiben.

Zusätzlich bot uns OpenShift auch den "Compliance Operator" an. Das ist eine direkt auf Kubernetes-Ebene verankerte Ressourcenklasse, die für OpenShift-Workloads Compliance-as-a-Code erlaubt. So konnten wir im Vorfeld festlegen, dass in OpenShift ausgerollte Work-loads bestimmten formalen Kriterien genügen mussten. Ist das nicht der Fall, unterband OpenShift die Ausführung des jeweiligen Codes selbstständig.

Mindestanforderungen an die Sicherheit erfüllt

Buchstäblich unspektakulär präsentierte sich OpenShift in Sachen Sicherheit. Weil auf den einzelnen Systemen der Umgebung im Normalfall ein deutlich reduziertes Red Hat Enterprise Linux Core OS zum Einsatz kommt, ist die Anzahl der potenziell von Security-Problemen betroffenen Komponenten geringer als auf einem normalen System. Im Gegenzug sind für die einzelnen OpenShift-Komponenten, die allesamt in Containerform daherkommen, öfter Updates notwendig. Hier gibt es zwar, wie eingangs erwähnt, den Update-Operator, doch dieser funktioniert nur im Kontext eines einzelnen Clusters. Uns zeigte sich im Test keine zentrale Schaltstelle, die erlaubt, viele Cluster parallel sicher zu betreiben. Es bleibt letztlich also nur das manuelle Nachhalten von Updates. Alternativ lässt sich auch Satellite nutzen, was das Preisschild aber nochmal vergrößert.

Auf der Applikationsebene gab es im OpenShift-Kontext hingegen nichts zu meckern. Alle Standardwerkzeuge von Kubernetes unterstützt OpenShift. Hinzu kommen Tools wie Istio, das zwischen den einzelnen Containern eines Pods für erhöhte Sicherheit sorgt, indem es etwa On-the-Fly-Transportverschlüsselung einführt. Um die Details mussten wir uns dabei gar nicht kümmern. Das hilft im Alltag erheblich, weil es letztlich die Nutzer und auch die Admins entlastet. Denn Letztere müssen sich seltener um wildgewordene Kundenapplikationen kümmern, nachdem diese einem Angriff zum Opfer gefallen sind.

Ganz neu: Red Hat OpenShift 4.7 Plus

Kurz vor Redaktionsschluss veröffentlichte Red Hat ein Zusatzprodukt zu Open-Shift im Rahmen der online abgehaltenen KubeCon. Das Produkt hört auf den Namen "Red Hat OpenShift Platform Plus" und erweitert die "OpenShift Container Platform" um einige der Funktionen, die uns im Test fehlten. So liegt der Plus-Edition etwa ein Werkzeug bei, mit dem sich verschiedene OpenShift-Cluster zentral verwalten lassen. Admins freuen sich in den allermeisten Fällen über einen "Single Point of Administration", den erst die Plus-Version nachrüstet. Dasselbe gilt für das Monitoring und die Überwachung mehrerer OpenShift-Instanzen, denn auch hierfür benötigt der IT-Verantwortliche, sofern er nicht selber basteln möchte, die Plus-Edition.

Vor allem verspricht die neue Variante jedoch Sicherheit. So liegt ihr etwa "Quay" bei. Diese Komponente, die Red Hat zusammen mit CoreOS übernommen hat, stellt eine Container-Registry dar, die zu Docker und Podman kompatibel ist. Quay erlaubt es, eine globale, private Container-Registry zu betreiben, in der nur vom Admin handverlesene Abbilder hinterlegt sind.

Ebenfalls auf das Thema Sicherheit zielt die Policy Engine, die das Steuern verschiedener Aktionen per Regelwerk ermöglicht. Last but not least kommt die Plus-Edition mit einer eigenen Profiling-Anwendung daher, um Risiken und Compliance-Verstöße automatisch zu erkennen, sowie mit einer zentralen Verwaltung von Updates für Sicherheitsprobleme, wie Admins es etwa auch von Red Hat Satellite bereits kennen.

Zu den Preisen für die Plus-Variante äußerte sich Red Hat allerdings bisher nicht. Klar ist nur, dass die Plus-Subskription zusätzlich zur bestehenden Standard-Subskription zu erwerben sein wird.

Fazit

Red Hat OpenShift präsentiert sich als verlässlicher Partner in Sachen effiziente Container-Orchestrierung. Wer keine Extrawürste benötigt, kommt mit dem einge- bauten Installationsprogramm gut zurecht und verfügt schnell über eine funktionale OpenShift-Instanz. Die bietet den Kubernetes-Standardumfang mit der für Red Hat typischen Fokussierung auf die eigenen In-House-Features, allen voran die Operators. Auch die Wartung bestehender OpenShift-Setups ist in Summe unproblematisch, wenn der Admin von einem Standard-Setup ausgeht. Updates von einer OpenShift-Version auf die nächste haben allerdings durchaus Thriller-Potenzial, wenn die Umgebung auch nur in wenigen Punkten vom Red-Hat-Standard abweicht. Insgesamt liefert OpenShift aber für die allermeisten Einsatzzwecke eine solide und robuste Leistung.

Produkt	Produktreihe von Container-Anwendungsplattformen für Cloud Computing.
Hersteller	Red Hat https://www.redhat.com/
Preis	Eine dreijährige Premium-Subskription mit Compute-Knoten, drei Master-Servern und Premium-Support schlägt mit etwa 42.000 US-Dollar zu Buche. Alternativ lassen sich auch Lizenzen für Cluster-Pakete mit festgelegten vCPU- und vRAM-Mengen oder pro Knoten und pro Kern/vCPU erstehen. Für eine Premium-Subskription für ein Jahr, zwei CPU-Kerne beziehungsweise vier vCPUs verlangt Red Hat 1649 US-Dollar.
Systemanforderungen	OpenShift-Master-Nodes: RHEL 7.4 oder höher, vier (v)CPUs, 16 GByte RAM, 42 GByte Speicherplatz. Für die Nodes: RHEL 7.4 oder höher, eine (v)CPU, 8 GByte RAM, 17 GByte Speicherplatz sowie 15 GByte zusätzlicher, nicht zugewiesener Speicherplatz.
Technische Daten	https://www.it-administrator.de/downloads/datenblaetter