Die vierte Version von OpenShift wurde vor relativ kurzer Zeit veröffentlicht. Die aktuelle Version 4.3 ist seit Ende Januar verfügbar und alle darin enthaltenen Änderungen sind entweder etwas völlig Neues, das es in der dritten Version nicht gab, oder ein großes Update dessen, was in Version 4.1 erschien. Alles, was wir Ihnen jetzt sagen werden, muss von denen bekannt, verstanden und berücksichtigt werden, die mit OpenShift arbeiten und einen Umstieg auf eine neue Version planen.
Mit der Veröffentlichung von OpenShift 4.2 hat Red Hat die Arbeit mit Kubernetes einfacher gemacht. Für die Erstellung von Containern, CI/CD-Pipelines und serverlosen Bereitstellungen sind neue Tools und Plugins erschienen. Innovationen geben Entwicklern die Möglichkeit, sich auf das Schreiben von Code zu konzentrieren und nicht auf den Umgang mit Kubernetes.
Was ist eigentlich neu in den Versionen von OpenShift 4.2 und 4.3?
Auf dem Weg zu Hybrid Clouds
Bei der Planung einer neuen IT-Infrastruktur oder beim Aufbau einer bestehenden IT-Landschaft denken Unternehmen zunehmend über einen Cloud-Ansatz zur Bereitstellung von IT-Ressourcen nach, für den sie Private-Cloud-Lösungen implementieren oder die Leistungsfähigkeit öffentlicher Cloud-Anbieter nutzen. Daher werden moderne IT-Infrastrukturen zunehmend nach einem „hybriden“ Cloud-Modell aufgebaut, bei dem sowohl On-Premise-Ressourcen als auch Public-Cloud-Ressourcen mit einem gemeinsamen Managementsystem genutzt werden. Red Hat OpenShift 4.2 wurde speziell entwickelt, um den Übergang zu einem Hybrid-Cloud-Modell zu vereinfachen und die Anbindung von Ressourcen von Anbietern wie AWS, Azure und Google Cloud Platform an den Cluster sowie die Nutzung privater 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 eine einzelne in Go geschriebene Binärdatei. Openshit-Installer bereitet eine Yaml-Datei mit der für die Bereitstellung erforderlichen Konfiguration vor.
Bei der Installation mithilfe von Cloud-Ressourcen müssen Sie minimale Informationen zum zukünftigen Cluster angeben: DNS-Zone, Anzahl der Worker-Knoten, spezifische Einstellungen für den Cloud-Anbieter, Kontoinformationen für den Zugriff auf den Cloud-Anbieter. Nach der Vorbereitung der Konfigurationsdatei kann der Cluster mit einem Befehl bereitgestellt werden.
Bei der Installation auf Ihren eigenen Computerressourcen, beispielsweise bei Verwendung einer privaten Cloud (vSphere und OpenStack werden unterstützt) oder bei der Installation auf Bare-Metal-Servern, müssen Sie die Infrastruktur manuell konfigurieren – bereiten Sie die Mindestanzahl virtueller Maschinen vor oder physische Server, die zum Erstellen eines Control Plane-Clusters erforderlich sind, Netzwerkdienste konfigurieren. Nach dieser Konfiguration kann ein OpenShift-Cluster auf ähnliche Weise mit einem Befehl des Dienstprogramms openshift-installer erstellt werden.
Infrastrukturaktualisierungen
CoreOS-Integration
Das wichtigste Update ist die Integration mit Red Hat CoreOS. Red Hat OpenShift-Masterknoten können jetzt funktionieren nur auf dem neuen Betriebssystem. Hierbei handelt es sich um 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 nun eine einzige Appliance – eine unveränderliche Infrastruktur.
Für Cluster, die RHCOS für alle Knoten verwenden, ist das Upgrade der OpenShift Container Platform ein einfacher und hochautomatisierter Prozess.
Bisher musste man zum Aktualisieren von OpenShift zunächst das zugrunde liegende Betriebssystem aktualisieren, auf dem das Produkt lief (damals Red Hat Enterprise Linux). Nur dann konnte OpenShift schrittweise Knoten für Knoten aktualisiert werden. Von einer Automatisierung des Prozesses war keine Rede.
Da die OpenShift Container Platform nun die Systeme und Dienste auf jedem Knoten, einschließlich des Betriebssystems, vollständig steuert, kann diese Aufgabe per Knopfdruck über die Weboberfläche gelöst werden. Anschließend wird im OpenShift-Cluster ein spezieller Operator gestartet, der den gesamten Update-Prozess steuert.
Neues CSI
Zweitens handelt es sich beim neuen CSI um einen Speicherschnittstellen-Controller, mit dem Sie verschiedene externe Speichersysteme an den OpenShift-Cluster anschließen können. Eine große Anzahl von Speichertreiberanbietern für OpenShift werden basierend auf Speichertreibern unterstützt, die von den Speichersystemherstellern selbst geschrieben werden. Eine vollständige Liste der unterstützten CSI-Treiber finden Sie in diesem Dokument: . In dieser Liste finden Sie alle Hauptmodelle von Disk-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 CSI-Treiber der CSI-Spezifikation Version 1.1.
RedHat OpenShift Service Mesh
Basierend auf den Projekten Istio, Kiali und Jaeger ermöglicht Red Hat OpenShift Service Mesh zusätzlich zu den üblichen Aufgaben der Weiterleitung von Anforderungen zwischen Diensten auch deren Nachverfolgung und Visualisierung. Dies hilft Entwicklern, eine in Red Hat OpenShift bereitgestellte Anwendung einfach zu kommunizieren, zu überwachen und zu verwalten.
Visualisierung einer Anwendung mit einer Microservice-Architektur mithilfe von Kiali
Um die Installation, Wartung und Lebenszyklusverwaltung von Service Mesh so weit wie möglich zu vereinfachen, stellt Red Hat OpenShift Administratoren einen speziellen Operator zur Verfügung, den Service Mesh Operator. Dies ist ein Kubernetes-Operator, der es Ihnen ermöglicht, neu konfigurierte Istio-, Kiali- und Jaeger-Pakete in einem Cluster bereitzustellen und so den Verwaltungsaufwand für die Verwaltung von Anwendungen zu maximieren.
CRI-O statt Docker
Der Standard-Container-Laufzeit-Docker wurde durch CRI-O ersetzt. CRI-O konnte bereits in Version 3.11 verwendet werden, in 4.2 wurde es jedoch zur Hauptversion. Nicht gut oder schlecht, aber etwas, das man bei der Verwendung des Produkts beachten sollte.
Betreiber und Anwendungsbereitstellung
Operatoren sind eine neue Entität für RedHat OpenShift, das in der vierten Version erschien. Es handelt sich um eine Methode zum Packen, Bereitstellen und Verwalten einer Kubernetes-Anwendung. Man kann es sich als Plugin für Anwendungen vorstellen, die in Containern bereitgestellt werden und von der Kubernetes-API und den Kubectl-Tools gesteuert werden.
Kubernetes-Operatoren helfen bei der Automatisierung aller Aufgaben im Zusammenhang mit der Verwaltung und dem Lebenszyklusmanagement der Anwendung, die Sie in Ihrem Cluster bereitstellen. Beispielsweise kann der Betreiber Updates, Backups und Skalierung der Anwendung automatisieren, die Konfiguration ändern usw. Eine vollständige Liste der Betreiber finden Sie unter .
Auf OperatorHub kann direkt über die Weboberfläche der Verwaltungskonsole zugegriffen werden. Es handelt sich um ein von Red Hat verwaltetes Anwendungsverzeichnis für OpenShift. Diese. Alle von Red Hat zugelassenen Betreiber sind durch den Herstellersupport abgedeckt.
OperatorHub-Portal in der OpenShift-Verwaltungskonsole
Universelles Basisbild
Es handelt sich um einen standardisierten Satz von RHEL-Betriebssystem-Images, die zum Erstellen Ihrer Containeranwendungen verwendet werden können. Es gibt Minimal-, Standard- und Komplettsets. Sie nehmen sehr wenig Platz ein und unterstützen alle notwendigen installierten Pakete und Programmiersprachen.
CI/CD-Tools
In RedHat OpenShif 4.2 wurde es möglich, zwischen Jenkins und OpenShift Pipelines basierend auf Tekton Pipelines zu wählen.
OpenShift Pipelines basiert auf Tekton, das von Pipeline als Code- und GitOps-Ansätzen besser unterstützt wird. 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 Modulbereitstellungspipelines, Plugins und Zugriffskontrolle, ohne dass ein zentraler CI/CD-Server verwaltet werden muss.
OpenShift Pipelines befindet sich derzeit in der Entwicklervorschau und ist als Operator auf einem OpenShift 4-Cluster verfügbar. OpenShift-Benutzer können Jenkins natürlich weiterhin auf RedHat OpenShift 4 verwenden.
Aktualisierungen der Entwicklerverwaltung
In 4.2 OpenShift wurde die Weboberfläche sowohl für Entwickler als auch für Administratoren komplett aktualisiert.
In früheren Versionen von OpenShift arbeiteten alle an drei Konsolen: Dienstverzeichnis, Administratorkonsole und Arbeitskonsole. Jetzt ist der Cluster nur noch in zwei Teile unterteilt – die Administratorkonsole und die Entwicklerkonsole.
Die Entwicklerkonsole hat erhebliche Verbesserungen an der Benutzeroberfläche erfahren. Jetzt werden die Topologien von Anwendungen und deren Baugruppen bequemer angezeigt. Dies erleichtert Entwicklern das Erstellen, Bereitstellen und Visualisieren von Containeranwendungen und Clusterressourcen. Ermöglicht ihnen, sich auf das zu konzentrieren, was ihnen wichtig ist.
Entwicklerportal in der OpenShift-Verwaltungskonsole
Odo
Odo ist ein entwicklerorientiertes Befehlszeilendienstprogramm, das die Anwendungsentwicklung in OpenShift vereinfacht. Diese CLI nutzt die Kommunikation im Git-Push-Stil und hilft Entwicklern, die neu bei Kubernetes sind, beim Erstellen von Anwendungen in OpenShift.
Integration mit Entwicklungsumgebungen
Entwickler können jetzt ihre Anwendungen in OpenShift erstellen, debuggen und bereitstellen, ohne ihre bevorzugte Code-Entwicklungsumgebung wie Microsoft Visual Studio, JetBrains (einschließlich IntelliJ), Eclipse Desktop usw. zu verlassen.
Red Hat OpenShift Deployment-Erweiterung für Microsoft Azure DevOps
Die Red Hat OpenShift Deployment-Erweiterung für Microsoft Azure DevOps ist erschienen. Benutzer dieses DevOps-Toolsets können ihre Anwendungen jetzt direkt aus Microsoft Azure DevOps in Azure Red Hat OpenShift oder einem anderen OpenShift-Cluster bereitstellen.
Übergang von der dritten Version zur vierten
Da es sich um eine neue Version und nicht um ein Update handelt, kann man nicht einfach die vierte Version auf die dritte legen. Ein Update von Version XNUMX auf Version XNUMX wird nicht unterstützt..
Aber es gibt eine gute Nachricht: Red Hat stellt Tools für die Migration von Projekten von 3.7 auf 4.2 bereit. Sie können Anwendungs-Workloads mit dem Cluster Application Migration (CAM)-Tool migrieren. Mit CAM können Sie die Migration steuern und Anwendungsausfallzeiten minimieren.
offene Schicht 4.3
Die wichtigsten in diesem Artikel beschriebenen Neuerungen erschienen in Version 4.2. Die kürzlich veröffentlichten 4.3-Änderungen sind nicht so groß, aber es gibt dennoch einige neue Dinge. Die Liste der Änderungen ist recht umfangreich, hier sind unserer Meinung nach die wichtigsten:
Aktualisieren Sie die Kubernetes-Version auf 1.16.
Die Version wurde um zwei Schritte gleichzeitig aktualisiert; in OpenShift 4.2 war sie 1.14.
Datenverschlüsselung in etcd
Ab Version 4.3 ist es möglich, Daten in der etcd-Datenbank zu verschlüsseln. Sobald die Verschlüsselung aktiviert ist, können die folgenden OpenShift-API- und Kubernetes-API-Ressourcen verschlüsselt werden: Secrets, ConfigMaps, Routen, Zugriffstoken und OAuth-Autorisierung.
Helm
Unterstützung für Helm Version 3, einen beliebten Paketmanager für Kubernetes, hinzugefügt. Der Support hat vorerst den Status TECHNOLOGY PREVIEW. Die Helm-Unterstützung wird in zukünftigen Versionen von OpenShift auf volle Unterstützung ausgeweitet. Das Helm-CLI-Dienstprogramm wird mit OpenShift geliefert und kann von der Cluster-Management-Webkonsole heruntergeladen werden.
Aktualisierung des Projekt-Dashboards
In der neuen Version bietet das Project Dashboard zusätzliche Informationen auf der Projektseite: Projektstatus, Ressourcenauslastung und Projektkontingente.
Anzeige von Schwachstellen für Quay in der Webkonsole
Der Verwaltungskonsole wurde eine Funktion hinzugefügt, um bekannte Schwachstellen für Bilder in Quay-Repositorys anzuzeigen. Die Anzeige von Schwachstellen für lokale und externe Repositories wird unterstützt.
Vereinfachte Erstellung eines Offline-Operatorhubs
Für den Fall der Bereitstellung eines OpenShift-Clusters in einem isolierten Netzwerk, von dem aus der Zugriff auf das Internet eingeschränkt oder nicht möglich ist, wird die Erstellung eines „Spiegels“ für die OperatorHub-Registrierung vereinfacht. Jetzt ist dies mit nur drei Teams möglich.
Autoren:
Victor Puchkov, Yuri Semenyukov
Source: habr.com