© Roman Iegoshyn, 123RF

Red Hat legt sich bei seiner Kubernetes-Distribution Open Shift ordentlich ins Zeug. Sind die Neuerungen nur Kosmetik oder ein echter Fitness-Booster?

[UCC:x-l-anfang-sys]Mitte vorigen [/UCC] Jahres hatte sich das Linux-Magazin zum letzten Mal mit Open Shift [1] beschäftigt. Das Produkt, das Red Hat wie ein neu erfundenes Rad bewirbt, ist bei nüchterner Betrachtung eigentlich nur eine kommerzielle Distribution der Container-Orchestrierung Kubernetes [2].

“Eigentlich” – weil es dabei nicht bleibt. Seit der Version 3.0, in der der Hersteller das Produkt auf das neue Fundament Kubernetes hob, gab es kontinuierliche Verbesserungen in vielen Teilen der Software. Von welchen Funktionen profitieren Admins, die eine Open-Shift-Cloud betreiben, besonders? Was erfreut Anwender und aus welchen Neuerungen ziehen Entwickler den größten Nutzen? Der folgende Artikel gibt Auskunft.

Neuer Besen?

Eine auffällige Änderung ergibt sich seit Open Shift 3.4 bereits bei der Benennung der einzelnen Produkte der Open-Shift-Serie. Open Shift ist ja eine Art Markenname, hinter dem sich mehrere Produkte in verschiedenen Ausführungen verbergen. Open Shift Origin bezieht sich auf das ursprüngliche Open-Source-Produkt, auf dem die kommerziellen Varianten von Open Shift basieren. Die Open-Source-Variante ist für jene Nutzer interessant, die Red Hat kein Geld überweisen möchten. Sie erhalten im Gegenzug aber auch keinerlei Support.

Wer dagegen Unterstützung braucht, hat die Wahl zwischen Red Hats öffentlicher Open-Shift-Installation als einer Art Public Cloud, einer Open-Shift-Installation, die Red Hat im Kundenauftrag hostet, und einer privaten Open-Shift-Installation im eigenen Rechenzentrum. An Interessenten für die letztgenannte Option richtete sich dereinst Open Shift Enterprise, das nun einen neuen Namen bekommt: Künftig firmiert das Produkt bei Red Hat unter der Bezeichnung Open Shift Container Platform.

Allerdings beeilt sich der Hersteller klarzustellen, dass sich außer dem Namen des Produkts nichts geändert hat. Die Motivation für die Umbenennung dürfte daher sein, dass Red Hat innerhalb seines Portfolios Open Shift besser mit anderen Komponenten vernetzen will. Auch die bessere Integration mit Cloud Forms, auf die der Artikel später noch eingeht, gehört wohl zu diesen Maßnahmen.

Updates bei Kubernetes und Docker

Offensichtlich verändert hat sich dagegen einiges unter der Haube. Weil der Open-Shift-Releasezyklus recht kurz ist, hält Red Hat Schritt mit der Entwicklung bei Kubernetes und Docker [3]. Die Neuerungen, die sich aus dieser Richtung ergeben, bekommen Nutzer nicht unmittelbar zu Gesicht – Sinn und Zweck von Open Shift ist es ja gerade, dem Benutzer ein integriertes Produkt mit GUI und allen Schikanen anzubieten. Wie bisher geht das auch weiterhin fast nur auf RHEL- oder Centos-Systemen.

Wer Open Shift Origin in Kombination mit einer kommerziellen Open-Shift-Variante nutzt, ist auf das Red Hat Linux festgelegt. Er kann zwischen der normalen Variante oder der auf das absolute Minimum reduzierten Atomic-Version von RHEL wählen. Egal für welche Variante man sich entscheidet: Für Open Shift in der Version 3.6, die zu Redaktionsschluss gerade aktuell war, ist auf den Hosts ein aktuelles Docker aus dem Extras-Verzeichnis von Docker erforderlich.

Einfachere Installation

Apropos Atomic Linux. Zwar bietet Red Hat auch weiterhin zwei Wege an, um das eigene Open-Shift-Deployment zu starten. Nämlich jenen, bei dem auf einem normalen RHEL Open Shift per RPM installiert wird, sowie einen, bei dem der Admin ein fertiges Open Shift in Form eines Docker-Containers installiert. In den letzten Open-Shift-Versionen hat Red Hat das Container-basierte Setup aber deutlich vereinfacht und beschleunigt. Auf Basis eines von Red Hat offiziell angebotenen Docker-Abbilds aus dem Docker-Hub lässt sich eine komplette und funktionierende Open-Shift-Umgebung inzwischen mit einem einzigen Befehl in wenigen Sekunden ausrollen [4].

So ein All-in-one-Setup eignet sich allerdings nur bedingt für den Produktivbetrieb. Red Hat gibt das auch unumwunden zu und empfiehlt für größere, komplexe Setups die auf Ansible basierende RPM-Installation. Für Entwickler allerdings, die in einer sauberen Open-Shift-Umgebung experimentieren und testen wollen, ist der neue Deployment-Mechanismus ein echter Segen.

Es gilt also: Für große Setups ist die RPM-Variante gut geeignet, wer Open Shift nur mal testen möchte oder wer damit entwickeln will, ist mit der Installation aus einem Container bestens bedient (Abbildung 1).

Abbildung 1: Open Shift Origin lässt sich mittels eines einzelnen Kommandos als All-in-one-Installation starten.

Authentifizierung mit LDAP

Das Thema Benutzerverwaltung gehört meist nicht zu den bei Admins besonders beliebten Themen. Denn es ist sehr komplex und nicht nur mit der IT, sondern mit vielen anderen Aspekten einer Firma verbunden. Der Vertrieb, die Verrechnungsabteilung und die Technik nutzen idealerweise dieselben Daten, wenn es um die Verwaltung derer geht, die am Ende tatsächlich kostenpflichtige IT-Dienste konsumieren dürfen.

Open Shift bot schon im Sommer 2006 eine durchaus beeindruckende Liste an Mechanismen, um das Thema Authentifizierung abzuwickeln. Der Klassiker, der bei den meisten Setups für die Authentifizierung der Nutzer zum Einsatz kommt, dürfte Oauth sein.

Die Herausforderung: Die Nutzerdaten, gegen die Oauth abgleicht, müssen von irgendwoher kommen. Regelmäßig findet sich ein LDAP-Verzeichnis als Quelle solcher Daten. Ganz gleich, ob es sich um eine private Open-Shift-Installation handelt, bei der es lediglich um interne Mitarbeiter geht, oder um eine öffentliche Installation, die auch Kunden nutzen – mittels LDAP lassen sich diese Daten komfortabel verwalten.

Die erste Version des 3er Releasezyklus von Open Shift bot zwar LDAP schon als mögliche Quelle für Nutzerdaten an. Doch konnte Open Shift 3.0 damals nur Benutzerzugänge aus LDAP laden. Eventuell vorhandene Gruppenzuordnungen fielen unter den Tisch. Was wie eine Lappalie klingt, hat das Zeug zum Liebestöter: Weil Open Shift intern die Rechtevergabe auch anhand von Gruppen abwickelt, hätte ein Admin bei der Kombination aus LDAP und Open Shift 3.0 de facto zwei Benutzerverzeichnisse pflegen müssen – die Benutzerliste im LDAP und die Gruppenzugehörigkeit in Open Shift.

Genau diesen Unsinn haben die Entwickler beendet: Mittlerweile kann Open Shift die in LDAP angelegten Gruppen mit dem eigenen Gruppenverzeichnis synchronisieren. Praktisch genügt es also, einen Account einmal im LDAP anzulegen und ihn zum Mitglied in den richtigen Gruppen zu machen, damit er anschließend in Open Shift für die gewünschten Projekte die passenden Berechtigungen hat.

Image Streams und HA

Leichter installieren lassen sich künftig auch verschiedene PaaS-Dienste. Fertige Abbilder bezieht Open Shift bekanntlich aus Image Streams. Und die haben die Entwickler in aktuellen Open-Shift-Versionen gehörig erweitert, sodass sich nun etwa auch Rocket Chat oder WordPress automatisch ausrollen und betreiben lassen (Abbildung 2).

Abbildung 2: In aktuellen Open-Shift-Releases haben die Entwickler besonders die Image Streams erweitert.

So schön die bunte Welt von Cloud-Ready-Applikationen und Stateless Design auch sein mag – elementare Gesetze der IT können auch diese Konzepte nicht überwinden. Kubernetes als Motor von Open Shift kommt mit einigen wenigen Komponenten daher, die im Falle eines Ausfalls zum echten Single Point of Failure werden. Erwähnt sei beispielsweise der Kubernetes-Master: Er betreibt in Form von Etcd den zentralen Key-Value-Speicher, in dem die gesamte relevante Konfiguration der Plattform enthalten ist. Auch zentrale Komponenten wie der Scheduler oder das Kubernetes-API laufen auf dem Masterknoten mit. Kurzum: Fällt der Master aus, hat Kubernetes ein echtes Problem.

Mehrere Ansätze sind denkbar, um die Schwierigkeit in den Griff zu bekommen. Die klassische Methode wäre es, die zentralen Master-Komponenten mit dem Cluster-Manager Pacemaker [5] hochverfügbar zu machen. Das würde dazu führen, dass im Falle des Ausfalls eines Masterknotens die benötigten Dienste auf einem anderen Knoten erneut gestartet werden. In vorherigen Versionen von Open Shift hat Red Hat genau dieses Konzept verfolgt, wohl nicht zuletzt weil der größte Teil der Pacemaker-Entwickler auf der Payroll in Raleigh zu finden ist.

Tatsächlich fährt man bei dieser Lösung aber mit der Kirche ums Kreuz. Denn Kubernetes selbst hat implizite HA-Funktionen. Der Key-Value-Speicher Etcd etwa hat einen eigenen Cluster-Modus und kommt auch bei großen Setups nicht ins Straucheln. Ähnlich verhält es sich mit den anderen Komponenten, die dank der Etcd-Features problemlos auf vielen Hosts gleichzeitig laufen können.

Dass es deutlich sinnvoller ist, diese impliziten HA-Fähigkeiten auch zu nutzen, ist den Open-Shift-Produktentwicklern mittlerweile wohl auch aufgefallen. Aktuellere Open-Shift-Versionen sehen für HA jedenfalls nur noch die native Methode vor, Pacemaker ist aus dieser Gleichung komplett raus.

Mit einer winzigen Einschränkung: Auf jene Komponenten, die zwar zum Setup gehören, aber nicht zu Kubernetes, hat das keinen Einfluss. Wer auf Basis von Pacemaker etwa einen HA-Cluster mit HA-Proxy betreibt, um Lastverteilung auf die verschiedenen Kubernetes-API-Instanzen zu gewährleisten, muss das Setup auch weiterhin mit Pacemaker betreiben. In Kubernetes ist Pacemaker jedoch ein Thema der Vergangenheit.

Vielseitig: Persistenter Speicher

Ähnlich unbeliebt wie das Thema Authentifizierung ist in großen Setups auch das Thema Storage. Gleichwohl: Persistenter Speicher ist eine Anforderung, die in Clouds – und nichts anderes produziert Open Shift ja am Ende – irgendwie erfüllt sein muss. Denn ganz gleich wie gut Setups der Kunden auf den Stateless-Betrieb ausgerichtet sind: Am Ende gibt es immer irgendeinen Punkt, an dem Daten persistent vorzuhalten sind. Selbst eine PaaS-Umgebung mit einer Webshop-Software braucht mindestens eine mit persistentem Speicher versehene Datenbank.

Das Bauen von persistentem Speicher für Clouds ist aber nicht so leicht wie bei konventionellen Setups. Klassische Ansätze versagen, wenn die genutzten Setups bestimmte Größen erreichen. Für skalierbaren Storage existieren mittlerweile etliche Lösungen wie Gluster FS [6] oder Ceph [7], die auf Client-Seite jedoch entsprechenden Support voraussetzen.

Die gute Nachricht für Admins: Beim Thema persistenter Speicher haben die Open-Shift-Entwickler in den vergangenen Monaten massiv nachgelegt. Über das Persistent-Volume-Framework lassen sich PaaS-Instanzen Volumes zuweisen. Und im Backend kann das PV-Framework mittlerweile mit einer Vielzahl verschiedener Lösungen sprechen, darunter neben Gluster FS und Ceph – beide immerhin hausinterne Lösungen von Red Hat – auch mit VMware Vstorage oder dem Klassiker NFS.

Natürlich integrieren sich diese Volumes absolut nahtlos in Open Shift: Hat der Admin das jeweilige Storage-Backend konfiguriert, weisen die Nutzer sich entsprechende Storage-Volumes im Rahmen der Quotas einfach selbst zu. Im Hintergrund betreibt Open Shift die Container danach mit der passenden korrekten Pod-Definition von Kubernetes.

Load Balancer und Router

Eine Herausforderung, mit der sich schon die Virtualisierungslösung und Cloudsoftware Open Stack regelmäßig herumschlagen musste, ist das Einbinden externer Appliances in die Cloud. Etwa Firewalls oder ganz klassische Load Balancer von Palo Alto oder F5 [8]. Weil Open Shift eine Cloud baut und dabei Software Defined Networking zumindest ansatzweise nutzt, steht es an dieser Stelle vor einem echten Problem: Die physische Appliance ist irgendwie in das virtuelle Netz des Kunden zu integrieren, das im Underlay aber gar nicht zu sehen ist.

Am Beispiel von F5 hat Red Hat in Open Shift nun unter Beweis gestellt, dass sich externe Appliances durchaus in SDN integrieren lassen. Wer also eine F5 mit BIG-IP in der Version 11.6 oder höher hat, kann sie nicht nur als externe Firewall in Open Shift nutzen, sondern sie auch direkt im Netz seiner Container verwenden – als Router.

In erster Linie interessant ist das Angebot freilich für Unternehmen, die eine eigene Open-Shift-Installation betreiben oder solche Setups für Kunden aufbauen – dass Red Hat seinen eigenen Kunden solche Sonderwünsche etwa auch in der öffentlichen Open-Shift-Cloud erfüllt, darf bezweifelt werden. Wer jedoch eine private Open-Shift-Installation hochzieht und ohnehin F5 verwendet, findet in der Kombination der beiden Technologien eine elegantere Lösung für Routing und Load Balancing, als sie mit Open-Shift-Bordmitteln zu erreichen ist.

Und natürlich richtet sich das Angebot auch an jene Unternehmen, die aus Gründen der Compliance externe Router oder Load Balancer verwenden müssen und in dieser Hinsicht auf F5 festgelegt sind. Dank der neuen Funktionen, die erstmals in Open Shift 3.1 vollständig zur Verfügung standen, eröffnet sich für eben jene nun überhaupt die Chance auf Open Shift.

Multicast für Pods

Eine ebenfalls bahnbrechende Neuerung, zumindest für viele Anwendungen, ist die Tatsache, dass Kubernetes zwischen vielen Pods nun auch Multicast abwickeln kann. Bisher war das nicht möglich, Multicast-Verkehr ließ sich an der Quelle zwar absetzen, an den Grenzen eines Pod war jedoch Schluss, weshalb der Multicast-Traffic sein Ziel nie erreichen konnte.

Multicast-Traffic steht gerade bei Netzwerk-Admins ohnehin nicht sehr hoch im Kurs – viele winken entnervt ab, wenn die Sprache nur auf das Thema kommt. Das ändert nichts daran, dass sich manche Software nur mit Multicast betreiben lässt, etwa dann, wenn es um Service Discovery oder um den Austausch von größeren Datenmengen zwischen vielen Clients geht.

Aktuelle Versionen von Open Shift bieten solchen Applikationen erstmals ein Zuhause: In der aktuellen Version 3.6 ist das Feature keine Technology Preview mehr, sondern darf offiziell in Produktions-Setups genutzt werden. Pro Projekt lässt sich Multicast nun aktivieren.

Großer Beliebtheit bei der Open-Stack-Usergemeinde erfreuen sich die bei Open Stack verfügbaren Security Groups.

Network Policies für mehr Sicherheit

Vereinfacht ausgedrückt bietet die Cloudsoftware unter diesem Namen einen auf IPtables basierten Weg, den Zugriff auf einzelne VMs zu beschränken. Die Default Security Group etwa lässt Traffic zur Außenwelt zu, erlaubt aber keinen eingehen Traffic. Open Shift hatte ein mit Security Groups vergleichbares Feature bisher nicht im Programm. Zwar liefert Kubernetes selbst ein Network Policy Flag als mögliches Objekt für Pod-Definitionen mit, in Open Shift blieb dies bis zur Version 3.5 allerdings unbeachtet und unbenutzt.

In Open Shift 3.5 liefern die Entwickler das Feature zumindest teilweise nach. Zwar ist es dort noch als Technology Preview markiert und funktioniert nur in Setups, die auf Open Vswitch basieren, dort ist der angebotene Funktionsumfang dann allerdings beachtlich. In der Tat bildet die Network Policy bei Kubernetes nach, was Security Groups in Open Stack seit Jahren können. Aktiviert der Admin das Flag für einen Pod, blockiert dieser automatisch allen eingehenden Traffic bis auf die explizit vom Admin definierten Ausnahmen.

Bis Open Shift die Network Policy ganz unterstützt und offiziell für den produktiven Einsatz freigibt, dürfte wohl noch etwas Zeit vergehen. Ein Anfang ist jedoch gemacht, und gerade wer aus Compliance-Gründen entsprechende Paketfilter braucht, freut sich über die neuen Möglichkeiten.

Liebe zum Detail: Das GUI

Das selbst gebaute GUI ist nach Ansicht von Red Hat so etwas wie das Hauptverkaufsargument für Open Shift. Kein Wunder: Kubernetes selbst kommt ganz ohne grafische Oberfläche und dokumentiert einmal mehr, dass die tollste Software nicht weiterhilft, wenn die Einstiegshürden extrem hoch sind. Bei Red Hat hingegen steht leichtfüßige und unkomplizierte Administration ganz weit oben auf der Featureliste. Ganz gleich ob Admin, Kunde oder Developer: Alle sollen das Open-Shift-GUI als echte Erleichterung im Alltag wahrnehmen.

Entsprechend umfassend sind die Änderungen, die das GUI immer und immer wieder erfährt. Fast die Hälfte der Changelogs zu den Vorversionen ist mit GUI-Änderungen gespickt. Das geht schon beim Login los: Wer möchte, der kann seiner Open-Shift-Installation nun eine gebrandete Seite voranstellen, damit sich einloggende Nutzer nicht durch die generische Open-Shift-Oberfläche bei der Oauth-Anmeldung abgeschreckt werden.

Wer erst mal eingeloggt ist, stößt an allen Ecken und Enden auf UI-Neuerungen. Red Hat hat etwa an vielen Stellen Suchfilter eingebaut, mit denen sich der Inhalt langer Listen viel besser als zuvor prüfen lässt. Die Suchmaske reagiert bereits, während der Benutzer Text eingibt: Will er etwa den Pod Apache sehen, taucht dieser schon auf, wenn er nur »Apa« ins Feld eingibt. Das ist ausgesprochen nützlich.

Noch nützlicher ist das eigene GUI, das Red Hat für die Docker-Registry gebaut hat, die fix zu Open Shift gehört. Zur Erinnerung: Will der Admin auf einem Host einen Kubernetes-Pod aus Docker-Containern starten, gibt er in der Pod-Definition auch das Docker-Image an, das er als Basis nutzen möchte. In der Default-Konfiguration holt Docker sich die Images beim Docker-Hub ab und betreibt sie anschließend lokal.

Bei Kubernetes funktioniert das so nicht: Teil des gesamten Konzepts ist schließlich, dass man passende PaaS-Container gleich in Open Shift baut und in den produktiven Betrieb übernimmt. Dazu ist es jedoch nötig, dass die lokalen Docker-Instanzen mit einer lokalen Registry kommunizieren können, in der die gebauten Abbilder hinterlegt sind. Und eben solch eine Registry gehört bei Open Shift zum Lieferumfang.

In den ersten Releases des 3er Zweigs von Open Shift kam die Registry aber komplett ohne GUI daher. Wollte der Admin etwa wissen, welche Images dort hinterlegt waren, musste er auf die Kommandozeile – wo er womöglich mit einer elend langen Image-Liste konfrontiert war, die er händisch sortieren musste. Die Zeiten sind nun vorbei: Im Open-Shift-GUI hat die Registry nun eine eigene Seite, die bereits beschriebenen Suchfelder inbegriffen. Jedes in der Registry hinterlegt Abbild lässt sich einzeln begutachten, außerdem zeigt das GUI auch zusätzliche Details zu den Abbildern an (Abbildung 3). Insgesamt gilt: Beim Open-Shift-GUI hat sich sehr viel getan, sodass es nun deutlich komfortabler nutzbar ist als zuvor.

Abbildung 3: Die eingebaute Docker-Registry von Open Shift kommt nun mit einem eigenen GUI daher, das den Zugriff deutlich komfortabler möglich macht.

Das Bundle mit Cloud Forms

Ein Ideal von Software-Anbietern ist, dass sich verschiedene Umgebungen komfortabel unter einer Oberfläche verwalten lassen. Red Hat hat wenigstens zwei Kandidaten im Portfolio, bei denen der Wunsch danach durchaus aufkommen könnte: Open Shift und Cloud Forms.

Konsequent bietet Red Hat seit Open Shift 3.1 die Option an, Cloud Forms so in Open Shift zu integrieren, dass es seine Dienste auf Open Shift als Pods ausrollt. Ein einziges Management-GUI hat man dann zwar nicht, denn Cloud Forms kommt mit einem komfortablen eigenen GUI daher. Die Kombination aus Cloud Forms und Open Shift ist aber dennoch sinnvoll, weil beide Komponenten gut harmonieren (Abbildung 4).

Abbildung 4: Cloud Forms und Open Shift lassen sich künftig so betreiben, dass Cloud Forms Container in Open Shift startet.

Open Shift und Jenkins

Eine Hauptmotivation für die Nutzung von Open Shift ist, dass der Anwender die eigene Container-Infrastruktur auf ein solides Fundament aus Continuous Integration und Continuous Delivery stellt (CI, CD). Damit das klappt, haben die Open-Shift-Entwickler ihre Software über ein separates Plugin mit dem CI/CD-Werkzeug Jenkins verbunden und gleichzeitig die Build Pipelines eingeführt.

Die Idee dahinter: Nutzer entwickeln ihre Container in Form von Git-Verzeichnissen oder verwalten zumindest die Docker-Files darin. Checkt der Entwickler eine Änderung für einen Container ein, setzt Jenkins automatisch den Neubau des Docker-Image an und lädt das fertige Image in die Registry hoch.

Funktionschecks erfolgen ebenfalls komplett automatisch. Eine Build Pipeline kann aus beliebig vielen Schritten bestehen, die der Admin frei definiert. Für Image-Entwickler ist das Feature also ausgesprochen nützlich (Abbildung 5).

Abbildung 5: Pipelines versprechen ein besseres CI/CD für Container-Images.

Was es kostet

Bleibt die Frage, was Red Hat für das Produkt haben möchte. Für die Online-Version ist das noch eine leicht zu beantwortende Frage: Das Starter-Paket mit einem Projekt, 1 GByte Arbeitsspeicher und 1 GByte Storage gibt es kostenlos. Mit mindestens 50 US-Dollar pro Monat schlägt der Pro-Plan zu Buche, der ab Werk mehr Speicher, CPU und Storage bietet und sich zudem nach Bedarf jederzeit erweitern lässt. Details zu den Kosten finden sich unter [9].

Die Preise für eine Dedicated-Umgebung gibt Red Hat weiterhin mit mindestens 48000 US-Dollar pro Jahr an, wobei sich verschiedene Ressourcen gegen Aufpreis hinzubuchen lassen. Die Preise für On-Premise-Installationen rückt Red Hat noch immer nur in Form eines konkreten Angebots heraus.

Fazit

Open Shift von Red Hat entwickelt sich mit großen Schritten weiter. Wer jetzt in die Kubernetes-Welt einsteigen möchte und nur wenig oder keine Vorerfahrung hat, der ist mit dem Produkt gut bedient: Die Einstiegshürden sind erfreulich niedrig – und dennoch steht schon nach kurzer Zeit eine Kubernetes-Plattform zur Verfügung.

Das GUI ist ein echter Mehrwert für Admins, Nutzer und Entwickler: Es füllt die Lücke, die in Kubernetes klafft, und zwar auf erfreuliche Art und Weise. Dennoch haben erfahrene Konsolen-Jockeys aber auch weiterhin die Möglichkeit, ihre Umgebung von der Kommandozeile aus zu steuern.

Viele Funktionen, die die Entwickler in den vergangenen Monaten eingebaut haben, sind sehr hilfreich, zum Beispiel der F5-Support. Auf die nächsten Neuerungen darf man gespannt sein.