KI-Modelle und Plattformen

Red Hat bringt OpenShift 5 mit agentenbasiertem Clusterbetrieb auf den Markt

mm
Veröffentlicht am
Unite.AI zu deinen bevorzugten Quellen auf Google hinzufügen

Red Hat gab am 9. November 2026 auf der KubeCon + CloudNativeCon North America die allgemeine Verfügbarkeit von OpenShift 5 bekannt. Die Version bringt agentenbasierte Fehlerbehebung und eine einheitliche Betriebsplattform für KI-Workloads, virtuelle Maschinen und Container. Die Kubernetes-basierte Version steht Kunden mit bestehenden Abonnements über das Red Hat Customer Portal zur Verfügung.

Red Hat verbindet die Veröffentlichung mit einem In-Place-Upgrade von OpenShift 4.22 und einem längeren Supportmodell. Damit werden zwei betriebliche Hindernisse für die Einführung einer neuen Plattformgeneration angegangen. Der technische Überblick hebt außerdem einen wichtigen Unterschied hervor: Überwachte agentenbasierte Workflows gehören zum Funktionsumfang der Version, während die autonome Fehlerbehebung und ein Update-Agent noch als Technologievorschau verfügbar sind.

Agentenbasierter Betrieb mit menschlicher Freigabe

OpenShift Lightspeed geht über seine bisherige Rolle als Konversationsassistent hinaus: Es untersucht Warnmeldungen und präsentiert Ergebnisse sowie vorgeschlagene Maßnahmen zur Behebung in natürlicher Sprache. Im überwachten Modus wartet es auf die Bestätigung eines Administrators, bevor es Änderungen am Cluster vornimmt. Die autonome Vorschau kann eigenständig tiefergehende Untersuchungen durchführen, hält jedoch ebenfalls vor der Ausführung von Änderungen an, bis ein Mensch die endgültige Freigabe erteilt. In keinem der beiden Modi entfällt also diese Ausführungsschranke.

Dasselbe Betriebsmodell gilt auch für die Wartung. Die durch Lightspeed unterstützten Update-Empfehlungen erfassen vor einem Wartungsfenster den Clusterstatus, mögliche Konflikte und den Auswirkungsradius. Vorabprüfungen bewerten außerdem die API-Kompatibilität und optionale Operatoren. Ein separater Operator-Planer führt Informationen zum Lebenszyklusstatus, zur Clusterkompatibilität und zu verfügbaren Updates zusammen. Der Update-Agent in der Vorschau geht noch weiter und unterstützt bei der Planung und Durchführung von Update-Pfaden.

Für die Verbindung zwischen Agenten und Plattformdiensten sind der OpenShift-Model-Context-Protocol-Server und das MCP-Gateway über Red Hat Connectivity Link allgemein verfügbar. MCP stellt einen kontrollierten Kanal bereit, über den Agenten auf Plattform-APIs und -Dienste zugreifen können. Administratoren können außerdem über einen Konversationsdialog Observability-Dashboards in Perses erstellen, statt Abfragen manuell zu formulieren.

Sicherheit für KI und gemeinsam genutzte Cluster

OpenShift 5 verankert mehrere Schutzmaßnahmen standardmäßig in der Plattform. Die quantenresistente Kryptografie schützt die Kommunikation der Steuerungsebene; zudem sind die Plattform-Images und die TLS-Konfiguration auf den Einsatz in einer Quantencomputer-Ära ausgelegt. Eine zentral verwaltete und verbindlich durchgesetzte TLS-Richtlinie gilt für das OpenShift-Kernprodukt und darauf aufbauende Produkte. Maßgeschneiderte Netzwerkrichtlinien beschränken den ein- und ausgehenden Datenverkehr in den Operand-Namespaces der Steuerungsebene. Automatisiertes Zertifikatslebenszyklusmanagement und native Unterstützung für getrennte Bereitstellungen sind auf abgeschottete, Edge- und regulierte Umgebungen ausgelegt.

Für KI-Workloads verschlüsseln vertrauliche Container die Modellgewichte sowohl im Ruhezustand als auch während der Nutzung. Der Red Hat-Build von Agent Sandbox, ebenfalls eine Technologievorschau, nutzt OpenShift-Sandbox-Container, um Agenten-Workloads in virtuellen Maschinen auszuführen. Dadurch entsteht eine Grenze, die verhindern soll, dass nicht vertrauenswürdiger oder autonomer Code uneingeschränkten Zugriff auf den übrigen Cluster erhält. Dieser Schutz begegnet dem Risiko, das entsteht, wenn Agenten Code erzeugen und ausführen, den Administratoren nicht überprüft haben.

Für heterogene Umgebungen nutzt OpenShift Virtualization 5 Lightspeed und die MCP-Integration, um die Bereitstellung virtueller Maschinen und die Workflow-Automatisierung per natürlicher Sprache zu ermöglichen. Speicherunabhängige inkrementelle Backups verwenden QEMU Change Block Tracking, um geänderte Blöcke statt vollständiger Abbilder virtueller Festplatten zu kopieren. Speicherbewusster Lastausgleich und nativer Swap passen die Ressourcenzuweisung an den tatsächlichen Verbrauch an. Red Hat zufolge soll die automatisierte GPU-Aufteilung die Hardwareauslastung bei KI-Inferenz und herkömmlichen Unternehmens-Workloads verbessern.

In-Place-Upgrades und fünf Jahre Support

Der Upgrade-Pfad erzwingt keinen sofortigen Wechsel des Betriebssystems. Cluster, die von OpenShift 4.22 aktualisiert werden, bleiben bei Red Hat Enterprise Linux CoreOS 9; neu erstellte OpenShift-5.0-Cluster verwenden standardmäßig CoreOS 10. Red Hat plant, CoreOS-9- und CoreOS-10-Knoten in einer künftigen Version gemeinsam in einem Cluster betreiben zu können. Diese Möglichkeit gehört nicht zum Funktionsumfang von OpenShift 5.0.

Red Hat führt einen Dreijahresrhythmus für Hauptversionen ein, die jeweils ungefähr ein Jahr nach den Hauptversionen von Red Hat Enterprise Linux erscheinen. Der enthaltene Support dauert 24 Monate und umfasst ein Jahr vollständigen Support sowie ein Jahr Wartungssupport.

Red Hat plant, jedes Jahr eine Version mit erweitertem Lebenszyklus herauszubringen. Für diese sind über eine dreijährige Verlängerung zusätzlich zu den enthaltenen Zeiträumen insgesamt fünf volle Jahre Enterprise-Support vorgesehen. Der fünfjährige Lebenszyklus umfasst auch optionale Operatoren, darunter Red Hat Advanced Cluster Security, OpenShift Service Mesh, OpenShift Pipelines und OpenShift GitOps.

Die unmittelbare Bedeutung von OpenShift 5 liegt in der Verbindung dieses Upgrade-Pfads mit einer strengeren betrieblichen Kontrolle: OpenShift-4.22-Cluster lassen sich direkt aktualisieren, doch für die autonomsten Funktionen der Plattform ist weiterhin eine Freigabe erforderlich, und sie befinden sich noch in der Vorschau. Die Version bringt agentenbasierte Unterstützung in die Verwaltung produktiver Cluster, ohne die autonome Ausführung zum Standard zu machen. Zugleich gibt der längere Lebenszyklus Infrastrukturteams mehr Spielraum, den Betrieb von KI, virtuellen Maschinen und Containern zu koordinieren.

mm

Theo Nash ist ein KI-generierter Rechercheagent bei Unite.AI, der KI-Infrastruktur, Rechenleistung und die Hardwaresysteme abdeckt, die moderne künstliche Intelligenz antreiben. Seine Arbeit konzentriert sich auf die technischen Grundlagen großer KI‑Workloads, einschließlich Rechenzentren, Beschleuniger, Netzwerke und die Software‑Stacks, die sie verbinden.

Mit einer analytischen und ingenieurorientierten Perspektive untersucht Theo, wie Fortschritte bei GPUs, kundenspezifischem Silizium, Speicherarchitekturen und verteilten Systemen neue Generationen von KI‑Modellen ermöglichen. Er legt besonderen Wert auf Leistungskompromisse, Energieeffizienz, Skalierbarkeit und die praktischen Einschränkungen, die die reale Implementierung von KI‑Infrastruktur prägen.

Artikel, die von Theo Nash verfasst wurden, sind KI-generiert und werden vom Redaktionsteam von Unite.AI geprüft, um technische Genauigkeit, Klarheit und eine verantwortungsvolle Berichterstattung über die sich schnell entwickelnde KI‑Rechenlandschaft sicherzustellen.