10 Gründe für OpenShift. Ein Vergleich mit Kubernetes

Grafik: Kubernetes und OpenShift

Plain Kubernetes

oder
Enterprise-ready
OpenShift?

Kubernetes (K8s) oder doch lieber OpenShift? 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.

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

Beim Aufsetzen eines Kubernetes-Clusters empfiehlt es sich also, auf ein wohl abgestimmtes Gesamtpaket zurückzugreifen! Die 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 oder im eigenen Rechenzentrum. Also "K8S the easy way"!

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 wird die Installation durch die Installer Provisioned Infrastructure (IPI) Methodik extrem vereinfacht. Diese steht aktuell für sehr viele Plattformen zur Verfügung, sogar für klassische Bare Metal Installationen. Spezielle und angepasste Installationen lassen sich nach wie vor mit der UPI (User Provisioned Infrastructure) Installationsmethode realisieren.

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. 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.

III. On Premise- und Disconnected-Installation verspricht volle Datenhoheit

Ein sehr wichtiger Aspekt ist die Frage der Datenhoheit. Wer die volle Kontrolle über die eigenen Daten behalten möchte, kann 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. Mit OpenShift als Enterprise-Container-Plattform ist ein solches Setup einer der Hauptanwendungsfälle und mit einer OpenShift Disconnected Installation bleiben Ihre Daten sicher und vollständig im eigenen Rechenzentrum. Das bedeutet: Maximale Kontrolle und Schutz Ihrer sensiblen Informationen.

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 & Observability

Bei der Transformation in eine cloud-native Anwendung zerteilt sich eine klassische monolithische Anwendung in eine Vielzahl parallel laufender Container. Sowohl die Zahl der Container, als auch die potenziell flüchtige Natur der Container machen eine umfassende Observability (zentrales Logging, Monitoring, Tracing etc.) unerlässlich, um den Zustand und das Verhalten eines Systems durch Log-Dateien, Metriken und Traces besser zu verstehen. OpenShift bietet dafür fertige und in die Plattform integrierte Lösungen: 

  • Logging (Loki/Vector, Elastic/Fluentd)
  • Monitoring (Prometheus/Alertmanager)
  • Distributed Tracing (Jaeger/Tempo)
  • Telemetrie (OpenTelemetry)
  • Network Observability (NetObserv)
  • Power Monitoring (Kepler) 

Hierdurch können in komplexen und verteilten Architekturen Probleme schneller erkannt und analysiert werden.

VII. User Experience

Kubernetes besitzt eine graphische, webbasierte 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 OpenShift Pipelines (basierend auf Tekton) ermöglicht es, cloud-native 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.
Zusätzlich gibt es noch OpenShift GitOps (basierend auf ArgoCD), um den Ansatz "everything as code" umsetzen/nutzen zu können.

Beides sind integrierte Produkte in OpenShift - es entstehen also keine Zusatzkosten und Sie profitieren vom Support durch Red Hat.

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.

OpenShift Dev Spaces, 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. Dabei haben Entwickler die freie Wahl, welche web-basierten IDEs sie in ihrer Cloud-Entwicklungsumgebung nutzen wollen: Microsoft Visual Studio Code oder JetBrains IntelliJ IDEA.

Den umgekehrten Weg geht OpenShift Local. 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. Integriertes OS für reduzierte Betriebsaufwände

Mit Red Hat OpenShift erhalten Sie Red Hat CoreOS, ein speziell für Container optimiertes Betriebssystem, das nahtlos in die Plattform integriert ist. Es ist also keine separate Wartung oder Pflege des Betriebssystems erforderlich.
Das bedeutet: Weniger Komplexität und keine OS-Betriebsaufwände, da diese vollständig in der Plattform abstrahiert sind. So erfolgen z.B. Betriebssystem-Updates automatisch mit einem OpenShift-Update.

X. Erweiterbarkeit: Smooth & ohne Kompromisse

Um Mehrwerte zu schaffen, lässt sich die OpenShift Container Plattform als solide Basis problemlos erweitern. Dafür stehen integrierte, abgestimmte und supportete Lösungen zur Verfügung, so. z.B.:

  • Red Hat OpenShift Virtualization: Virtuelle Maschinen nahtlos auf OpenShift betreiben
  • Red Hat Advanced Cluster Management (RH ACM): Effiziente Cluster-Verwaltung, richtlinienbasierte Compliance/Governance, zentrale Deployment-Verwaltung und mehr
  • Red Hat Advanced Cluster Security (RH ACS): Starke Sicherheitslösungen für Container-Workloads (build and run)
  • Red Hat OpenShift AI (RHOAI): k8s-native AI- und MLops-Plattform für Ihre AI/ML-Usecases
  • Red Hat OpenShift Data Foundation (RH ODF): Integrierte Storage-Lösung für skalierbare Datenanforderungen

Der Vorteil: Alle Lösungen stammen aus einer Hand vom Hersteller Red Hat und sind optimal aufeinander abgestimmt, was eine reibungslose Integration ohne "selbstgestrickte Workarounds" ermöglicht.

OpenShift Consulting. Unser Baukasten für Ihren Erfolg.

Mehr erfahren

Plain Kubernetes oder Enterprise-ready OpenShift - noch Fragen?

Foto: Andreas Schilz

Lassen Sie uns sprechen!

Andreas Schilz

# Red Hat
# Cloud
# Platform Engineering
+49-211-339903-86
Durch Absenden des Formulars stimmen Sie unserer Datenschutzerklärung zu.
+49-89-45841-100