Get best of the week

Was ist neu in Red Hat OpenShift 4.2 und 4.3?


Die vierte Version von OpenShift wurde vor relativ kurzer Zeit veröffentlicht. Die aktuelle Version 4.3 ist ab Ende Januar verfügbar und alle Änderungen sind entweder etwas völlig Neues, das nicht in der dritten Version enthalten war, oder ein umfangreiches Update von Version 4.1. Alles, was wir Ihnen jetzt sagen werden, müssen Sie kennen, verstehen und berücksichtigen, die mit OpenShift arbeiten und ein Upgrade auf die neue Version planen.

Mit der Veröffentlichung von OpenShift 4.2 hat Red Hat Kubernetes vereinfacht. Neue Tools und Plugins zum Erstellen von Containern, CI / CD-Pipelines und serverlosen Bereitstellungen wurden veröffentlicht. Innovationen geben Entwicklern die Möglichkeit, sich auf das Schreiben von Code zu konzentrieren, anstatt sich mit Kubernetes zu streiten.

Was ist eigentlich neu in den Versionen von OpenShift 4.2 und 4.3?

Bewegen Sie sich in Richtung Hybridwolken


Bei der Planung einer neuen IT-Infrastruktur oder der Entwicklung einer vorhandenen IT-Landschaft berücksichtigen Unternehmen zunehmend den Cloud-Ansatz bei der Bereitstellung von IT-Ressourcen, für die sie Private Cloud-Lösungen implementieren, oder nutzen die Leistung öffentlicher Cloud-Anbieter. Daher werden moderne IT-Infrastrukturen zunehmend auf einem „hybriden“ Cloud-Modell aufgebaut, wenn sowohl lokale Ressourcen als auch öffentliche Cloud-Ressourcen mit einem gemeinsamen Managementsystem verwendet werden. Red Hat OpenShift 4.2 wurde speziell entwickelt, um den Übergang zu einem Hybrid-Cloud-Modell zu vereinfachen und die Verbindung der Ressourcen von Anbietern wie AWS, Azure und der Google Cloud Platform mit dem Cluster zusammen mit privaten Clouds auf VMware und OpenStack zu vereinfachen.

Neuer Installationsansatz


In Version 4 hat sich der Ansatz zur Installation von OpenShift geändert. Red Hat bietet ein spezielles Dienstprogramm zum Bereitstellen eines OpenShift-Clusters - openshift-install. Das Dienstprogramm ist die einzige in Go geschriebene Binärdatei. Openshit-Installer bereitet eine Yaml-Datei mit der für die Bereitstellung erforderlichen Konfiguration vor.

Bei der Installation mit Cloud-Ressourcen müssen Sie die Mindestinformationen zum zukünftigen Cluster angeben: DNS-Zone, Anzahl der Arbeitsknoten, spezifische Einstellungen für den Cloud-Anbieter, Kontoinformationen für den Zugriff auf den Cloud-Anbieter. Nach dem Vorbereiten der Konfigurationsdatei kann der Cluster mit einem Befehl bereitgestellt werden.

Wenn Sie auf Ihren eigenen Computerressourcen installieren, z. B. wenn Sie eine private Cloud verwenden (vSphere und OpenStack werden unterstützt) oder wenn Sie auf Bare-Metal-Servern installieren, müssen Sie die Infrastruktur manuell konfigurieren. Bereiten Sie die Mindestanzahl an virtuellen Maschinen oder physischen Servern vor, die zum Erstellen eines Control Plane-Clusters erforderlich sind Netzwerkdienste. Nach dieser Konfiguration kann der OpenShift-Cluster auf ähnliche Weise mit einem Befehl des Dienstprogramms openshift-installer erstellt werden.

Infrastruktur-Updates


Integration mit CoreOS


Ein wichtiges Update ist die Integration in Red Hat CoreOS. Jetzt können Red Hat OpenShift-Masterknoten nur unter dem neuen Betriebssystem funktionieren . Dies ist ein kostenloses Betriebssystem von Red Hat, das speziell für Containerlösungen entwickelt wurde. Red Hat CoreOS ist ein leichtes Linux, das für die Ausführung von Containern optimiert ist.

Wenn in 3.11 das Betriebssystem und OpenShift getrennt existierten, ist es in 4.2 untrennbar mit OpenShift verbunden. Dies ist eine einzige Appliance - unveränderliche Infrastruktur.


Für Cluster, die RHCOS für alle Knoten verwenden, ist die Aktualisierung der OpenShift Container Platform ein einfacher und gut automatisierter Prozess.

Zuvor war es zum Aktualisieren von OpenShift zunächst erforderlich, das zugrunde liegende Betriebssystem zu aktualisieren, auf dem das Produkt ausgeführt wurde (zu diesem Zeitpunkt war es Red Hat Enterprise Linux). Erst danach war es möglich, OpenShift Knoten für Knoten schrittweise zu aktualisieren. Es wurde nicht über eine Automatisierung des Prozesses gesprochen.

Da die OpenShift Container Platform nun die Systeme und Dienste auf jedem Knoten, einschließlich des Betriebssystems, vollständig steuert, wird diese Aufgabe durch Drücken einer Taste auf der Weboberfläche gelöst. Danach wird im OpenShift-Cluster ein spezieller Operator gestartet, der den gesamten Aktualisierungsprozess steuert.

Neuer CSI


Das zweite ist das neue CSI, der Speicherschnittstellen-Controller, mit dem Sie verschiedene externe Speichersysteme mit dem OpenShift-Cluster verbinden können. Eine große Anzahl von Speichertreiberanbietern für OpenShift wird basierend auf den Speichertreibern unterstützt, die von den Speicheranbietern selbst geschrieben wurden. Eine vollständige Liste der unterstützten CSI-Treiber finden Sie in diesem Dokument: https://kubernetes-csi.imtqy.com/docs/drivers.html . In dieser Liste finden Sie alle Hauptmodelle von Festplatten-Arrays führender Hersteller (Dell / EMC, IBM, NetApp, Hitachi, HPE, PureStorage), SDS-Lösungen (Ceph) und Cloud-Speicher (AWS, Azure, Google). OpenShift 4.2 unterstützt die Arbeit mit CSI-Treibern der CSI-Spezifikation Version 1.1.

RedHat OpenShift Service Mesh


Basierend auf den Projekten Istio, Kiali und Jaeger - Red Hat OpenShift Service Mesh - können Sie diese zusätzlich zu den üblichen Aufgaben zum Weiterleiten von Anforderungen zwischen Diensten verfolgen und visualisieren. Dies hilft Entwicklern, die Interaktion, Überwachung und Verwaltung von Anwendungen zu vereinfachen, die in Red Hat OpenShift bereitgestellt werden.


Visualisierung einer Anwendung mit einer Microservice-Architektur mit Kiali

Um die Installation, den Service und das Lebenszyklusmanagement von Service Mesh zu vereinfachen, bietet Red Hat OpenShift Administratoren einen speziellen Operator - Service Mesh Operator. Dies ist der Kubernetes-Operator, mit dem Sie die neu konfigurierten Istio-, Kiali- und Jaeger-Pakete im Cluster bereitstellen können, um den Verwaltungsaufwand für die Verwaltung von Anwendungen zu minimieren.

CRI-O anstelle von Docker


Der Standard-Container-Laufzeit-Docker wurde durch CRI-O ersetzt. CRI-O konnte bereits in Version 3.11 verwendet werden, wurde jedoch in 4.2 zur Hauptversion. Nicht gut und nicht schlecht, aber bei der Verwendung des Produkts zu beachten.

Operatoren und Bereitstellungsanwendungen


Operatoren - eine neue Entität für RedHat OpenShift, die in der vierten Version veröffentlicht wurde. Dies ist eine Methode zum Packen, Bereitstellen und Verwalten der Kubernetes-Anwendung. Es kann sich als Plugin für Anwendungen vorstellen, die in Containern bereitgestellt werden, die mit der Kubernetes-API und den kubectl-Tools verwaltet werden.

Kubernetes-Operatoren helfen bei der Automatisierung aller Aufgaben im Zusammenhang mit der Verwaltung und Verwaltung des Lebenszyklus einer Anwendung, die Sie in Ihrem Cluster bereitstellen. Ein Bediener kann beispielsweise Aktualisierungen automatisieren, eine Anwendung sichern und skalieren, die Konfiguration ändern usw. Eine vollständige Liste der Betreiber finden Sie unter https://operatorhub.io/ .

OperatorHub ist direkt über die Weboberfläche der Verwaltungskonsole verfügbar. Es ist ein Anwendungskatalog für OpenShift, der von Red Hat verwaltet wird. Jene. Alle von Red Hat zugelassenen Betreiber werden vom Anbietersupport abgedeckt.


OperatorHub Portal in der OpenShift Management Console

Universelles Basisbild


Dies ist ein standardisierter Satz von RHEL OS-Images, mit denen Sie Ihre Anwendungen in Containern erstellen können. Es gibt minimale, Standard- und Komplettsets. Sie nehmen sehr wenig Platz ein und unterstützen alle erforderlichen installierten Pakete und Programmiersprachen.

CI / CD-Tools


RedHat OpenShif 4.2 bietet die Möglichkeit, basierend auf Tekton Pipelines zwischen Jenkins und OpenShift Pipelines zu wählen.

OpenShift Pipelines basiert auf Tekton, das von der Pipeline besser unterstützt wird, wenn sich Code und GitOps nähern. In OpenShift-Pipelines wird jeder Schritt in einem eigenen Container ausgeführt, sodass Ressourcen nur während der Ausführung des Schritts verwendet werden. Dies gibt Entwicklern die vollständige Kontrolle über die Modullieferungs-Pipelines, Plug-Ins und die Zugriffskontrolle ohne einen zentralen CI / CD-Server für die Verwaltung.

OpenShift Pipelines befindet sich derzeit in der Vorschau für Entwickler und ist als Operator im OpenShift 4-Cluster verfügbar. Natürlich können OpenShift-Benutzer Jenkins weiterhin in RedHat OpenShift 4 verwenden.

Management-Updates für Entwickler


In 4.2 hat OpenShift die Weboberfläche für Entwickler und Administratoren vollständig aktualisiert.

In früheren Versionen von OpenShift arbeiteten alle in drei Konsolen: einem Servicekatalog, einer Administratorkonsole und einer Arbeitskonsole. Jetzt ist der Cluster nur noch in zwei Teile unterteilt - Administratorkonsole und Entwicklerkonsole.

Die Entwicklerkonsole wurde erheblich verbessert. Jetzt ist es bequemer, Topologien von Anwendungen und deren Baugruppen anzuzeigen. Dies erleichtert Entwicklern das Erstellen, Bereitstellen und Visualisieren von Containeranwendungen und Clusterressourcen. Ermöglicht es Ihnen, sich auf das zu konzentrieren, was für sie wichtig ist.


Entwicklerportal in der OpenShift Management Console

Odo


Odo ist ein entwicklerorientiertes Befehlszeilenprogramm, das die Anwendungsentwicklung in OpenShift vereinfacht. Mithilfe der Interaktion im Git-Push-Stil hilft diese CLI Entwicklern, die neu in Kubernetes sind, Anwendungen in OpenShift zu erstellen.

Integration in Entwicklungsumgebungen


Entwickler können jetzt ihre Anwendungen in OpenShift erstellen, debuggen und bereitstellen, ohne ihre bevorzugte Codeentwicklungsumgebung wie Microsoft Visual Studio, JetBrains (einschließlich IntelliJ), Eclipse Desktop usw. zu verlassen.

Red Hat OpenShift-Bereitstellungserweiterung für Microsoft Azure DevOps


Die Red Hat OpenShift-Bereitstellungserweiterung für Microsoft Azure DevOps wurde angezeigt. Jetzt können Benutzer dieses DevOps-Toolkits ihre Anwendungen direkt über Microsoft Azure DevOps in Azure Red Hat OpenShift oder einem anderen OpenShift-Cluster bereitstellen.

Übergang von der dritten zur vierten Version


Da es sich um eine neue Version handelt, nicht um ein Update, ist es nicht so einfach, die vierte Version auf die dritte zu setzen. Das Aktualisieren von der dritten auf die vierte Version wird nicht unterstützt .

Aber es gibt gute Nachrichten: Red Hat bietet Tools zum Verschieben von Projekten von 3.7 auf 4.2. Sie können Anwendungs-Workloads mit dem CAM-Tool (Cluster Application Migration) übertragen. Mit CAM können Sie die Migration steuern und Ausfallzeiten von Anwendungen minimieren.

OpenShift 4.3


Die in diesem Artikel beschriebenen Hauptinnovationen wurden in Version 4.2 veröffentlicht. In der kürzlich veröffentlichten Version 4.3 sind die Änderungen nicht so bedeutend, aber es gibt noch etwas Neues. Die Liste der Änderungen ist recht umfangreich, wir geben unserer Meinung nach die wichtigsten an:

Aktualisieren Sie die Kubernetes-Version auf 1.16.


Die Version wurde sofort auf zwei Schritte aktualisiert, in OpenShift 4.2 war es 1.14.

Datenverschlüsselung in etcd


Ab Version 4.3 war es möglich, Daten in der etcd-Datenbank zu verschlüsseln. Nachdem die Verschlüsselung aktiviert wurde, können die folgenden OpenShift-API- und Kubernetes-API-Ressourcen verschlüsselt werden: Geheimnisse, ConfigMaps, Routen, Zugriffstoken und OAuth-Autorisierung.

Helm


Unterstützung für Helm 3rd Version hinzugefügt - ein beliebter Paketmanager für Kubernetes. Bisher hat die Unterstützung den Status TECHNOLOGY PREVIEW. In zukünftigen Versionen von OpenShift wird die Helmunterstützung vollständig erweitert. Das Dienstprogramm helm cli wird mit OpenShift geliefert und kann von der Cluster Management-Webkonsole heruntergeladen werden.

Projekt-Dashboard-Update


In der neuen Version von Project Dashboard finden Sie zusätzliche Informationen auf der Projektseite: Projektstatus, Ressourcennutzung und Kontingente für das Projekt.

Zeigen Sie Schwachstellen für den Kai in der Webkonsole an


Die Funktion zum Anzeigen bekannter Schwachstellen für Bilder in Quay-Repositorys zur Verwaltungskonsole wurde hinzugefügt. Die Sicherheitsanfälligkeitszuordnung für lokale und externe Repositorys wird unterstützt.

Vereinfachte Offline-Operatorhub-Erstellung


Für die Bereitstellung eines OpenShift-Clusters in einem isolierten Netzwerk, in dem der Internetzugang eingeschränkt ist oder fehlt, wird die Erstellung eines „Spiegels“ für die OperatorHub-Registrierung vereinfacht. Dies kann jetzt mit nur drei Teams durchgeführt werden.

Verfasser: Yuri Semenyukov

More articles:


All Articles