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, was in der dritten Version nicht vorhanden war, oder bedeutende Aktualisierungen dessen, was in Version 4.1 eingeführt wurde. Alles, was wir jetzt erzählen werden, ist wichtig zu wissen, zu verstehen und zu berücksichtigen für alle, die mit OpenShift arbeiten und einen Wechsel auf die neue 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 serverlosen Bereitstellungen sind hinzugekommen. Diese Neuerungen ermöglichen es Entwicklern, sich auf das Codieren zu konzentrieren, anstatt sich mit Kubernetes auseinanderzusetzen.
Was gibt es Neues in den Versionen OpenShift 4.2 und 4.3?
Bewegung in Richtung hybrider Clouds
Bei der Planung neuer IT-Infrastrukturen oder der Weiterentwicklung bestehender IT-Landschaften ziehen Unternehmen zunehmend einen Cloud-Ansatz für die Bereitstellung von IT-Ressourcen in Betracht. Dazu implementieren sie private Cloud-Lösungen oder nutzen die Ressourcen öffentlicher Cloud-Anbieter. Auf diese Weise werden moderne IT-Infrastrukturen immer häufiger nach einem hybriden Cloud-Modell aufgebaut, bei dem sowohl On-Premises-Ressourcen als auch öffentliche Cloud-Ressourcen mit einem gemeinsamen Management-System verwendet werden. Red Hat OpenShift 4.2 wurde speziell entwickelt, um den Übergang zum hybriden Cloud-Modell zu erleichtern, und ermöglicht eine einfache Anbindung von Ressourcen solcher Anbieter wie AWS, Azure und Google Cloud Platform zusammen mit der Nutzung privater Clouds auf VMware und OpenStack.
Neuer Ansatz für die Installation
In der vierten Version hat sich der Ansatz zur Installation von OpenShift geändert. Red Hat bietet ein spezielles Dienstprogramm zur Bereitstellung eines OpenShift-Clusters an – openshift-install. Dieses Dienstprogramm ist eine einzelne Binärdatei, die in Go geschrieben ist. Der Openshift-Installer erstellt eine yaml-Datei mit der zur Bereitstellung erforderlichen Konfiguration.
Bei der Installation mit Cloud-Ressourcen müssen die minimalen Informationen über den zukünftigen Cluster angegeben werden: DNS-Zone, Anzahl der Worker-Knoten, spezifische Einstellungen für den Cloud-Anbieter, Zugangsdaten zum Cloud-Anbieter. Nach der Vorbereitung der Konfigurationsdatei kann der Cluster mit einem Befehl bereitgestellt werden.
Bei der Installation auf eigenen Rechenressourcen, zum Beispiel bei der Nutzung einer privaten Cloud (vSphere und OpenStack werden unterstützt) oder bei der Installation auf Bare-Metal-Servern, ist eine manuelle Konfiguration der Infrastruktur erforderlich – es müssen die minimale Anzahl an virtuellen Maschinen oder physischen Servern vorbereitet werden, die erforderlich sind, um ein Control Plane-Cluster zu erstellen, und die Netzwerkdienste konfiguriert werden. Nach dieser Konfiguration kann das OpenShift-Cluster ebenfalls mit einem Befehl des Openshift-Installers erstellt werden.
Updates in der Infrastruktur
Integration mit CoreOS
Ein Schlüssel-Update ist die Integration mit Red Hat CoreOS. Jetzt können die Master-Knoten von Red Hat OpenShift auf dem neuen Betriebssystem arbeiten. nur Dies ist ein kostenloses Betriebssystem von Red Hat, das speziell für Containerlösungen entwickelt wurde. Red Hat CoreOS ist ein schlankes Linux, das für den Betrieb von Containern optimiert ist.
Während in 3.11 das Betriebssystem und OpenShift separat existierten, ist es in 4.2 eng mit OpenShift verbunden. Jetzt ist es ein einzelnes Appliance – immutable infrastructure.
Für Cluster, die RHCOS für alle Knoten verwenden, ist das Update der OpenShift Container Platform ein einfacher und gut automatisierter Prozess.
Früher musste man OpenShift zuerst aktualisieren, indem man das zugrunde liegende Betriebssystem aktualisierte, auf dem das Produkt ausgeführt wurde (damals war es Red Hat Enterprise Linux). Erst danach konnte OpenShift schrittweise, Knoten für Knoten, aktualisiert werden. Von einer Automatisierung des Prozesses konnte nicht die Rede sein.
Jetzt hingegen, da die OpenShift Container Platform die Systeme und Dienste auf jedem Knoten, einschließlich des Betriebssystems, vollständig kontrolliert, wird diese Aufgabe per Knopfdruck über die Weboberfläche gelöst. Danach wird ein spezieller Operator innerhalb des OpenShift-Clusters gestartet, der den gesamten Aktualisierungsprozess verwaltet.
Neuer CSI
Zweitens – neuer CSI – ein Controller für die Storage-Schnittstelle, der es ermöglicht, verschiedene externe Speicherlösungen an das OpenShift-Cluster anzuschließen. Eine große Anzahl von Speicheranbietern wird für OpenShift unterstützt, basierend auf Storage-Treibern, die von den Herstellern der Speicherlösungen selbst geschrieben werden. Eine vollständige Liste der unterstützten CSI-Treiber finden Sie in diesem Dokument: . In dieser Liste finden Sie alle wichtigen Modelle von Speicherlösungen 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 in Version 1.1.
RedHat OpenShift Service Mesh
Basierend auf den Projekten Istio, Kiali und Jaeger – Red Hat OpenShift Service Mesh ermöglicht es neben den üblichen Aufgaben der Anfragenweiterleitung zwischen Diensten auch deren Nachverfolgbarkeit 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 mikroservicebasierter Architektur unter Verwendung von Kiali
Um die Prozesse zur Installation, Verwaltung und Lebenszyklusverwaltung des Service Mesh zu vereinfachen, stellt Red Hat OpenShift den Administratoren einen speziellen Operator – den Service Mesh Operator – zur Verfügung. Dies ist ein Kubernetes-Operator, der es ermöglicht, auf dem Cluster umkonfigurierte Pakete von Istio, Kiali und Jaeger bereitzustellen und administrative Belastungen bei der Anwendungsverwaltung zu minimieren.
CRI-O anstelle von Docker
Die Standard-Container-Runtime Docker wurde durch CRI-O ersetzt. Bereits in Version 3.11 konnte CRI-O genutzt werden, aber in 4.2 ist es die Hauptversion. Es ist weder gut noch schlecht, sollte jedoch beim Einsatz des Produkts berücksichtigt werden.
Operatoren und Bereitstellung von Anwendungen
Operatoren sind eine neue Entität für RedHat 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 als ein über die Kubernetes-API und kubectl verwaltetes Plugin für in Containern bereitgestellte Anwendungen vorstellen.
Kubernetes-Operatoren helfen dabei, sämtliche Aufgaben zu automatisieren, die mit der Verwaltung und dem Lebenszyklusmanagement einer Anwendung verbunden sind, die Sie in Ihrem Cluster bereitstellen. Beispielsweise kann ein Operator Updates, Backups und Skalierungen der Anwendung automatisieren, Konfigurationen ändern usw. Eine vollständige Liste der Operatoren finden Sie auf .
OperatorHub ist direkt über die Web-Oberfläche der Verwaltungs-Konsole zugänglich. Er ist ein Katalog von Anwendungen für OpenShift, der von Red Hat unterstützt wird. Das heißt, alle von Red Hat genehmigten Operatoren erhalten Unterstützung durch den Anbieter.
Portal OperatorHub in der Verwaltungs-Konsole von OpenShift
Universelles Basis-Image
Dies ist ein standardisierter Satz von Images für das Betriebssystem RHEL, die zur Erstellung Ihrer Anwendungen in Containern verwendet werden können. Es gibt minimal, standard und vollständig Pakete. Sie nehmen sehr wenig Platz ein und unterstützen alle erforderlichen installierten Pakete und Programmiersprachen.
CI/CD-Tools
In RedHat 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 OpenShift-Pipelines wird jeder Schritt in einem eigenen Container ausgeführt, sodass Ressourcen nur während der Ausführung des Schrittes verwendet werden. Dies gibt Entwicklern die vollständige Kontrolle über die Bereitstellungspipelines von Modulen, 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-Benutzer weiterhin Jenkins in RedHat OpenShift 4 nutzen.
Updates im Management für Entwickler
In 4.2 hat OpenShift das Webinterface sowohl für Entwickler als auch für Administratoren vollständig aktualisiert.
In früheren Versionen von OpenShift arbeiteten alle in drei Konsolen: Service-Katalog, Administrator-Konsole und Arbeitskonsole. Jetzt ist der Cluster nur noch in zwei Teile unterteilt - Administrator-Konsole und Entwickler-Konsole.
Die Entwicklerkonsole hat erhebliche Verbesserungen in der Benutzeroberfläche erhalten. Jetzt werden Anwendungs- und Buildtopologien übersichtlicher dargestellt. Dies erleichtert Entwicklern die Erstellung, Bereitstellung und Visualisierung von containerbasierten Anwendungen und Clusterressourcen. Dadurch können sie sich auf das konzentrieren, was für sie wichtig ist.
Das Entwicklerportal in der OpenShift-Management-Konsole
Odo
Odo ist ein auf Entwickler ausgerichtetes Kommandozeilenwerkzeug, das die Anwendungsentwicklung in OpenShift vereinfacht. Durch die Interaktion im Git-Push-Stil 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 wie Microsoft Visual Studio, JetBrains (einschließlich IntelliJ), Eclipse Desktop usw. verlassen zu müssen.
Red Hat OpenShift Deployment-Erweiterung für Microsoft Azure DevOps
Es ist eine Erweiterung für Red Hat OpenShift Deployment für Microsoft Azure DevOps erschienen. Jetzt können Benutzer dieses DevOps-Toolsets ihre Anwendungen direkt aus Microsoft Azure DevOps in Azure Red Hat OpenShift oder in ein anderes OpenShift-Cluster bereitstellen.
Übergang von Version drei auf vier
Da es sich um ein neues Release und nicht um ein Upgrade handelt, kann man nicht einfach die vierte Version über die dritte installieren. Ein Upgrade von der dritten auf die vierte Version wird nicht unterstützt.
Aber es gibt auch gute Nachrichten: Red Hat stellt Werkzeuge für die Migration von Projekten von 3.7 auf 4.2 zur Verfügung. Sie können Arbeitslasten von Anwendungen mit dem Tool Cluster Application Migration (CAM) migrieren. CAM ermöglicht die Steuerung der Migration und minimiert die Ausfallzeiten der Anwendung.
OpenShift 4.3
Die wichtigsten Neuerungen, die in diesem Artikel beschrieben werden, erschienen in Version 4.2. In der kürzlich veröffentlichten 4.3 sind die Änderungen nicht so bedeutend, aber es gibt trotzdem einige Neuigkeiten. Die Liste der Änderungen ist recht umfangreich, hier sind einige der wichtigsten aus unserer Sicht:
Update der Kubernetes-Version auf 1.16.
Die Version wurde um zwei Schritte aktualisiert, in OpenShift 4.2 war es 1.14.
Verschlüsselung von Daten in etcd
Seit Version 4.3 gibt es die Möglichkeit, Daten in der etcd-Datenbank zu verschlüsseln. Nach Aktivierung der Verschlüsselung können die folgenden Ressourcen der OpenShift API und der Kubernetes API verschlüsselt werden: Secrets, ConfigMaps, Routen, Zugangstoken und OAuth-Autorisierungen.
Helm
Unterstützung für Helm Version 3 – einen beliebten Paketmanager für Kubernetes – wurde hinzugefügt. Derzeit hat die Unterstützung den Status TECHNOLOGY PREVIEW. In zukünftigen Versionen von OpenShift wird die Unterstützung für Helm auf vollständige Ausprägung erweitert. Das Helm-CLI-Tool wird zusammen mit OpenShift bereitgestellt und kann über die Web-Konsole des Cluster-Managements heruntergeladen werden.
Update des Project Dashboards
In der neuen Version bietet das Project Dashboard zusätzliche Informationen auf der Projektseite: Projektstatus, Ressourcenauslastung und Quoten für das Projekt.
Darstellung von Schwachstellen für Quay in der Web-Konsole
In die Management-Konsole wurde die Funktion zur Anzeige bekannter Schwachstellen für Images in Quay-Repositories integriert. Die Anzeige von Schwachstellen in lokalen und externen Repositories wird unterstützt.
Die Erstellung von Offline-Operator-Hubs wurde vereinfacht.
Für den Fall der Bereitstellung eines OpenShift-Clusters in einem isolierten Netzwerk, dessen Zugriff zum Internet eingeschränkt oder nicht vorhanden ist, wurde die Erstellung eines „Spiegels“ für das OperatorHub-Registry vereinfacht. Dies kann jetzt mit nur drei Befehlen erfolgen.
Autoren:
Viktor Puchkov, Yuri Semenyukov
Quelle: habr.com
