Red Hat OpenShift 4.16: Was Sie wissen müssen

Red Hat OpenShift 4.16 ist jetzt allgemein verfügbar. Basierend auf Kubernetes 1.29 und CRI-O 1.29 konzentriert sich OpenShift 4.16 auf den Kern, Sicherheit, Virtualisierung und Funktionen für Telekommunikation und Edge Computing. Das Ziel von Red Hat OpenShift ist die Beschleunigung der modernen Anwendungsentwicklung und -bereitstellung in der gesamten Hybrid Cloud durch eine bewährte, umfassende und konsistente Plattform.

3-jähriger Lifecycle für Red Hat OpenShift 4.14 und höher

Das Produkt ist als Add-on-Subskription verfügbar und bietet jetzt eine optionale Laufzeit von zusätzlichen 12 Monaten Extended Update Support (EUS) für Red Hat OpenShift 4.14 und alle nachfolgenden Releases mit gerader Nummer. Dadurch wird der vollständige Lifecycle, der für diese EUS-Releases von Red Hat OpenShift zur Verfügung steht, von der vorherigen 6-monatigen EUS-Laufzeit auf 3 Jahre verlängert. Weitere Einzelheiten finden Sie in der Red Hat OpenShift Container Platform Life Cycle Policy.

Shift Left-Ansatz und Sicherheit skalieren mit Red Hat Advanced Cluster Security Cloud Service

Red Hat Advanced Cluster Security Cloud Service wird jetzt von der eingeschränkten Verfügbarkeit zur allgemeinen Verfügbarkeit hochgestuft. Red Hat Advanced Cluster Security Cloud Service ist ein vollständig gemanagter Kubernetes-nativer Security Cloud Service, der sowohl Red Hat OpenShift als auch Kubernetes-Plattformen anderer Anbieter wie Amazon EKS, Google GKE und Microsoft AKS unterstützt. Mit diesem Cloud Service können Sie einen sicherheitsorientierten Ansatz für die Entwicklung, Bereitstellung und Wartung cloudnativer Anwendungen in großem Umfang in der Hybrid Cloud verfolgen, unabhängig von der zugrunde liegenden Kubernetes-Plattform.

Kosten reduzieren und Cluster-Deployment optimieren mit selbst gemanagten gehosteten Control Planes in AWS

Gehostete Control Planes sind standardmäßig in der Multi-Cluster Engine (MCE) für Kubernetes Operator seit Version 2.4 aktiviert. Mit der MCE-Version 2.6 sind selbst gemanagte gehostete Control Planes in AWS allgemein neben Red Hat OpenShift 4.16 verfügbar.

Gehostete Control Planes bieten mehr Effizienz und Kosteneffektivität für das Management mehrerer OpenShift Cluster in großem Umfang. Es zentralisiert das Management der Control Plane und ermöglicht eine bessere Ressourcennutzung und eine einfachere Wartung. Mit gehosteten Control Planes können Sie sich auf Ihre Anwendungen konzentrieren, da Sie den Infrastruktur- und Verwaltungsaufwand reduzieren, das Deployment von Clustern optimieren und eine Trennung von Management und Workloads ermöglichen.

Externe Authentifizierungsserver in Red Hat OpenShift on AWS mit gehosteter Control Plane

Sie können jetzt Ihre eigene OpenID Connect (OIDC)-Lösung in Red Hat OpenShift Service on AWS (ROSA) mit gehosteten Control Planeseinbringen, damit Sie Nutzende und Gruppen direkt mit dem Kubernetes-API-Server authentifizieren können. ROSA-Cluster nutzen AWS Security Token Service (STS) und OIDC, um Cluster-internen Operatoren Zugriff auf die erforderlichen AWS-Ressourcen zu gewähren. Mehr erfahren Sie unter Vereinfachen Sie den Zugriff auf Ihre ROSA-Cluster mit externem OIDC.

OpenShift Cluster-Netzwerke mit Admin Network Policy sichern

Die nächste Generation von Kubernetes-Netzwerkrichtlinien wird jetzt in Deployments von OpenShift, die OVN-Kubernetes für Netzwerke verwenden, vollständig unterstützt. Admin Network Policy (auch als Global Network Policy bezeichnet) bietet Verbesserungen zu vorherigen Implementierung der Network Policy im Upstream. Zu den am häufigsten nachgefragten Features gehören:

• Netzwerksicherheitsrichtlinien sind nur für Administratoren gültig und können nicht von Namespace-Administratoren und -Entwicklern überschrieben werden.
• Geltungsbereich im gesamten Cluster. Ausgangsrichtlinien können beispielsweise nur einmal an einem Ort definiert und auf den gesamten Cluster-Datenverkehr angewendet werden.
• Die Möglichkeit, spezifische, geprüfte Sicherheitsrichtlinien an Namespace-Administratoren und Entwickler zu delegieren, damit diese über die notwendige Flexibilität für Netzwerkrichtlinien für die Anwendungsentwicklung verfügen.

Die Admin-Netzwerkrichtlinie ermöglicht Ihnen Folgendes:

• Isolieren Sie Mandanten innerhalb eines Clusters mit einer vom Administrator privilegierten Kontrolle.
• Erstellen Sie eine endgültige Zulassungsliste für den Datenverkehr, der immer fließen muss.
• Legen Sie eine unveränderlichen Richtlinie für den gesamten ausgehenden Cluster-Datenverkehr fest. Sie können beispielsweise erzwingen, dass der gesamte Datenverkehr ein Gateway-Gerät zur Überprüfung durchläuft.
• Definieren Sie eine Richtlinie für den Netzwerkverkehr mit einer genauen Auflösung für hochselektive Datenverkehrsmuster, insbesondere zu und von sensiblen Namespaces.

Reduzierung von nicht authentifizierten Benutzer- oder Gruppenzugriff

Ab OpenShift 4.16 gibt es eine Beschränkung der Berechtigungen für den Benutzer system:anonymous und die Gruppesystem:unauthenticated. Standardmäßig sind nur zwei Rollen zulässig:

• system:openshift:public-info-viewer: erforderlich für OIDC-Workflows
• system:public-info-viewer: Lesezugriff auf nicht vertrauliche Informationen über den Cluster

Dies gilt nur für neue Cluster. Cluster, für die ein Upgrade durchgeführt wird, sind nicht betroffen.

Für Anwendungsfälle, in denen anonymer Zugriff erforderlich ist, muss der Cluster-Administrator diese Berechtigungen explizit hinzufügen. Wenn Sie beispielsweise Webhooks für BuildConfigs von einem externen System (wie GitHub) verwenden, die das Senden von Authentifizierungstoken über HTTP nicht unterstützen, müssen Sie Berechtigungen für system:webhook explizit hinzufügen. Wir empfehlen in solchen Szenarien dringend die Verwendung von lokalen Rollenbindungen (RoleBinding) anstelle von ClusterRoleBinding-Objekten. Ein Cluster-Administrator kann bei Bedarf wieder eine ClusterRoleBinding für den anonymen Benutzer hinzufügen, nachdem er die damit verbundenen Risiken und Vorteile abgewogen hat.

Vereinfachte Fehlerbehebung bei OpenShift-Updates mit Upgrade-Status oc adm

Red Hat OpenShift 4.16 enthält den neuen Befehl oc adm upgrade status, der als Technologievorschau verfügbar ist. Dieser Befehl zeigt den Fortschritt der Cluster-Aktualisierung an und Admin-Teams sehen auf einen Blick, ob das Update gut verläuft oder ob sie eingreifen müssen. Im Falle eines Update-Problems gibt der Befehl Informationen darüber zurück, was gerade passiert, zusammen mit Anweisungen und Links zu relevanten Ressourcen (z. B. Red Hat-Dokumentation oder Knowledgebase-Artikel).

# oc adm upgrade status
An update is in progress for 55m7s: Working towards 4.16.0: 198 of 951 done (20% complete)
= Control Plane =
Assessment:      Progressing
Completion:      97%
Duration:        55m6.974951563s
Operator Status: 36 Total, 36 Available, 1 Progressing, 0 Degraded
= Worker Upgrade =
= Worker Pool =
Worker Pool:     worker
Assessment:      Progressing
Completion:      7%
Worker Status:   42 Total, 22 Available, 20 Progressing, 39 Outdated, 19 Draining, 0 Excluded, 0 Degraded
Worker Pool Node(s)
NAME                                       ASSESSMENT    PHASE      VERSION       EST    MESSAGE
build0-gstfj-ci-builds-worker-b-25ptt      Progressing   Draining   4.16.0-ec.3   +30m   
build0-gstfj-ci-longtests-worker-b-ppxvc   Progressing   Draining   4.16.0-ec.3   +30m   
build0-gstfj-ci-prowjobs-worker-b-gvthg    Progressing   Draining   4.16.0-ec.3   +30m   
build0-gstfj-ci-tests-worker-b-7hvhq       Progressing   Draining   4.16.0-ec.3   +30m   
...
Omitted additional 32 Total, 3 Completed, 22 Available, 10 Progressing, 29 Outdated, 9 Draining, 0 Excluded, and 0 Degraded nodes.
Pass along --details to see all information.
= Update Health =
SINCE   LEVEL   IMPACT   MESSAGE
55m7s   Info    None     Upgrade is proceeding well

In-Place Migration zu Microsoft Entra Workload ID

Wenn Sie das selbst gemanagte Red Hat OpenShift auf Azure verwenden, können Sie jetzt mit minimalen Ausfallzeiten zu Microsoft Entra Workload ID (ehemals Azure AD Workload Identity) migrieren. Die Unterstützung von Microsoft Entra Workload ID wurde in Red Hat OpenShift 4.14 hinzugefügt. Kunden können damit Red Hat OpenShift Cluster mit temporären, begrenzten Berechtigungen erstellen und verwalten. Jetzt können Sie Microsoft Entra Workload ID einführen, ohne mit einem neuen Cluster beginnen zu müssen. Weitere Informationen finden Sie unter Konfigurieren von OpenShift mit Microsoft Entra Workload ID.

Optimieren der Cluster-Leistung mit etcd-Tuning-Parametern

Jetzt können Sie etcd aktualisieren, damit Ihr Cluster eine geringere Latenz zwischen etcd-Mitgliedern tolerieren kann. Dazu legen Sie die Latenzparameter für das Heartbeat-Intervall und die Leader Wahl-Timeouts auf Werte fest, die die Performance optimieren und die Latenz verringern. Die möglichen Werte sind:

• "" (Standardwert ist leer)
• Standard
• Langsamer

Auf diese Weise können Sie Szenarien berücksichtigen, in denen Sie möglicherweise über langsamere, aber akzeptable Disks oder über ausgedehnte Cluster verfügen, die unter die Best Practices OpenShift Leistung und Skalierbarkeit fallen.

Weitere Informationen finden Sie in der etcd-Spezifikation.

Optimieren Sie die automatische Cluster-Skalierung entsprechend den Workload-Anforderungen

Der Cluster Autoscaler verwendet nun die Expander-Strategien „LeastWaste“, „Priority“ und „Random“. Sie konfigurieren diese Expander so, dass sie die Auswahl der MachineSets bei der Skalierung Ihres Clusters beeinflussen.

• Random: Empfohlen für die gleichmäßige Verteilung von Workloads in einem homogenen Cluster, in dem die Knotengruppen ähnliche Ressourcen bieten.
• LeastWaste: Für Cluster, bei denen Effizienz und die Minimierung von Ressourcenverschwendung Prioritäten darstellen, insbesondere bei dynamischen Workloads, bei denen es auf schnelle Skalierung und Flexibilität ankommt.
• Priority: Für anspruchsvolle Skalierungsentscheidungen auf der Basis benutzerdefinierter Prioritäten. Auch für komplexe Cluster mit unterschiedlichen Knotengruppen geeignet.

Eigene Load Balancers für On-Premise Deployments nutzen

Mit Red Hat OpenShift 4.16 können Sie Ihren eigenen, von Nutzenden gemanagten Load Balancer in Verbindung mit einem Cluster auf einer beliebigen lokalen Infrastruktur (Bare Metal, VMware vSphere, Red Hat OpenStack Platform, Nutanix und mehr) verwenden. Für diese Konfiguration geben Sie loadBalancer.type:UserManaged in der Datei install-config.yaml Ihres Clusters an. Weitere Informationen zu diesem Feature finden Sie unter Services für einen vom Benutzer verwalteten Load Balancer.

Transparenz Ihres Clusters durch erweiterte Überwachungs- und Fehlerbehebungsfunktionen verbessern

Red Hat OpenShift 4.16 umfasst erhebliche Verbesserungen der Beobachtbarkeitsfunktionen und bietet verbesserte Tools für die Überwachung, Fehlerbehebung und Optimierung eines Clusters. Komponenten des In-Cluster-Monitoring-Stacks wie Prometheus, Thanos und neue Alarmregeln wurden aktualisiert. Ein neuer Metrics Server vereinfacht die Metrikerfassung, und die neue monitoring-alertmanager-view-Rolle verbessert Sicherheit und Zusammenarbeit. Diese Funktionen sind im Cluster Observability Operator Version 0.3.0 enthalten, der als zentraler Operator für die Installation und Verwaltung von Beobachtbarkeit dient. Dieses Release umfasst außerdem Verbesserungen an OpenTelemetry und erweiterte die Funktionalität der Cluster Logging API.

Cluster Observability Operator führt eine neue Version der Observability Signal Correlation zur Korrelation von Beobachtbarkeitssignalen, Incident Detection zur Priorisierung kritischer Warnungen und Verbesserungen des Distributed Tracing mit Tempo Operator-Unterstützung für die monolithische Bereitstellung ein. Distributed Tracing-Visualisierungen werden nun in der OpenShift-Konsole angezeigt.

Observability Signal Correlation und Incident Detection sind beide für die Developer Preview verfügbar. Power Monitoring, das für die Technologievorschau verfügbar ist, bietet jetzt eine Integration mit einer Entwickler-Benutzeroberfläche (UI) und verbessert die Datengenauigkeit.

Infrastrukturmanagement mit Red Hat OpenShift Virtualization modernisieren

Im Bereich Red Hat OpenShift Virtualization freuen wir uns, die allgemeine Verfügbarkeit von Metro Disaster Recovery für virtuelle Maschinen (VMs) bekannt zu geben, die Storage auf Red Hat OpenShift Data Foundation in Verbindung mit Red Hat Advanced Cluster Management for Kubernetes (RHACM) für das Management nutzen.

Wir haben eine Reihe von VM-Verbesserungen vorgenommen. Sie haben nun die Möglichkeit, einer ausgeführten VM deklarativ zusätzliche vCPU-Ressourcen hinzuzufügen. Es gibt eine verbesserte Speicherdichte mit sicherem Memory Overcommit, und wir haben die Skalierung von VMs mit CPU-Hotplug vereinfacht.

Mit RHACM können Sie jetzt Multi-Cluster-VMs überwachen. Über einen RHACM-Hub können Sie alle VMs in mehreren OpenShift-Clustern anzeigen. Sie können Berichte für alle VMs erfassen und schnell erstellen. In einem globalen RHACM-Hub mit Global Hub Search können Sie alle VMs auf mehreren Hubs anzeigen.

Das Partnernetzwerk wächst weiter mit Hardware-Partnern, Storage- und Netzwerkinfrastruktur-Partnern sowie Drittanbietern für Datenschutz. Neben Veeam Kasten, Trilio und Storaware gibt es neue Funktionen von Cohesity, Commvault, Kapitel und Veritas.

Image-basiertes Update für OpenShift-Cluster mit einem Knoten mithilfe von Lifecycle-Agent

Die Telekommunikationspartner von Red Hat wechseln zu Containern für Radio Access Networks (RAN) und stellen Lösungen auf Einzelknoten OpenShift bereit. Red Hat OpenShift 4.16 bietet einen „Shift-Left“-Ansatz mit imagebasierten Updates (IBU). IBU bietet eine alternative Möglichkeit zur Aktualisierung eines OpenShift-Clusters mit einem Knoten. Dabei verlagern OpenShift-Benutzer mit einem Knoten einen großen Teil des Aktualisierungsprozesses in eine Vorproduktionsumgebung, um den Zeitaufwand für die Aktualisierung am Produktionsstandort zu reduzieren.

Mit der IBU können Sie z-stream-Updates, Nebenversions-Updates sowie direkte EUS-zu-EUS-Updates durchführen, bei denen die Zwischenversion übersprungen wird. Diese Update-Methode verwendet den Lifecycle-Agent, um ein OCI-Image aus einem dedizierten Seed-Cluster zu generieren, der auf dem OpenShift-Ziel-Einzelknoten-Cluster als neuer ostree stateroot installiert wird. Ein Seed-Cluster ist ein OpenShift-Cluster mit einem einzelnen Knoten, der mit der Zielversion von OpenShift Container Platform, den bereitgestellten Operatoren und den Konfigurationen, die allen Ziel-Clustern gemeinsam sind, bereitgestellt wird. Anschließend verwenden Sie das Seed-Image, um die Plattformversion in jedem OpenShift-Cluster mit einem Knoten zu aktualisieren, der dieselbe Kombination aus Hardware, Operatoren und Cluster-Konfiguration wie der Seed-Cluster aufweist.

Wenn ein Update fehlschlägt oder die Anwendung nicht wieder funktioniert, kann sie auf den Zustand vor dem Update zurückgesetzt werden. Hinweis: Dies gilt nur für OpenShift-Cluster mit einem Knoten. Dadurch wird sichergestellt, dass der Service in einem Szenario mit erfolgreichen oder fehlerhaften Updates so schnell wie möglich wiederhergestellt wird. IBU ist nahtlos in die Zero Touch Provisioning-Workflows integriert, die Red Hat OpenShift GitOps und Red Hat Advanced Cluster Management verwenden.

Entwicklung einer eigenständigen OpenShift Appliance in großem Umfang

Partner, die benutzerdefinierte, sofort einsatzbereite Appliances mit eigenständigem OpenShift und zusätzlichen Services auf ihrer vorgeschriebenen Hardware in großem Umfang erstellen möchten, können dies jetzt mit dem OpenShift-basierten Appliance Builder tun, der als Technologievorschau verfügbar ist. Der OpenShift-basierte Appliance Builder ist ein containerbasiertes Dienstprogramm, das ein Disk-Image erstellt, das das Agent-basierte Installationsprogramm enthält, das zur Installation mehrerer OpenShift-Cluster verwendet wird. Weitere Informationen finden Sie im OpenShift-based Appliance Builder User Guide.

Verbessertes Networking, GitOps-Management und nahtlose EUS-Updates für MicroShift

Für den Red Hat Build von MicroShift wurden im neuesten Release drei Updates zur Verbesserung des Edge-Managements eingeführt:

1. Mehrere Netzwerkschnittstellen mit Pods verbinden Multus CNI für MicroShift: Mit Multus können Kubernetes-Pods eine Verbindung zu mehreren Netzwerken herstellen. Dies ist hilfreich, wenn Sie SR-IOV verwenden oder komplexe VLAN-Konfigurationen haben. Wenn Multus auf Microshift aktiviert ist, können Sie mithilfe der CNI-Plugins bridge, macvlan oder ipvlan ganz einfach mehrere Schnittstellen zu Pods hinzufügen.
2. Automatisierung der Infrastruktur- und Anwendungsverwaltung mit GitOps für MicroShift: Mit GitOps für MicroShift können Sie Kubernetes-basierte Infrastruktur und Anwendungen konsistent in Clustern und Entwicklungs-Lifecycles konfigurieren und bereitstellen. GitOps mit Argo CD für MicroShift ist ein schlanker, optionaler Add-on-Controller, der vom Red Hat OpenShift GitOps Operator abgeleitet ist. GitOps for MicroShift verwendet die Argo-CD-Befehlszeilenschnittstelle, um mit dem GitOps-Controller zu interagieren, der als deklarative GitOps-Engine fungiert.
3. Direkte EUS-Updates für MicroShift: MicroShift aktualisiert jetzt direkt die Version 4.14 des Extended User Support (EUS) auf Version 4.16 mit einem einzigen Neustart (Red Hat Enterprise Linux 9.4 ist für Version 4.16 erforderlich).

Testen Sie Red Hat OpenShift 4.16

Starten Sie noch heute mit Red Hat Hybrid Cloud Console, und profitieren Sie von den neuesten Funktionen und Verbesserungen in OpenShift. Sehen Sie sich die folgenden Ressourcen an, um herauszufinden, was Sie als Nächstes tun:

• Neuerungen und Updates in Red Hat OpenShift
• OpenShift YouTube Channel
• OpenShift Blogs
• OpenShift Commons
• Red Hat Developer Blogs
• Red Hat Portfolio Architecture Center

Eine vollständige Liste der Red Hat OpenShift 4.16 Updates finden Sie in den Red Hat OpenShift 4.16 Release Notes. Senden Sie uns Feedback über Ihre Kontakte bei Red Hat, senden Sie uns eine Nachricht an den OpenShift Commons Slack-Channel oder erstellen Sie eine Issue auf GitHub.