Plain Kubernetes oder Enterprise-ready OpenShift?

10 Vorteile von Red Hat OpenShift bei Container-Entwicklung & -Management

Kubernetes (K8s) ist die de facto Standard-Plattform, wenn es um Container-Orchestrierung geht. Wer eine große Anzahl von Containern betreiben will und dabei zeitgemäße Anforderungen bzgl. Skalierung und Resilienz stellt, kommt am Betrieb eines Kubernetes-Clusters nicht vorbei.

Allerdings bietet Kubernetes an sich nur die Basis-Funktionalität für den Betrieb von Containern und Nodes. Infrastruktur-Komponenten, die für den Betrieb eines Clusters unentbehrlich sind, sind nicht Bestandteil des originären K8s. Dazu zählen unter anderem:

  • Storage (persistenter Datenspeicher)
  • Netzwerk (für die Kommunikation mit den Containern & der Container untereinander)
  • Authentifzierung und Autorisierung (Benutzer- und Rechteverwaltung)

Kubernetes bietet hierfür zwar Schnittstellen an, über die spezialisierte Komponenten angebunden werden können. Doch das Aufsetzen eines Kubernetes-Clusters auf diesem Level bietet zahllose Fallstricke und ist die Domäne von absoluten Experten: K8s the hard way.

10 Gründe für Red Hat OpenShift: K8s the easy way

Beim Aufsetzen eines Kubernetes-Clusters empfiehlt es sich also, auf ein wohl abgestimmtes Gesamtpaket zurückzugreifen! Red Hat OpenShift Container Platform ist eine auf Kubernetes aufsetzende K8s-Distribution. Wir zählen 10 Vorteile der Plattform auf, um damit unternehmenstaugliche (enterprise-ready) Kubernetes-Cluster aufzusetzen und zu betreiben – egal ob in der Public oder in der Private Cloud.

I. Erleichterte Installation
Das Aufsetzen eines Kubernetes-Clusters ist eine anspruchsvolle Aufgabe. Entfernt man sich von den absoluten Standards, landet man schnell bei mühseligen manuellen Nacharbeiten. Mit OpenShift 4 wurde die Installation durch den IPI (Installer Provisioned Infrastructure) Installer extrem vereinfacht. Dieser steht aktuell für viele Plattformen zur Verfügung. Installationen auf klassischen Plattformen, wie Bare Metal, lassen sich über den UPI (User Provisioned Infrastructure) realisieren. Gegenüber OpenShift 3 wurde die Fehleranfälligkeit des Installers minimiert.


II. Cluster-Update
Beim Update eines Kubernetes-Clusters müssen Zusätze und Plugins einzeln aktualisiert werden. Dabei ist keineswegs garantiert, dass alle Versionen zueinander kompatibel sind. Bei OpenShift geht das einfacher (so lange alle Komponenten über den Installer installiert wurden): OpenShift 4 bietet hier sogar noch mehr Sicherheit und Komfort gegenüber OpenShift 3, da die Update-Logik für die verschiedenen Services und Komponenten in die entsprechenden Operatoren verschoben wurde. Bei Operatoren handelt es sich um Software, die operatives Wissen beherrscht, um einen hohen Automatisierungsgrad anzustreben.


III. On Premise-Installation verspricht volle Datenhoheit
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.


IV. Kuratierte Image Registry
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).


V. Operator-Hub
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.


VI. Logging & Monitoring
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.


VII. User Experience
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.


VIII. Developer Experience
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.

Builder Images sind spezielle Images, mit denen neue Images gebaut werden können. Es gibt sie in der Ausprägung Docker-Builds (Images anhand eines Dockerfiles bauen) oder Source-to-Image-Builds (Images komplett aus den Sources einer Anwendung bauen). Letztere werden für viele gängige Programmiersprachen von Red Hat zur Verfügung gestellt.

Die integrierte CI/CD-Lösung Jenkins ermöglicht es, CI/CD-Pipelines zu implementieren, d.h. den kompletten Workflow zu automatisieren: vom Auschecken der Sourcen über Bauen der Artefakte, Code-Analyse, Tests auf verschiedenen Levels bis zum automatischen Deployment der neuen Images. Ganz neu und momentan noch technical preview ist OpenShift Pipelines. OpenShift liefert hier eine Tekton-Integration mit und damit ein modernes, cloud-natives CI/CD-Tool.

Die integrierte Image Registry ist der Ort, an dem die selbst gebauten Images gespeichert werden, bevor sie für das Deployment aktualisierter Container verwendet werden. Die Images (sprich: ihre unternehmenskritische Software) verlassen ihren Cluster nicht.

Für extrem kurze Round-Trip-Zeiten beim Entwickeln steht seit OCP4 das Tool odo zur Verfügung. Artefakte, die auf dem Arbeitsgerät eines Entwicklers gebaut wurden, können damit direkt in einen laufenden Container injiziert und dort sofort ausprobiert werden. Über entsprechende Plugins von Red Hat steht diese Funktionalität auch in den IDEs Eclipse und IntelliJ zur Verfügung.

CodeReady Workspaces, basierend auf Eclipse Che, bringt die Entwickler noch näher an den Ort des Geschehens (sprich die Pods). Es bietet eine Entwicklungs-Umgebung, die auf ihrem OpenShift Cluster läuft und über den Internet-Browser bedient wird. Durch selbst vorkonfigurierte und versionierte Umgebungs-Beschreibungen wie z.B. Programmiersprachen oder Build-Frameworks, kann der Onboarding-Aufwand für Entwickler auf ein Minimum reduziert werden.

Den umgekehrten Weg geht CodeReady Containers. Damit ist es möglich, einen kleinen OpenShift-Cluster lokal auf dem Arbeitsrechner eines Entwicklers zu starten und dort die Arbeitsergebnisse auszuprobieren.

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.


IX. OpenShift Serverless
Seit OpenShift Version 4.4 gilt auch OpenShift Serverless (basierend auf Knative) als allgemein verfügbar (generally available, GA). 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.


X. Service Mesh
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.

Ihr Ansprechpartner

Zisis Lianas

Tel.: +49-89-45841-100