OpenShift Kubernetes Vergleich: 10 Gründe für OpenShift

Beim Update eines Kubernetes-Clusters müssen Zusätze und Plugins einzeln aktualisiert werden. Dabei ist keineswegs garantiert, dass alle Versionen zueinander kompatibel sind. OpenShift bietet einen zentralen Update-Mechanismus inkl. Upgrade-Pfade für die gesamte Plattform. Hierbei wird auch die Integrität aller Komponenten sichergestellt. Die Update-Logik wurde dahingehend verbessert, dass die verschiedenen Services und Komponenten in die entsprechenden Operatoren verschoben wurden. Bei Operatoren handelt es sich um Software, die operatives Wissen beherrscht, um einen hohen Automatisierungsgrad anzustreben.

Ein sehr wichtiger Aspekt ist die Frage der Datenhoheit. Wer die volle Kontrolle über seine Daten behalten möchte, wird seinen Cluster in den eigenen Räumlichkeiten auf physischen Rechnern (Bare Metal) oder virtuellen Maschinen betreiben. Das Aufsetzen eines Kubernetes-Clusters auf dieser Basis ist (wie bereits weiter oben beschrieben) eine Herausforderung. Für OpenShift mit seiner Positionierung als Enterprise-Container-Plattform ist ein solches Setup einer der Hauptanwendungsfälle.

Möchte man in Kubernetes eine Applikation oder einen Dienst ausrollen, den man nicht selbst entwickelt hat, greift man üblicherweise auf eine der zahlreichen Image Registries im Internet zurück und lädt von dort das gewünschte Image herunter. Dabei muss man gezwungenermaßen dem Betreiber der Image Registry und dem Schöpfer des Images vertrauen. Mit OpenShift hat man Zugriff auf eine von Red Hat kuratierte Image Registry. Alle Images dort werden immer auf dem neuesten Stand gehalten. Des Weiteren werden die Images kontinuierlich auf bekannte Schwächen überprüft und ggf. werden schnell neue, fehlerbereinigte Versionen bereitgestellt. Diese Registry bietet einen umfangreichen Satz an Images für allerlei Dienste (Datenbanken, Middleware, Builder, Laufzeitumgebungen).

Operatoren sind ein zunehmend populäres Konzept, um Infrastruktur und Applikationen für einen Kubernetes-Cluster mit einem hohen Automatisierungsgrad bereitzustellen. Dies umfasst Installation, Upgrade, Skalierung, Backup/Restore und das gesamte Lifecycle-Management. Die OpenShift Web-Konsole bietet hierfür den Operator-Hub, einen Katalog von Operatoren kuratiert von Red Hat. Operatoren können installiert werden und bieten ihre Möglichkeiten dann über den Entwickler-Katalog an, so dass Benutzer einen Dienst oder eine Anwendung, für die ein bestimmter Operator verantwortlich ist, einfach selbst installieren und verwalten können.

Eine klassische monolithische Applikation zerteilt sich bei der Transformation in eine cloud-native Applikation in eine Vielzahl von parallel laufenden Containern. Sowohl die Zahl der Container, als auch die potenziell flüchtige Natur der Container machen ein zentrales Logging und Monitoring unerlässlich. OpenShift kommt bereits mit fertigen Lösungen dafür: Prometheus inkl. Grafana für Monitoring und EFK (ElasticSearch, Fluentd, Kibana) für Logging.

Kubernetes besitzt eine graphische (web-basierte) Oberfläche, das sogenannte Dashboard. Dieses ist allerdings eingeschränkt brauchbar. Zum einen ist die Anmeldung kompliziert (X509-Client-Zertifikat). Zum anderen zeigt das Dashboard nur die existierenden Ressourcen des Kubernetes-Clusters und deren Status. Es sind keine Änderungen möglich (abgesehen vom unkomfortablen und fehleranfälligen Editieren von YAML-Dateien). In OpenShift gibt es die Web-Konsole. Einfacher Login, alle Ressourcen werden angezeigt, Modifikationen sind (meist formular-basiert) möglich, neue Ressourcen können angelegt werden. Auch das Ausrollen neuer Anwendungen oder Dienste ist über den Service-Katalog komfortabel möglich.

Kubernetes bietet keine Mittel, um Images selbst zu bauen. Images werden aus der Registry geladen. Wie sie dorthin gelangen, liegt komplett außerhalb der Verantwortung von Kubernetes. Dem gegenüber stellt OpenShift eine Reihe von Ressourcen bereit, die es Entwicklern ermöglichen, eigene Images innerhalb von OpenShift zu bauen und zu verteilen.

Last but not least gibt es eine dedizierte Entwickler-Konsole, die eine alternative Sicht auf die Ressourcen eines OpenShift-Projekts bietet. In grafisch übersichtlicher Weise werden die Komponenten einer Applikation präsentiert und wie sie miteinander in Beziehung stehen. Erst im zweiten Schritt erfolgt der Zugriff auf die Ressourcen, die die einzelnen Komponenten konstituieren.

Seit der OpenShift Version 4.4 wird mit der OpenShift Container Plattform auch OpenShift Serverless mitgeliefert, welches auf Knative basiert. Damit können Serverless Applications realisiert werden. Es handelt sich dabei um Applikationen, für die Ressourcen nur bei Bedarf alloziert werden. Gehen keine Requests ein, so werden nach kurzer Zeit alle Ressourcen freigegeben (scale-to-zero). Andererseits findet bei Lastspitzen eine automatische Skalierung für die Applikation statt.

Abgerundet wird das Ganze durch Knative Eventing, ein mächtiges Framework, um Anfragen und Events zu steuern: Entweder direkt von „source to sink“ oder über den Weg eines Channels oder Brokers, der Events nach einer festgelegten Logik filtert, bevor sie an die entsprechenden Services weitergeleitet werden.

Moderne, cloud-native Applikationen bestehen aus einer Vielzahl von Microservices, die untereinander kommunizieren. Mit wachsender Anzahl von Microservices (und Instanzen davon) wird das Kommunikationsmanagement unübersichtlich. Red Hat OpenShift Service Mesh ermöglicht es, die Datenströme genau zu beobachten und zu visualisieren. Dies erleichtert die Fehler- und Last-Analyse ungemein. Darüber hinaus lässt sich deklarativ festlegen, wie der Datenverkehr verteilt werden & wie im Fehlerfall oder im Überlastfall reagiert werden soll. Der entsprechende Code muss nicht in die Microservices integriert werden und Entwickler können sich auf den Business-Nutzen konzentrieren.