Red Hat lanserer OpenShift 5 med agentbasert klyngedrift

Red Hat kunngjorde at OpenShift 5 er allment tilgjengelig 9. november 2026 på KubeCon + CloudNativeCon North America. Lanseringen gir agentbasert feilsøking og én samlet driftsplattform for AI-arbeidsbelastninger, virtuelle maskiner og containere. Den Kubernetes-baserte versjonen er tilgjengelig for kunder med eksisterende abonnementer via Red Hat Customer Portal.

Red Hat kombinerer lanseringen med en oppdatering på stedet fra OpenShift 4.22 og en lengre støtteperiode. Dermed tar selskapet tak i to driftsmessige hindringer for å ta i bruk en ny plattformgenerasjon. Den tekniske oversikten skiller også tydelig mellom funksjonene: Overvåkede agentbaserte arbeidsflyter inngår i lanseringen, mens autonom feilsøking og en oppdateringsagent fortsatt er tilgjengelige som teknologiforhåndsvisninger.

Agentbasert drift med godkjenning fra mennesker

OpenShift Lightspeed går lenger enn den tidligere rollen som samtaleassistent: Den undersøker varsler og presenterer funn og forslag til utbedring på naturlig språk. I overvåket modus venter den på bekreftelse fra en administrator før den gjør endringer i klyngen. Den autonome forhåndsvisningen kan gjennomføre grundigere undersøkelser på egen hånd, men stanser også for å få endelig godkjenning fra et menneske før endringene utføres. Ingen av modusene fjerner dermed kravet om godkjenning før utføring.

Den samme driftsmodellen gjelder også ved vedlikehold. Oppdateringsveiledningen, som er utvidet med Lightspeed, kartlegger klyngestatus, mulige konflikter og konsekvensomfang før et vedlikeholdsvindu. Forhåndskontroller vurderer samtidig API-kompatibilitet og valgfrie operatører. En separat operatørplanlegger samler informasjon om livssyklusstatus, klyngekompatibilitet og tilgjengelige oppdateringer. Oppdateringsagenten, som er i forhåndsvisning, går et skritt videre ved å hjelpe til med å planlegge og gjennomføre oppdateringsløp.

OpenShift Model Context Protocol-serveren og MCP-gatewayen via Red Hat Connectivity Link, som kobler agenter til plattformtjenester, er allment tilgjengelige. MCP gir agentene en styrt kanal for tilgang til plattformens API-er og tjenester. Administratorer kan også opprette Perses-dashbord for observerbarhet gjennom en samtale, i stedet for å sette sammen spørringer manuelt.

Sikkerhet for AI og delte klynger

OpenShift 5 gjør flere sikkerhetstiltak til standardinnstillinger på plattformen. Postkvantekryptografi beskytter kommunikasjonen i kontrollplanet, og støtte for kvantedatamaskiner er bygget inn i plattformavbildningene og TLS-konfigurasjonen. En sentralisert og håndhevet TLS-policy gjelder for både OpenShift-kjernen og lagdelte produkter, mens tilpassede nettverkspolicyer begrenser trafikken inn i og ut av navnerommene for kontrollplanets operander. Automatisert håndtering av sertifikaters livssyklus og innebygd støtte for frakoblede distribusjoner dekker behovene i isolerte miljøer, ved ytterkanten av nettverket og i regulerte miljøer.

For AI-arbeidsbelastninger krypterer konfidensielle containere modellvekter både når de er lagret og når de er i bruk. Red Hat-versjonen av Agent Sandbox, som også er en teknologiforhåndsvisning, bruker OpenShift sandboxed containers til å kjøre agentarbeidsbelastninger i virtuelle maskiner. Dette skaper en avgrensning som skal hindre at kode som ikke er klarert, eller autonom kode, får ubegrenset tilgang til resten av klyngen. Beskyttelsen håndterer risikoen som oppstår når agenter genererer og kjører kode som administratorer ikke har gjennomgått.

For blandede miljøer bruker OpenShift Virtualization 5 Lightspeed og integrasjon med MCP til å klargjøre virtuelle maskiner og automatisere arbeidsflyter med naturlig språk. Lagringsuavhengig, inkrementell sikkerhetskopiering bruker QEMU Change Block Tracking til å kopiere endrede blokker i stedet for fullstendige virtuelle diskavbildninger. Minnebevisst lastbalansering og innebygd swap justerer tildelingene ut fra faktisk forbruk. Red Hat sier også at automatisk oppdeling av GPU-ressurser for databehandling er utviklet for å øke maskinvareutnyttelsen både for AI-slutninger og tradisjonelle arbeidsbelastninger i bedrifter.

Oppdateringer på stedet og fem års støtte

Oppdateringsløpet krever ikke et umiddelbart bytte av operativsystem. Klynger som oppdateres fra OpenShift 4.22, forblir på Red Hat Enterprise Linux CoreOS 9, mens nyopprettede OpenShift 5.0-klynger som standard bruker CoreOS 10. Red Hat planlegger å la CoreOS 9- og CoreOS 10-noder sameksistere i én klynge i en framtidig versjon. Dette er ikke en funksjon i OpenShift 5.0.

Red Hat innfører en treårig syklus for hovedversjoner, som kommer omtrent ett år etter hovedversjonene av Red Hat Enterprise Linux. Den inkluderte støtten varer i 24 måneder, fordelt på ett år med full støtte og ett år med vedlikeholdsstøtte.

Red Hat planlegger én Extended Life Cycle-versjon hvert år, med fem hele år med bedriftsstøtte gjennom et tillegg på tre år utover de inkluderte periodene. Den femårige livssyklusen omfatter også valgfrie operatører, blant annet Red Hat Advanced Cluster Security, OpenShift Service Mesh, OpenShift Pipelines og OpenShift GitOps.

Den umiddelbare betydningen av OpenShift 5 ligger i kombinasjonen av dette oppdateringsløpet og strammere driftskontroll: OpenShift 4.22-klynger kan oppdateres på stedet, men plattformens mest autonome funksjoner krever fortsatt godkjenning og er fremdeles forhåndsvisninger. Lanseringen tar dermed agentbasert assistanse inn i produksjonsstyringen av klynger uten å gjøre autonom utføring til standard. Samtidig gir den lengre livssyklusen infrastrukturt teamene større handlingsrom til å samordne driften av AI, virtuelle maskiner og containere.