Anmelden / Registrieren Konto

Als jemand, der schon seit ca. sechs Jahren mit OpenShift arbeitet, wurde ich immer wieder gefragt, was OpenShift eigentlich ist. Mit dem Umstieg auf die Version 3.x von Kubernetes von der vorherigen Architektur hat sich dies von der ursprünglichen Frage dahin entwickelt, was die Unterschiede zwischen OpenShift und Kubernetes sind. Heute möchte ich das etwas genauer beleuchten.

Kubernetes ist der sogenannte „Kernel“

Bei CoreOS haben wir Kubernetes als „Kernel“ der verteilten Systeme angesehen. Wir haben erkannt, dass ein wohldurchdachter Job Scheduler, der auf mehreren Rechnern ausgeführt werden kann und in der Lage ist, den Status verwalteter Workloads abzustimmen, die Kollaboration auf die gleiche natürliche Weise fördern würde wie das der Linux-Kernel für die Planung von Workloads auf einem einzelnen Host getan hat. Dieser Logik folgend war uns bewusst, dass sich Produkte basierend auf den für die jeweiligen Nutzer wichtigen Aspekte differenzieren würden.

Es handelt sich um den gleichen Linux-Kernel, der auch in vielen Handys, Laptops, Servern und selbst Raspberry Pi ausgeführt wird, auch wenn das Patching zur Unterstützung der Hardware variiert, auf dem der Kernel direkt aufsitzt.

In diesem gleichen Modell haben wir es mit dem gleichen Kubernetes in den verschiedenen Distributionen zu tun, wobei das Patching zur Unterstützung der Schicht variiert, auf dem Kubernetes direkt aufsitzt: die Linux-Distributionen, auf dem jede der Kubernetes-Versionen ihre Workloads ausführt.

OpenShift ist die Distribution

Das ist eine überaus wichtige Unterscheidung. Das Entwickler-Team von OpenShift ist stolz darauf, eine Kubernetes-Distribution basierend auf den Erfahrungen von Entwicklern zu produzieren, die die nächste Generation cloudnativer Anwendungen hervorbringen möchten. Das für Tectonic (der CoreOS-Distribution von Kubernetes) verantwortliche Team hat den Fokus auf die Erfahrungen von Admin- und Ops-Teams gelegt, die Probleme mit dem Betriebssystem und Kubernetes zeitnah lösen müssen. Mit der bevorstehenden OpenShift 4.0 Release stellen wir Schnittstellen für beide Zielgruppen bereit, um eine gemeinsame Plattform für diese speziellen Anforderungen anbieten zu können.

Obwohl es jedem freisteht, Linux von Grund auf zu entwickeln – durch die Auswahl der einzelnen Komponenten und deren Kombination in der vom jeweiligen Nutzer gewünschten Weise – entscheiden sich die meisten allerdings dagegen. Anhand der von den meisten Nutzern gewählten Abstraktionsstufe lässt sich ablesen, dass sie der Verwaltung der Unterschiede zwischen Util-Linux Version 2.31 und 2.33 keinen großen Wert beimessen (oder gar Informationen darüber besitzen). Genauer betrachtet, stellt man fest, dass das Hauptanliegen der Nutzer ein Mindestgrad an Funktionalität ist (z. B. zu wissen, welche Befehle/APIs verfügbar sind, solange sie eine Mindest-Versionsnummer wählen). An zweiter Stelle wäre eine Liste der verfügbaren Features.

Dies lässt sich mit OpenShift vergleichen. Wir paketieren Kubernetes und integrieren zusätzliche Tools als Features, die wir für wichtig erachten und die unsere Nutzer fordern. So wie CoreOS und CentOS verschiedene Tool-Sets für unterschiedliche Nutzer enthalten, verhält sich das auch mit Kubernetes-Distributionen. Bei Red Hat haben wir den Fokus darauf gelegt, diejenigen Tools bereitzustellen, die Dev- und Ops-Teams ein erfolgreiches Arbeiten ermöglichen. Dies ist auch der Grund, warum wir in OpenShift jetzt auch Istio als technologische Vorschau bereitstellen. Unserer Meinung nach ist das ein Tool, das den Nutzern gute Dienste leisten kann und deshalb auch als Schlüsselfaktor in der Basisdistribution enthalten sein sollte.

OKD vs Red Hat OpenShift

Noch mal von vorne.

Ist OpenShift eine Open Source Software? Aber sicher! Alle Komponenten von OpenShift werden im Rahmen der Open Source Community entwickelt und können mit GitHub angezeigt werden. Sie finden dort eine große Anzahl an Repositories mit vielen Themen rund um die Einrichtung und kontinuierliche Ausführung von Kubernetes-Clustern.

Wir paketieren die für die Ausführung von Kubernetes notwendigen Softwarekomponenten in einem Projekt. Dieses Projekt ist eine Distribution von Kubernetes namens OKD (früher „Origin“). Kubernetes und OKD ähneln sich, weil sie beide Open Source-Projekte sind, wobei Kubernetes eines von vielen Upstream-Projekten von OKD ist, so wie der Linux-Kernel, GNU Bash, GCC und der Apache httpd Server Upstream-Projekte der Fedora Linux-Distribution sind. Wenn wir Features von OpenShift verbessern oder hinzufügen möchten, tun wir das für Kubernetes „upstream“ und arbeiten bei der Entwicklung von OpenShift mit Kubernetes-Releases.

Red Hat paketiert OKD dann zusammen mit einer Reihe weiterer Projekte wie Maistra, verschiedenen Operatoren und anderen Ressourcen zum Produkt Red Hat OpenShift Container Platform. Nachdem die Kubernetes-Release erstellt wurde, beginnt der Arbeitsschritt zur Paketierung von OKD und später OpenShift.

Das Produkt Red Hat OpenShift baut auf all diesen Elementen auf und wird umfassend getestet, um sicherzustellen, dass alle Komponenten gut integriert und Teams dazu bereit sind, die Anforderungen von Kunden zu erfüllen, die die Software in Produktion ausführen. Diese internen Vorbereitungsarbeiten erklären teilweise die Verzögerung zwischen der Erstellung der Upstream-Version von OpenShift und der Version für Unternehmen. Unsere Kunden wollen von unserer Expertise profitieren und sich darauf verlassen können, dass wir End-to-End-Support für die mit OpenShift gelieferten Komponenten bereitstellen können.

Auf die gleiche Weise, wie Sie Linux von Grund auf entwickeln können, können Sie Kubernetes auch auf „umständliche“ Art und Weise installieren, allerdings sollten Sie solche Verfahren lieber denjenigen Personen überlassen, die über die Zeit und Geduld sowie das Risikoniveau verfügen, für die kein Unternehmenssupport erforderlich ist. Für alle diejenigen, die auf ihre eigenen Anwendungen fokussieren und dabei vom Fachwissen von Red Hat profitieren möchten, empfehlen wir OpenShift Container Platform.