Die vierte Version von OpenShift wurde relativ neu veröffentlicht. Die aktuelle Version 4.3 ist seit Ende Januar verfügbar, und alle Änderungen darin sind entweder völlig neu oder große Aktualisierungen der Funktionen, die in Version 4.1 vorhanden sind. Alles, was wir jetzt besprechen, ist wichtig zu wissen und zu berücksichtigen für alle, die mit OpenShift arbeiten und einen Wechsel zur neuen Version planen.
Mit der Veröffentlichung von OpenShift 4.2 hat Red Hat die Arbeit mit Kubernetes vereinfacht. Neue Werkzeuge und Plugins für die Erstellung von Containern, CI/CD-Pipelines und serverless Bereitstellungen sind hinzugekommen. Die Neuerungen ermöglichen es Entwicklern, sich auf das Programmieren zu konzentrieren, statt sich mit Kubernetes auseinandersetzen zu müssen.
Was genau ist neu in den Versionen OpenShift 4.2 und 4.3?
Bewegung in Richtung hybrider Clouds
Bei der Planung einer neuen IT-Infrastruktur oder der Weiterentwicklung der bestehenden IT-Landschaft ziehen Unternehmen zunehmend einen Cloud-Ansatz in Betracht, um IT-Ressourcen bereitzustellen. Hierfür werden private Cloud-Lösungen implementiert oder die Kapazitäten öffentlicher Cloud-Anbieter genutzt. Infolgedessen werden moderne IT-Infrastrukturen immer häufiger nach einem „Hybrid“-Cloud-Modell aufgebaut, das sowohl On-Premises-Ressourcen als auch öffentliche Cloud-Ressourcen mit einem integrierten Verwaltungssystem kombiniert. Red Hat OpenShift 4.2 wurde speziell entwickelt, um den Übergang zu einem hybriden Cloud-Modell zu erleichtern und ermöglicht die einfache Anbindung von Ressourcen solcher Anbieter wie AWS, Azure und Google Cloud Platform, während gleichzeitig Private Clouds auf VMware und OpenStack genutzt werden.
Neuer Ansatz zur Installation
In der vierten Version hat sich der Ansatz zur Installation von OpenShift geändert. Red Hat stellt ein spezielles Tool zum Deployment des OpenShift-Clusters zur Verfügung – openshift-install. Dieses Tool ist eine einzelne Binärdatei, die in Go geschrieben wurde. Der Openshift-Installer erstellt eine YAML-Datei mit der erforderlichen Konfiguration für das Deployment.
Bei der Installation über Cloud-Ressourcen müssen grundlegende Informationen über den zukünftigen Cluster angegeben werden: DNS-Zone, Anzahl der Worker-Knoten, spezifische Einstellungen für den Cloud-Anbieter sowie Zugangsdaten für den Cloud-Anbieter. Nach der Erstellung der Konfigurationsdatei kann der Cluster mit einem einzigen Befehl bereitgestellt werden.
Bei der Installation auf eigenen Rechenressourcen, zum Beispiel beim Einsatz von Private Cloud (vSphere und OpenStack werden unterstützt) oder bei der Installation auf Bare-Metal-Servern, ist eine manuelle Einrichtung der Infrastruktur erforderlich – es müssen mindestens die notwendigen virtuellen Maschinen oder physischen Server vorbereitet werden, um den Control Plane Cluster zu erstellen und Netzwerksdienste zu konfigurieren. Nach dieser Konfiguration kann der OpenShift-Cluster ebenfalls mit einem einzigen Befehl des Tools openshift-installer erstellt werden.
Updates in der Infrastruktur
Integration mit CoreOS
Ein zentrales Update ist die Integration mit Red Hat CoreOS. Jetzt können die Master-Knoten von Red Hat OpenShift betrieben werden. nur unter einem neuen Betriebssystem. Dies ist ein kostenloses Betriebssystem von Red Hat, das speziell für Containerlösungen entwickelt wurde. Red Hat CoreOS ist ein leichtgewichtiger Linux, das für die Ausführung von Containern optimiert ist.
Während in Version 3.11 das Betriebssystem und OpenShift getrennt existierten, sind sie in Version 4.2 untrennbar mit OpenShift verbunden. Jetzt handelt es sich um einen einheitlichen Appliance — immutable infrastructure.
Für Cluster, die RHCOS für alle Knoten nutzen, ist das Update der OpenShift Container Platform ein einfacher, gut automatisierter Prozess.
Früher musste man, um OpenShift zu aktualisieren, zuerst das zugrunde liegende Betriebssystem aktualisieren, auf dem das Produkt ausgeführt wurde (damals war das Red Hat Enterprise Linux). Erst danach konnte OpenShift schrittweise, Knoten für Knoten, aktualisiert werden. Eine Automatisierung des Prozesses gab es nicht.
Jetzt, da die OpenShift Container Platform die Systeme und Dienste auf jedem Knoten, einschließlich des Betriebssystems, vollständig kontrolliert, erfolgt diese Aufgabe auf Knopfdruck über die Weboberfläche. Anschließend wird ein spezieller Operator innerhalb des OpenShift-Clusters gestartet, der den gesamten Update-Prozess steuert.
Neue CSI
Das zweite ist der neue CSI – ein Storage-Interface-Controller, der das Anschließen verschiedener externer Speichersysteme an das OpenShift-Cluster ermöglicht. Eine Vielzahl von Storage-Treibern für OpenShift, die von den Herstellern der Speichersysteme selbst entwickelt werden, wird unterstützt. Eine vollständige Liste der unterstützten CSI-Treiber finden Sie in diesem Dokument: . In dieser Liste sind alle gängigen Modellreihe von Speicherarrays der führenden Hersteller (Dell/EMC, IBM, NetApp, Hitachi, HPE, PureStorage), SDS-Lösungen (Ceph) und Cloud-Speicher (AWS, Azure, Google) aufgeführt. OpenShift 4.2 unterstützt die Verwendung von CSI-Treibern gemäß der CSI-Spezifikation Version 1.1.
RedHat OpenShift Service Mesh
Basierend auf den Projekten Istio, Kiali und Jaeger ermöglicht das Red Hat OpenShift Service Mesh neben den üblichen Aufgaben der Anfrage-Routing zwischen Services die Durchführung von Tracing und Visualisierung. Dies hilft Entwicklern, die Interaktion, Überwachung und Verwaltung von Anwendungen, die innerhalb von Red Hat OpenShift bereitgestellt werden, zu vereinfachen.
Visualisierung einer Anwendung mit Mikroservices-Architektur unter Verwendung von Kiali
Um die Prozesse der Installation, des Services und des Lebenszyklusmanagements von Service Mesh zu vereinfachen, bietet Red Hat OpenShift den Administratoren einen speziellen Operator – den Service Mesh Operator. Dies ist ein Kubernetes-Operator, der es ermöglicht, umkonfigurierte Pakete von Istio, Kiali und Jaeger im Cluster bereitzustellen und dabei die administrative Belastung bei der Anwendungsverwaltung zu minimieren.
CRI-O statt Docker
Der standardmäßige Container-Laufzeitumgebung Docker wurde durch CRI-O ersetzt. CRI-O konnte bereits in Version 3.11 verwendet werden, ist aber in Version 4.2 zur Hauptlaufzeit geworden. Es ist weder gut noch schlecht, sollte aber bei der Nutzung des Produkts beachtet werden.
Operatoren und Anwendungsbereitstellung
Operatoren sind eine neue Entität für Red Hat OpenShift, die in der vierten Version eingeführt wurde. Dies ist eine Methode zur Verpackung, Bereitstellung und Verwaltung von Kubernetes-Anwendungen. Man kann es sich wie ein Plugin für Anwendungen vorstellen, das über die Kubernetes-API und die kubectl-Tools gesteuert wird und in Containern bereitgestellt wird.
Kubernetes-Operatoren helfen dabei, alle Aufgaben rund um die Verwaltung und den Lebenszyklus der Anwendungen, die Sie in Ihrem Cluster bereitstellen, zu automatisieren. Beispielsweise kann ein Operator Aktualisierungen, Backups und Skalierungen der Anwendung automatisieren, Konfigurationen ändern usw. Die vollständige Liste der Operatoren finden Sie unter .
OperatorHub ist direkt über die Weboberfläche der Verwaltungs-Konsole zugänglich. Es handelt sich um einen Katalog von Anwendungen für OpenShift, der von Red Hat unterstützt wird. Das bedeutet, dass alle von Red Hat genehmigten Operatoren vom Anbieter unterstützt werden.
Das OperatorHub-Portal in der OpenShift-Verwaltungskonsole
Universelles Basisimage
Dies ist ein standardisiertes Set von OS-Bildern für RHEL, die zur Erstellung Ihrer Anwendungen in Containern verwendet werden können. Es gibt minimale, standardisierte und vollständige Sätze. Sie nehmen nur wenig Platz ein, unterstützen alle erforderlichen installierten Pakete und Programmiersprachen.
CI/CD-Tools
In Red Hat OpenShift 4.2 besteht die Möglichkeit, zwischen Jenkins und OpenShift Pipelines auf Basis von Tekton Pipelines zu wählen.
OpenShift Pipelines basiert auf Tekton, das die Ansätze Pipeline as Code und GitOps besser unterstützt. In den OpenShift-Pipelines wird jeder Schritt in einem eigenen Container ausgeführt, sodass Ressourcen nur während der Ausführung des Schrittes verwendet werden. Dies ermöglicht Entwicklern die vollständige Kontrolle über die Bereitstellungspipelines, Plugins und den Zugriff ohne einen zentralen CI/CD-Server zur Verwaltung.
OpenShift Pipelines befindet sich derzeit in der Preview-Phase für Entwickler und ist als Operator im OpenShift 4-Cluster verfügbar. Selbstverständlich können OpenShift-Nutzer weiterhin Jenkins in RedHat OpenShift 4 verwenden.
Updates im Management für Entwickler
In Version 4.2 hat OpenShift das Web-Interface sowohl für Entwickler als auch für Administratoren vollständig aktualisiert.
In früheren Versionen von OpenShift arbeiteten alle in drei Konsolen: Servicedirectory, Administrator-Konsole und Arbeitskonsole. Jetzt ist der Cluster nur noch in zwei Teile unterteilt – Administrator-Konsole und Entwickler-Konsole.
Die Entwicklerkonsole wurde mit signifikanten Verbesserungen der Benutzeroberfläche ausgestattet. Jetzt werden die Anwendungs- und Build-Topologien übersichtlicher dargestellt. Dies erleichtert Entwicklern die Erstellung, Bereitstellung und Visualisierung von Containeranwendungen und Clusterressourcen. So können sie sich auf das Wesentliche konzentrieren.
Entwicklerportal in der OpenShift-Verwaltungskonsole
Odo
Odo ist ein entwicklerfreundliches Kommandozeilenwerkzeug, das die Anwendungsentwicklung in OpenShift vereinfacht. Mit der Git-Push-ähnlichen Interaktion hilft dieses CLI Entwicklern, die mit Kubernetes nicht vertraut sind, Anwendungen in OpenShift zu erstellen.
Integration in Entwicklungsumgebungen
Entwickler können jetzt ihre Anwendungen in OpenShift erstellen, debuggen und bereitstellen, ohne ihre bevorzugte Entwicklungsumgebung zu verlassen, wie z. B. Microsoft Visual Studio, JetBrains (einschließlich IntelliJ), Eclipse Desktop usw.
Red Hat OpenShift Deployment-Erweiterung für Microsoft Azure DevOps
Die Red Hat OpenShift Deployment-Erweiterung ist jetzt für Microsoft Azure DevOps verfügbar. Benutzer dieses DevOps-Tool-Sets können ihre Anwendungen direkt aus Microsoft Azure DevOps in Azure Red Hat OpenShift oder jeden anderen OpenShift-Cluster bereitstellen.
Der Umstieg von Version 3 auf Version 4
Da es sich um ein neues Release und nicht um ein Update handelt, kann man nicht einfach Version 4 über Version 3 installieren. Das Update von Version 3 auf Version 4 wird nicht unterstützt..
Aber es gibt gute Nachrichten: Red Hat bietet Werkzeuge zum Übertragen von Projekten von 3.7 auf 4.2 an. Sie können die Workloads von Anwendungen mit dem Tool Cluster Application Migration (CAM) übertragen. CAM ermöglicht es, die Migration zu steuern und die Ausfallzeit der Anwendung zu minimieren.
OpenShift 4.3
Die wichtigsten Neuerungen, die in diesem Artikel beschrieben werden, erschienen in Version 4.2. In der kürzlich veröffentlichten Version 4.3 sind die Änderungen nicht so gravierend, aber es gibt dennoch einige Neuerungen. Die Liste der Änderungen ist recht umfangreich, hier sind die aus unserer Sicht bedeutendsten:
Upgrade der Kubernetes-Version auf 1.16.
Die Version wurde um zwei Schritte aktualisiert, in OpenShift 4.2 war sie 1.14.
Datenverschlüsselung in etcd
Seit Version 4.3 ist es möglich, Daten in der etcd-Datenbank zu verschlüsseln. Nach Aktivierung der Verschlüsselung können die folgenden Ressourcen im OpenShift API und Kubernetes API verschlüsselt werden: Secrets, ConfigMaps, Routes, Zugangstoken und OAuth-Authorisierungen.
Helm
Die Unterstützung für Helm Version 3 – den beliebten Paketmanager für Kubernetes – wurde hinzugefügt. Derzeit ist die Unterstützung im STATUS DES TECHNOLOGIE-VORSCHAU. In zukünftigen Versionen von OpenShift wird die Unterstützung für Helm auf volle Unterstützung erweitert. Das Helm CLI-Tool wird zusammen mit OpenShift bereitgestellt und kann über die Web-Konsole des Cluster-Managements heruntergeladen werden.
Aktualisierung des Project Dashboards
In der neuen Version bietet das Project Dashboard zusätzliche Informationen auf der Projektseite: Projektstatus, Ressourcennutzung und Quoten für das Projekt.
Anzeige von Schwachstellen für Quay in der Web-Konsole
Die Management-Konsole hat eine Funktion zur Anzeige bekannter Schwachstellen für Images in Quay-Repositories hinzugefügt. Die Anzeige von Schwachstellen für lokale und externe Repositories wird unterstützt.
Erstellung des Offline Operatorhubs vereinfacht
Für den Fall der Bereitstellung eines OpenShift-Clusters in einem isolierten Netzwerk, dessen Zugriff auf das Internet eingeschränkt oder nicht vorhanden ist, wurde die Erstellung eines „Spiegels“ für das OperatorHub-Register vereinfacht. Dies kann jetzt mit nur drei Befehlen durchgeführt werden.
Autoren:
Viktor Puschkow, Yuri Semeniuk
Quelle: habr.com
