Red Hat OpenShift 4.20 beschleunigt Virtualisierung und Innovation von Unternehmens-KI

Red Hat OpenShift 4.20 ist jetzt allgemein verfügbar. Es basiert auf Kubernetes 1.33 und CRI-O 1.33. Zusammen mit Red Hat OpenShift Platform Plus unterstreicht dieses Release unser Engagement für die Bereitstellung einer zuverlässigen, umfassenden und konsistenten Anwendungsplattform. Auf OpenShift können KI-Workloads, Container und Virtualisierung nahtlos nebeneinander betrieben werden. So können Unternehmen Innovationen in der Hybrid Cloud schneller und ohne Kompromisse bei der Sicherheit umsetzen.

OpenShift ist in selbst gemanagten oder vollständig gemanagten Cloud Service-Versionen verfügbar und bietet eine Anwendungsplattform mit einem kompletten Set an integrierten Tools und Services für cloudnative, KI-, virtuelle und herkömmliche Workloads. In diesem Artikel werden die neuesten Innovationen und wichtige Verbesserungen in OpenShift 4.20 vorgestellt. Eine umfassende Liste von Updates und Verbesserungen finden Sie in den Versionshinweisen zu OpenShift 4.20.

Dieses neueste Release erweitert die Funktionen der Plattform für KI-Workloads mit der allgemeinen Verfügbarkeit von LeaderWorkerSet, der Gateway-API-Inferenzerweiterung und der Runtime OCI-Image-Quelle (Open Container Initiative). Darüber hinaus stärkt die Lösung die Kernfunktionen und führt wichtige Verbesserungen, darunter eigene, externe Identity Provider, Zero Trust Workload Identity Manager, User Namespace,External Secrets Operator for Red Hat OpenShift und Support für Border Gateway Protocol (BGP). Darüber hinaus bietet OpenShift 4.20 wichtige Fortschritte im Bereich der Virtualisierung, wie CPU-lastbewusstes Rebalancing und schnellere Live-Migration und stellt damit eine robustere und vielseitigere Plattform für verschiedenste Computing-Anforderungen bereit.

OpenShift 4.20 ermöglicht jetzt den hybriden Schlüsselaustauschmechanismus X25519MLKEM768 mit der Version Go 1.24 als Teil unserer Unterstützung von Post-Quanten-Kryptografie (PQC). Dies verbessert die TLS-Kommunikation zwischen den Kernkomponenten der Kubernetes-Control Plane wie dem API-Server, Kubelet, Scheduler und Controller-Manager und hilft, sie vor quantenbasierten Angriffen zu schützen.

Die aktuellen Releases von Red Hat Trusted Artifact Signer 1.3 und Trusted Profile Analyzer 2.2 bieten eine leistungsstarke Kombination aus kryptografischen Signierfunktionen und erweiterten Lieferkettenanalysen.

Verteilen und Skalieren von KI/ML-Workloads mit LeaderWorkerSet und JobSet

OpenShift 4.20 vereinfacht das Deployment komplexer verteilter KI-Workloads. Mit dem allgemein verfügbaren LeaderWorkerSet können Plattformteams KI-Modelle, die die Kapazität eines einzelnen Pods überschreiten, effizient verteilen und skalieren, indem ein Leader Pod zur nahtlosen Orchestrierung der Kommunikation zwischen Worker Pods verwendet wird. In Verbindung mit dem als Technologievorschau verfügbaren JobSet, das verteilte Jobs mit flexibler Planung und Fehlertoleranz gruppiert und verwaltet, können Teams vertraute Funktionen wie GitOps, RBAC (Role-based Access Control) und Überwachungsmuster selbst für die anspruchsvollsten ML-Workflows nutzen. Zusammen ermöglichen sie die End-to-End-Orchestrierung von Trainings- (JobSet) und Inferenz-Workloads (LeaderWorkerSet) in großem Umfang und bieten ein robustes, skalierbares und effizientes KI/ML-Lifecycle-Management in OpenShift.

Natives KI-Routing mit Red Hat OpenShift AI 3

KI- und ML-Workloads sind besondere Herausforderungen, aufgrund derer herkömmliche Load Balancing-Strategien wie Round Robin nicht geeignet sind. Red Hat OpenShift AI 3 löst diese Herausforderungen mit verteilter Inferenz mit llm-d und nutzt Kubernetes Gateway API Inference Extensions (GIE). OpenShift 4.20 enthält GIE, das auf der Kubernetes-Gateway-API aufbaut, um spezielles Routing und Datenverkehrsmanagement für KI/ML-Workloads zu ermöglichen. Wenn Sie die Kubernetes Gateway-API bereits für Ihre Anwendungen nutzen, können Sie jetzt denselben deklarativen Ansatz auf die KI-Modellbereitstellung anwenden.

GIE wird in OpenShift 4.20 automatisch verfügbar gemacht, wenn eine InferencePool-Ressource erstellt wird. Eine InferencePool-Ressource stellt eine Reihe von KI- oder ML-Inferenz-Pods und eine „Endpunkt-Auswahl“ dar, die spezielle Routing-Logik enthält. Der llm-d Inferenz-Scheduler, Teil von Red Hat OpenShift AI 3, dient als Endpunkt-Auswahl, indem er von vLLM bereitgestellte Telemetriedaten mit dem Modellserver-Protokoll erfasst und so intelligente Routing-Entscheidungen auf der Basis der besten verfügbaren Modellinstanz zu einem bestimmten Zeitpunkt ermöglicht.

GIE wird mit der Gateway-Implementierung von Istio bereitgestellt, die von Envoy Proxy über OpenShift Service Mesh 3.2 unterstützt wird. Derzeit wird dies nur von Red Hat OpenShift AI 3 unterstützt. Mit GIE können KI-Workloads über dieselben GitOps-Pipelines und RBAC-Richtlinien verwaltet werden. Unabhängig davon, ob Sie ein einzelnes Modell bereitstellen oder eine komplexe Multi-Modell-Inferenz-Pipeline orchestrieren, mit GIE wird aus einer spezialisierten KI-Infrastruktur eine einfache Route in Ihrem Cluster.

Aktualisieren Sie KI-Modelle, ohne Ihre Pods zu ändern

LLMs und ML-Modelle überschreiten häufig 10 GB, wodurch Neuerstellungen von Containern langsam und speicherintensiv werden. Sie müssen Container nicht mehr bei jedem Update Ihres KI-Modells neu erstellen. In OpenShift 4.20 können Sie Modellgewichtungen direkt aus Ihrer Container-Registry als Volumes mounten, sodass Data Scientists neue Modellversionen in die Registry übertragen können, während die Container zur Modellbereitstellung unverändert bleiben. Verweisen Sie einfach auf das OCI-Image in Ihrer Pod-Spezifikation und OpenShift übernimmt den Rest. Jetzt werden Modelle zu versionierbaren Artefakten, die vom Code getrennt sind und bei Bedarf über die vertraute Registry-Authentifizierung abgerufen, für die Performance lokal zwischengespeichert und aktualisiert werden, ohne dass Ihre Deployments davon betroffen sind.

Chatten Sie mit Ihren OpenShift- oder Kubernetes-Clustern in natürlicher Sprache

Wir freuen uns, die Entwicklervorschau des Kubernetes Model Context Protocol (MCP)-Servers für OpenShift und Kubernetes ankündigen zu können. Der Kubernetes MCP-Server revolutioniert das Infrastruktur-Management durch die Vernetzung von KI-Assistenten wie VS Code, Microsoft CoPilot und Cursor mit OpenShift- und Kubernetes-Umgebungen. Mit umfassenden CRUD-Operationen, erweitertem Pod-Management, Helm-Integration und plattformübergreifendem Deployment transformiert der Kubernetes MCP-Server die Cluster-Verwaltung und Fehlerbehebung durch Abfragen in natürlicher Sprache.

Darüber hinaus haben wir mit MCP die Vorfallserkennung in OpenShift Lightspeed integriert. Dies integriert die Vorfallanalyse direkt in die Konversationsschnittstelle und verändert Ihre Vorgehensweise bei der Untersuchung und Behebung von Cluster-Problemen.

Beschleunigen Sie KI-Workloads mit NVIDIA Bluefield-DPUs

Red Hat OpenShift ist als Technologievorschau verfügbar und bietet zusammen mit NVIDIA Bluefield DPUs einen optimierten Ansatz für das Deployment von Sicherheits-, Routing- und Storage-Lösungen für KI-, Telekommunikations- und Unternehmens-Workloads. Diese Lösung bietet Hardwarebeschleunigung und Sicherheitsisolierung für Infrastruktur- und Anwendungs-Workloads, verbessert die Ressourcennutzung und maximiert die Serverkapazität. Bluefield-DPUs (Data Processing Units) sind fester Bestandteil der Spectrum-X- und KI-Factory-Designs von NVIDIA. Künftige OpenShift-Releases ermöglichen eine nahtlose Bereitstellung und Orchestrierung der Spectrum-X-Lösung von NVIDIA sowie der KI-Factory-Designs.

Optimieren Sie das Identitätsmanagement mit nativer OIDC-Unterstützung

OpenShift 4.20 ermöglicht jetzt die direkte Integration mit externen OIDC-Identity-Providern (OpenID Connect), um Token für die Authentifizierung auszustellen, wodurch Sie mehr Kontrolle über Ihre Authentifizierungssysteme erhalten. Durch die direkte Integration mit einem externen OIDC-Anbieter können Sie die erweiterten Funktionen Ihres bevorzugten OIDC-Anbieters nutzen, anstatt durch die Funktionen des integrierten OAuth-Servers eingeschränkt zu werden. Ihr Unternehmen kann Nutzende und Gruppen über eine zentrale Oberfläche verwalten und gleichzeitig die Authentifizierung in mehreren Clustern und Hybrid-Umgebungen optimieren.

Verwalten Sie Workload-Identitäten mit Zero Trust auf OpenShift

Zero Trust Workload Identity Manager wird in den kommenden Wochen in OpenShift 4.20 allgemein verfügbar. Zero Trust Workload Identity Manager bietet Runtime-attestierte und kryptografisch verifizierbare Identitäten für sämtliche Workloads. Zero Trust Workload Identity Manager baut auf SPIFFE/SPIRE auf und bietet zentrale Funktionen wie automatische Workload-Registrierung, SPIRE-to-SPIRE-Föderation für universelles Vertrauen in Hybrid- und Multi-Cloud-Umgebungen, OIDC-Föderation zur Integration in bestehende Identitätssysteme von Unternehmen sowie Secretless-Authentifizierung mit Hashicorp Vault-Integration.

Zero Trust Workload Identity Manager schafft universelles Vertrauen, eliminiert statische Secrets und ermöglicht kurzlebige, verifizierbare Identitäten für eine sicherheitsorientierte Kommunikation zwischen Workloads. Er bietet konsistente, Runtime-zertifizierte Identitäten für cloudnative Workloads, von traditionellen Services bis hin zu neuen agentischen KI-Systemen. Damit sorgt er für Nachverfolgbarkeit und Nachverfolgbarkeit für jede Workload-Aktion und bildet die Basis für Zero Trust-Architekturen für die gesamte Anwendungslandschaft. Zero Trust Workload Identity Manager erfordert OpenShift Platform Plus, Red Hat Advanced Cluster Security for Kubernetes oder Red Hat Advanced Cluster Management Subskriptionen für cloudübergreifendes Workload-Identitätsmanagement bei Verwendung in mehr als einem Cluster. 

Optimieren Sie das Secrets-Management mit dem External Secrets Operator

In OpenShift 4.20 ist der External Secrets Operator for Red Hat OpenShift (ESO) jetzt allgemein verfügbar. ESO ist ein clusterweiter Service, der Lifecycle-Management für Secrets bietet, die von externen Secret-Management-Systemen abgerufen werden. Durch die Integration mit externen Secret-Management-Systemen wie AWS Secrets Manager, HashiCorp Vault und Azure Key Vault führt ESO das Abrufen, Aktualisieren und Provisionieren von Secrets innerhalb des Clusters durch und stellt so sicher, dass vertrauliche Secrets sicherer und effizienter in Workloads fließen, ohne dass Anwendungen direkt beteiligt sind.

Eliminieren Sie das Risiko erweiterter Container-Berechtigungen mit User Namespaces

Mit der allgemeinen Verfügbarkeit von User Namespaces in OpenShift 4.20 ermöglicht Red Hat das Ausführen von Workloads mit verbesserter Isolation und behält gleichzeitig die Flexibilität bei, die Entwicklungsteams für die Entwicklung moderner Anwendungen benötigen. User Namespaces in OpenShift erhöhen die Sicherheit erheblich, indem sie Container-Nutzende von Host-Nutzenden isolieren, das Risiko von Angriffen mit Rechteerweiterung verringern und es Containern ermöglichen, als Nicht-Root-Benutzer auf dem Host ausgeführt zu werden. Die internen Root-Berechtigungen für Vorgänge bleiben dabei erhalten. Dies führt zu sichereren mandantenfähigen Umgebungen und einer besseren Compliance mit Sicherheitsstandards in Unternehmen.

Service Mesh ohne Sidecars mit dem Ambient-Modus von Istio

OpenShift Service Mesh 3.2 bietet allgemein verfügbaren Support für Service Mesh ohne Sidecars mit dem Ambient-Modus von Istio. Es handelt sich hier um eine völlig neue Data Plane für Istio, die 2 Proxy-Ebenen verwendet, um Service Mesh-Funktionen nach Bedarf und mit minimaler zusätzlicher Ressourcennutzung zu aktivieren. 

Der erste Proxy ist zTunnel auf Knotenebene („Z“ für Zero Trust), das Richtlinien für Mutual-TLS-Verschlüsselung, Telemetrie und grundlegende Autorisierungsrichtlinien für Layer 4 bereitstellt. Obwohl es sich um einen Knoten-Proxy handelt, leitet er den Datenverkehr innerhalb des eindeutigen Netzwerk-Namespace jedes Pods um und stellt so sicher, dass der Datenverkehr auf Pod-Ebene isoliert und verschlüsselt wird. Der nächste Proxy ist der anwendungsorientierte Waypoint, der optional bereitgestellt werden kann, um Layer 7-Mesh-Funktionen wie Telemetrie und Richtlinien bereitzustellen, die auf Anwendungsspezifikationen wie HTTP-Anfragetypen oder -Header basieren. 

Diese Architektur reduziert die Ressourcenkosten für die Ausführung eines Service Mesh erheblich, insbesondere für Funktionen, die nur den zTunnel-Proxy erfordern, wie die Pod-zu-Pod-mTLS-Verschlüsselung. Mehr erfahren Sie unter Optimieren von Datenverkehr und Beobachtbarkeit mit OpenShift Service Mesh 3. 

Native BGP-Unterstützung in OpenShift Networking

Red Hat OpenShift Networking bietet jetzt native BGP-Routingfunktionen (Border Gateway Protocol) in seinem Standard-Netzwerk-Plugin „OVN-Kubernetes“. Diese Verbesserung erweitert die zuvor von MetalLB (Load Balancing für externen Service) und dem Cluster Network Operator unterstützten Netzwerk-Use Cases erheblich (Layer 3-Netzwerkstruktur, Multi-Homing, Verbindungsredundanz und schnelle Konvergenz). 

Ab OpenShift 4.20 ermöglicht BGP die direkte Weitergabe von Pod- und VM-Netzwerken (virtuelle Maschinen) im Cluster-Bereich an ein BGP-fähiges Anbieternetzwerk über den BGP-Router des externen Netzwerks. Umgekehrt können mit BGP erlernte Routen vom Anbieternetzwerk wieder in OVN-Kubernetes importiert werden – entweder in das Standard-Pod-Netzwerk oder in ein angegebenes UDN (User-Defined Network). Diese bidirektionale Integration ermöglicht einen nahtlosen Route-Austausch zwischen OpenShift und externen Netzwerkstrukturen. Support ist zunächst für Bare Metal-Plattformen verfügbar, der Support für Cloud-Plattformen ist für ein Folge-Release geplant.

Zur Verbesserung der Skalierbarkeit können optional Routenreflektoren zwischen dem Cluster und externen Netzwerken eingesetzt werden. Ein gängiges Beispiel, das die dynamische Natur und die Vorteile des BGP-basierten Route Advertisements veranschaulicht, ist eine VM-Migration oder ein Failover-Event. Wird eine VM auf einen anderen Knoten verschoben, behält sie ihre statische IP-Adresse bei und die BGP-Tabelle aktualisiert automatisch und schnell die angekündigte Route für das Netzwerk dieser VM, wodurch eine kontinuierliche Konnektivität mit minimalen Unterbrechungen gewährleistet wird.

Erkennen Sie Probleme, bevor Sie den Cluster aktualisieren

In OpenShift 4.20 bieten 2 neue Befehle den Nutzenden Einblick in potenzielle Probleme vor und während Updates. Die Befehle oc adm upgrade recommend und oc adm upgrade status sind jetzt allgemein verfügbar. 

Bevor Sie mit einem Update beginnen, analysiert oc adm upgrade recommend den Cluster auf bekannte Warnmeldungen. Es werden Alarme angezeigt, die Probleme verursachen, wie PodDisruptionBudgets am Limit, nicht verfügbare Cluster-Operatoren oder Alarme, die die Leerung von Knoten verlangsamen können. Sie sehen dann, welche Versionen in Ihrem Update-Kanal verfügbar sind, welche Probleme mit diesen Releases bekannt sind und, was noch wichtiger ist, welche Bedingungen im Vergleich zum normalen Cluster-Verhalten tatsächlich problematisch sind. 

$ oc adm upgrade recommend
Failing=True:
Reason: ClusterOperatorNotAvailable
Message: Cluster operator monitoring is not available
The following conditions found no cause for concern in updating this cluster to later releases: recommended/NodeAlerts (AsExpected), recommended/PodImagePullAlerts (AsExpected)
The following conditions found cause for concern in updating this cluster to later releases: recommended/PodDisruptionBudgetAlerts/PodDisruptionBudgetAtLimit/1
recommended/PodDisruptionBudgetAlerts/PodDisruptionBudgetAtLimit/1=False:
Reason: Alert: firing
Message: warning alert PodDisruptionBudgetAtLimit firing, which might slow node drains. Namespace=openshift-monitoring, PodDisruptionBudget-prometheus-k8s. The pod disruption budget is preventing further disruption to pods. The alert description is: The pod disruption budget is at the minimum disruptions allowed level. The number of current healthy pods is equal to the desired healthy pods.
https://github.com/openshift/runbooks/blob/master/alerts/cluster-kube-controller-manager-operator/PodDisruptionBudgetAtLimit.md
Upstream update service: https://api.integration.openshift.com/api/upgrades_info/graph
Channel: candidate-4.18 (available channels: candidate-4.18, candidate-4.19, candidate-4.18, eus-4.18, fast-4.18, fast-4.19, stable-4.18, stable-4.19)
Updates to 4.18:
VERSION    ISSUES
4.18.32    no known issues relevant to this cluster
4.18.30    no known issues relevant to this cluster
And 2 older 4.18 updates you can see with '--show-outdated-releases' or '--version VERSION'.

Nach dem Update zeigt oc adm upgrade status den Nutzenden in Echtzeit an, was gerade passiert: Fortschritt von Control Plane und Workerknoten, Prozentsätze für Fertigstellung, Zeitschätzungen und Warnungen, wenn ein Problem auftritt. Beide Befehle sind schreibgeschützt und ändern nichts im OpenShift Cluster. Mehr erfahren Sie unter Aktualisieren eines Clusters mithilfe des CLI.

Edge-Deployments mit 2 Knoten in OpenShift optimieren

Optimieren Sie Ihre Edge-Deployments mit OpenShift für 2 Knoten mit Arbiter. Dies bietet die gleichen Hochverfügbarkeitsmerkmale wie ein standardmäßiger OpenShift-Cluster mit 3 Knoten, erfordert aber nur 2 vollwertige Server, ergänzt durch einen schlanken Arbiter-Knoten für Quorum. 

Der Arbiter-Knoten wird als dritte etcd-Instanz für Quorum mit nur 2 vCPUs und 8 GB Arbeitsspeicher ausgeführt. In der Zwischenzeit verarbeiten die beiden großen Knoten den gesamten eigentlichen Workload, während der kleine Arbiter sicherstellt, dass der Cluster den Ausfall eines einzelnen Knotens tolerieren kann, ohne die Verfügbarkeit zu verlieren. Es sind nur 2 Bare Metal-Subskriptionen erforderlich, und für den Arbiter-Knoten fallen keine Lizenzierungskosten an. Mehr erfahren Sie unter Effiziente Infrastruktur mit 2 Knoten, bereitgestellt von Red Hat OpenShift und Portworx/Pure Storage.

Lastbewusstes Rebalancing und schnellere VM-Migration in Red Hat OpenShift Virtualization 4.20

Lastbewusstes Rebalancing auf Basis der CPU-Kapazität ist in Red Hat OpenShift Virtualization 4.20 jetzt ebenfalls allgemein verfügbar. Dies verbessert die Workload-Verteilung auf Cluster-Knoten, indem die Echtzeit-Ressourcenauslastung der Knoten dynamisch berücksichtigt und VMs von überlasteten Knoten zu Knoten mit verfügbarer Kapazität migriert werden.

OpenShift Virtualization bietet außerdem vereinfachtes VM-Management mit Multi-Cluster-Funktionen, beschleunigte Migration zu OpenShift durch das Migrations-Toolkit für die Virtualisierungs, Storage-Auslagerung von Lösungen wichtiger Storage-Anbieter, Live-Migration zu einem spezifischen Knoten und erweiterten ARM-Support. Netzwerkverbesserungen, wie BGP für benutzerdefinierte L2-Netzwerke, steigern die Effizienz und Flexibilität für virtualisierte Workloads weiter.

Skalieren von Virtualisierungs-Workloads in Oracle Cloud Infrastructure

OpenShift Virtualization auf Bare Metal-Instanzen in Oracle Cloud Infrastructure ist jetzt allgemein verfügbar. Dies gibt unseren gemeinsamen Kunden die Flexibilität, ihre VM-Workloads ortsunabhängig über die verteilte Cloud von OCI auszuführen. Mehr erfahren Sie unter Potenzial der Virtualisierung auf OCI in großem Umfang.

Erweiterung von OpenShift in souveräne Clouds von Oracle

Darüber hinaus erweitert OpenShift den Support für Oracle Cloud Infrastructure und konzentriert sich dabei insbesondere auf souveräne Clouds wie Oracle EU Sovereign Cloud, Oracle US Government Cloud, Oracle Cloud for UK Government & Defence, Oracle Cloud Cloud Isolated Regions und Oracle Alloy. Diese Erweiterung bietet Unternehmen mehr Flexibilität und Auswahl bei der Bereitstellung von OpenShift in Clouds, die wichtige Anforderungen in Bezug auf Datenhoheit, Compliance und verbesserte Sicherheit in spezialisierten Cloud-Umgebungen erfüllen. Mehr erfahren Sie unter Erweiterter Support für Oracle Cloud Infrastructure.

Testen Sie Red Hat OpenShift 4.20 noch heute

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 und finden Sie heraus, was Sie als Nächstes tun können:

• Neuerungen und nächste Schritte in Red Hat OpenShift
• Neuerungen in Red Hat OpenShift 4.20
• Testen Sie weitere interaktive Demos von OpenShift 4.20
• In the Clouds
• YouTube-Kanal zu OpenShift
• OpenShift Blogs
• OpenShift Commons
• Red Hat Developer Blogs
• Red Hat Portfolio Architecture Center
• Validated Patterns

Die vollständige Liste der Red Hat OpenShift 4.20 Updates finden Sie in den OpenShift 4.20 Release Notes. Senden Sie uns Feedback über Ihre Kontakte bei Red Hat oder erstellen Sie einen Eintrag auf GitHub.