Red Hat lancerer OpenShift 5 med agentbaseret klyngeadministration

Red Hat annoncerede den generelle tilgængelighed af OpenShift 5 den 9. november 2026 på KubeCon + CloudNativeCon North America. Udgivelsen introducerer agentbaseret fejlfinding og én samlet driftsplatform til AI-arbejdsbelastninger, virtuelle maskiner og containere. Den Kubernetes-baserede version er tilgængelig for kunder med eksisterende abonnementer via Red Hat Customer Portal.

Red Hat kombinerer udgivelsen med en opdatering på stedet fra OpenShift 4.22 og en længere supportmodel for at imødegå to driftsmæssige hindringer for at tage en ny platformgeneration i brug. Den tilhørende tekniske oversigt fremhæver også en vigtig forskel: Overvågede agentbaserede arbejdsgange er en del af udgivelsen, mens autonom fejlfinding og en opdateringsagent fortsat er teknologiforhåndsvisninger.

Agentbaseret drift med menneskelig godkendelse

OpenShift Lightspeed går videre end sin tidligere rolle som samtalebaseret assistent: Den undersøger alarmer og præsenterer resultater og forslag til afhjælpning på naturligt sprog. I overvåget tilstand afventer den en administrators bekræftelse, før den foretager ændringer i klyngen. Forhåndsvisningen af den autonome funktion kan på egen hånd foretage mere dybtgående undersøgelser, men standser også for at afvente en endelig menneskelig godkendelse, før ændringer udføres. Ingen af tilstandene fjerner altså kravet om godkendelse før udførelse.

Den samme driftsmodel gælder også ved vedligeholdelse. Opdateringsvejledning med hjælp fra Lightspeed kortlægger klyngens status, mulige konflikter og konsekvensernes omfang før et vedligeholdelsesvindue, mens indledende kontroller vurderer API-kompatibilitet og valgfrie operatorer. Et separat planlægningsværktøj til operatorer samler oplysninger om livscyklusstatus, klyngekompatibilitet og tilgængelige opdateringer. Opdateringsagenten, der er tilgængelig som forhåndsvisning, går et skridt videre ved at hjælpe med at planlægge og gennemføre opdateringsforløb.

OpenShift Model Context Protocol-serveren og MCP-gatewayen via Red Hat Connectivity Link er nu generelt tilgængelige til at forbinde agenter med platformtjenester. MCP giver agenter en styret kanal til platformens API’er og tjenester. Administratorer kan også oprette Perses-dashboards til overvågning via en samtalegrænseflade i stedet for at udforme forespørgsler manuelt.

Sikkerhed til AI og delte klynger

OpenShift 5 gør flere sikkerhedsforanstaltninger til standardindstillinger på platformen. Postkvantekryptering beskytter kommunikationen i kontrolplanet, og platformaftryk og TLS-konfiguration er klargjort til kvanteteknologi. En centraliseret, håndhævet TLS-politik gælder på tværs af OpenShift-kernen og lagdelte produkter, mens tilpassede netværkspolitikker begrænser trafik ind i og ud af kontrolplanets operand-navnerum. Automatiseret håndtering af certifikaters livscyklus og indbygget understøttelse af installationer uden netværksforbindelse imødekommer behovene i isolerede miljøer, ved edge-installationer og i regulerede miljøer.

Til AI-arbejdsbelastninger krypterer fortrolige containere modellens vægte, både når de er gemt, og når de er i brug. Red Hat-versionen af Agent Sandbox, der også er en teknologiforhåndsvisning, bruger OpenShift-sandkassecontainere til at placere agenters arbejdsbelastninger i virtuelle maskiner. Det skaber en afgrænsning, der skal forhindre ikke-betroet eller autonom kode i at få ubegrænset adgang til resten af klyngen. Denne beskyttelse imødegår den risiko, der opstår, når agenter genererer og udfører kode, som administratorer ikke har gennemgået.

Til blandede IT-miljøer bruger OpenShift Virtualization 5 Lightspeed og MCP-integration til klargøring af virtuelle maskiner på naturligt sprog og automatisering af arbejdsgange. Lagringsuafhængig, trinvis sikkerhedskopiering bruger QEMU Change Block Tracking til at kopiere ændrede blokke i stedet for komplette virtuelle diskaftryk, mens hukommelsesbevidst belastningsbalancering og indbygget swap justerer allokeringerne efter det faktiske forbrug. Red Hat oplyser også, at virksomhedens automatiserede GPU-opdeling er udviklet til at forbedre udnyttelsen af hardware på tværs af AI-slutninger og traditionelle arbejdsbelastninger i virksomheder.

Opdateringer på stedet og fem års support

Opdateringsforløbet kræver ikke en øjeblikkelig ændring af operativsystemet. Klynger, der opdateres fra OpenShift 4.22, forbliver på Red Hat Enterprise Linux CoreOS 9, mens nyoprettede OpenShift 5.0-klynger som standard bruger CoreOS 10. Red Hat planlægger at gøre det muligt at have CoreOS 9- og CoreOS 10-noder side om side i én klynge i en fremtidig udgivelse; dette er ikke en funktion i OpenShift 5.0.

Red Hat indfører en kadence på tre år mellem større udgivelser, omtrent ét år efter større udgivelser af Red Hat Enterprise Linux. Den inkluderede support varer 24 måneder fordelt på ét år med fuld support og ét år med vedligeholdelsessupport.

Red Hat planlægger én Extended Life Cycle-udgivelse om året, der er dækket af fem hele års virksomhedssupport gennem et tilkøb, som forlænger den inkluderede periode med tre år. Den femårige livscyklus omfatter også valgfrie operatorer, herunder Red Hat Advanced Cluster Security, OpenShift Service Mesh, OpenShift Pipelines og OpenShift GitOps.

OpenShift 5’s umiddelbare betydning ligger i kombinationen af opdateringsforløbet og en strammere driftsmæssig kontrol: OpenShift 4.22-klynger kan opdateres på stedet, men platformens mest autonome funktioner kræver stadig godkendelse og er fortsat forhåndsvisninger. Udgivelsen indfører dermed agentbaseret assistance i den daglige administration af produktionsklynger uden at gøre autonom udførelse til standard. Samtidig giver den længere livscyklus infrastrukturteams bedre mulighed for at koordinere driften af AI, virtuelle maskiner og containere.