Kubernetes 1.37 ble sluppet onsdag 26. august 2026, og utgivelsen bryter med en nettverksstandard som har ligget i bunnen av prosjektet siden 2016. Samtidig blir metrics.k8s.io, API-et som driver kubectl top og Horizontal Pod Autoscaler, endelig generelt tilgjengelig etter ni år i beta. For drifts- og plattformteam i Norge og resten av Norden betyr det en ny runde med testing før produksjonsklynger kan oppgraderes trygt.
Lanseringen kommer på et tidspunkt der Kubernetes ifølge Cloud Native Computing Foundation (CNCF) sin årlige undersøkelse, publisert 20. januar 2026, kjøres i produksjon av 82 % av alle som bruker containere. 98 % av de spurte organisasjonene oppgir at de har tatt i bruk skyfødte teknikker, og 66 % av virksomhetene som satser på kunstig intelligens bruker Kubernetes til å skalere inferens-arbeidslaster. Kubernetes 1.37 er dermed ikke bare en teknisk oppdatering, det er neste steg for en plattform CNCF omtaler som selve driftssystemet for AI i virksomheter.
Kubernetes 1.37: de viktigste tallene
Utviklingsløpet fulgte prosjektets vanlige kvartalsvise rytme. Funksjonsfrys (feature freeze) landet 17. juni 2026, kodefrys fulgte 22.-23. juli, og den første release candidate, 1.37.0-rc.0, ble sluppet 6. august. En andre kandidat, rc.1, kom 19. august, før den endelige versjonen, 1.37.0, ble generelt tilgjengelig 26. august 2026. Fra funksjonsfrys til GA tok det med andre ord litt over ti uker, en tidslinje som har holdt seg stabil gjennom flere utgivelsessykluser.
Under overflaten er 1.37 en tett pakke: en API som går fra beta til generelt tilgjengelig, en sikkerhetsfunksjon som slås på som standard og kan brekke eksisterende klynger, fjerning av utsatte kubelet-flagg, og flere funksjoner innen Dynamic Resource Allocation (DRA) som peker rett mot GPU- og AI-arbeidslaster. Release-teamet selv har trukket fram tre endringer plattformteam faktisk må planlegge rundt: DRA til GA, pod-sertifikater til GA, og stabilisering av vertikal skalering av poder mens de kjører.
| Milepæl | Dato |
|---|---|
| Funksjonsfrys (feature freeze) | 17. juni 2026 |
| Kodefrys (code freeze) | 22.-23. juli 2026 |
| Release candidate 1.37.0-rc.0 | 6. august 2026 |
| Release candidate 1.37.0-rc.1 | 19. august 2026 |
| Generelt tilgjengelig (GA) | 26. august 2026 |
Tre endringer som kan knekke eksisterende klynger
Den mest omtalte endringen i 1.37 er at SELinuxMount nå er stabil og slått på som standard. Funksjonen endrer hvordan hele volumer relabeles for SELinux, og i klynger som kjører med SELinux i enforcing-modus kan den nye oppførselen stoppe poder fra å starte. Dette rammer i praksis RHEL- og Fedora-baserte noder oftere enn Ubuntu- og Debian-baserte oppsett, som er mer vanlige i norske skymiljøer, men alle med blandede operativsystemer bør validere funksjonen i et testmiljø før oppgradering.
Den andre endringen gjelder kubelet-konfigurasjon. Flagg som ble varslet fjernet allerede i versjon 1.36 er nå borte for godt i 1.37, og enkelte av disse endringene forutsetter containerd 2.0 eller nyere som kjøretidsmiljø. Team som fortsatt kjører eldre containerd-versjoner må oppgradere kjøretidsmiljøet før de kan gå videre til 1.37, noe som gjør denne utgivelsen til en to-trinns oppgradering for en del klynger.
Den tredje endringen er mindre synlig for sluttbrukere, men viktig for prosjektets langsiktige helse: KEP #6164, som fjerner interne API-typer (__internal) fra apiserveren. Dette er fortsatt på alfa-stadiet i sig-api-machinery og påvirker ikke arbeidslaster direkte, men det er et tegn på at Kubernetes-prosjektet fortsetter å rydde opp i teknisk gjeld etter over ti år med utvikling.
| Endring | Status i 1.37 | Hva det betyr i praksis |
|---|---|---|
| metrics.k8s.io (Metrics API) | Generelt tilgjengelig | kubectl top og Horizontal Pod Autoscaler får et stabilt API etter ni år i beta |
| SELinuxMount | Stabil, på som standard | Kan stoppe poder i klynger med SELinux i enforcing-modus |
| Eldre kubelet-flagg fra 1.36 | Fjernet | Krever containerd 2.0 eller nyere på nodene |
| Interne API-typer (KEP #6164) | Ny alfa-funksjon | Forenkler apiserveren internt, ingen umiddelbar brukerpåvirkning |
| DRAResourceClaimDeviceStatus | Generelt tilgjengelig | Bedre statusrapportering for GPU- og akseleratorressurser |
| Pod-sertifikater (PodCertificateRequest) | Generelt tilgjengelig | Automatisk sertifikatutstedelse for arbeidslaster, aktivert som standard |
| gRPC-probe med TLS | Ny funksjon i kubelet | Krypterte helsesjekker mellom kubelet og containere |
Metrics-API-et blir voksent etter ni år
Historien om metrics.k8s.io illustrerer hvor sakte enkelte deler av Kubernetes modnes. API-et har levd i beta siden prosjektets tidlige år og har likevel vært selve grunnmuren for autoskalering i så godt som alle klynger som kjører Horizontal Pod Autoscaler. Med generell tilgjengelighet i 1.37 får verktøy som er bygget rundt kubectl top og HPA endelig et API med formelle stabilitetsgarantier, noe som gjør det tryggere for verktøyleverandører å bygge videre på det uten frykt for brytende endringer i fremtidige versjoner.
For plattformteam betyr dette i seg selv ingen umiddelbar handling. Klynger som allerede bruker metrics-server og HPA vil fortsette å fungere som før. Det som endrer seg er tilliten til API-et som grunnlag for nye interne verktøy, kostnadsstyring og kapasitetsplanlegging, siden en stabil API-kontrakt normalt fjerner den siste bremseklossen for bredere kommersiell og intern verktøybygging.
DRA og AI-arbeidslaster: Kubernetes som GPU-plattform
Dynamic Resource Allocation, forkortet DRA, er mekanismen som lar Kubernetes reservere og dele spesialisert maskinvare som GPU-er på en mer fleksibel måte enn det gamle systemet med faste ressursgrenser. I 1.37 når DRAResourceClaimDeviceStatus generell tilgjengelighet, samtidig som første versjon av DRAResourceHealth forfremmes videre i modenhetsstigen. Til sammen gir dette klyngeadministratorer bedre innsyn i hvilke GPU-er som faktisk er friske og i bruk, noe som blir stadig viktigere når AI-treningsjobber og inferenstjenester deler den samme maskinvaren.
Dette henger sammen med CNCFs karakteristikk av Kubernetes som driftssystemet for AI i virksomheter. Når 66 % av AI-satsende organisasjoner allerede bruker Kubernetes til å skalere inferens, blir modenheten til DRA en direkte forutsetning for hvor godt plattformen kan konkurrere med mer spesialiserte MLOps-løsninger. Norske selskaper som bygger AI-infrastruktur på hydrokraft-drevne datasentre i Norge vil trolig ha nytte av bedre GPU-styring etter hvert som flere store treningsklynger legges til landet.
Sikkerhet: pod-sertifikater og krypterte probe-kall
På sikkerhetssiden er den største nyheten at Pod Certificates går til generell tilgjengelighet, med feature-porten PodCertificateRequest satt til sann som standard. Funksjonen automatiserer utstedelse av korte, arbeidslastspesifikke sertifikater direkte fra klyngen, noe som reduserer behovet for eksterne certificate managers i mange oppsett og gjør identitetshåndtering mellom tjenester enklere å holde konsistent.
I tillegg støtter kubelet nå gRPC-baserte container-prober med TLS, slik at helsesjekker mellom kubelet og containere kan krypteres. Kombinert med at pod-sertifikater er lettere tilgjengelig, gir dette et mer solid utgangspunkt for zero-trust-arkitektur inne i klyngen, noe som er relevant for virksomheter som allerede jobber mot NIS2-krav om sikker intern kommunikasjon.
Slik ruller AKS, EKS og GKE ut støtte for 1.37
De tre store skyleverandørene følger ulikt tempo når det gjelder å tilby administrert støtte for en ny Kubernetes-versjon. Microsoft har publisert en konkret tidslinje for Azure Kubernetes Service (AKS): forhåndsvisning i september 2026, generell tilgjengelighet i oktober 2026, og standard support som varer til oktober 2027, med en utvidet støtteperiode til oktober 2028 for kunder som betaler for det. AKS følger en tolv måneders støttepolicy for GA-versjoner, et mønster som gjentar seg for hver Kubernetes-versjon Microsoft tar inn.
AWS og Google hadde ved publiseringstidspunktet ikke offentliggjort tilsvarende eksakte datoer for når Elastic Kubernetes Service (EKS) og Google Kubernetes Engine (GKE) tar inn 1.37. Basert på tidligere versjoner pleier begge å legge til støtte i løpet av åtte til tolv uker etter at en versjon blir generelt tilgjengelig oppstrøms, men det er ingen garanti, og team som planlegger migrering bør sjekke leverandørenes egne versjonssider løpende fremfor å anta faste datoer.
| Tjeneste | Forhåndsvisning | Generell tilgjengelighet | Slutt på standard støtte |
|---|---|---|---|
| Oppstrøms Kubernetes | – | 26. august 2026 | Følger prosjektets standard støttevindu |
| Azure AKS | September 2026 | Oktober 2026 | Oktober 2027 (utvidet til oktober 2028) |
| AWS EKS | Ikke bekreftet ved publisering | Ikke bekreftet ved publisering | Ikke bekreftet |
| Google GKE | Ikke bekreftet ved publisering | Ikke bekreftet ved publisering | Ikke bekreftet |
Fra kvartalsvise utgivelser til AI-infrastruktur: historisk kontekst
Kubernetes har i flere år holdt en jevn kvartalsvis utgivelsestakt, og 1.37 bryter ikke med det mønsteret. Prosjektet gikk fra å være et nisjeverktøy for containerorkestrering til å bli det CNCF nå kaller enterprise-standarden for å drifte moderne applikasjoner i stor skala, ifølge organisasjonens egen karakteristikk i januar-undersøkelsen. Den forrige store versjonen, 1.36, innførte blant annet endret EKS-støtte fra juni 2026 og la grunnlaget for funksjoner som nå modnes videre i 1.37, som endring av poders ressursbruk mens de kjører.
Det som skiller 1.37 fra tidligere versjoner er ikke størrelsen på endringslisten, men hvor konsentrert den er rundt to temaer: sikkerhet (SELinux, pod-sertifikater, krypterte prober) og AI-klargjøring (DRA, GPU-helsestatus). Det gjenspeiler hvor utviklerressursene i Kubernetes-fellesskapet nå brukes, og det er en klar dreining fra de mer generelle skalerings- og stabilitetsforbedringene som dominerte utgivelser for tre til fire år siden.
Markedstall: hvor stor er Kubernetes-økonomien i 2026
Ifølge en markedsanalyse publisert i august 2026 er det globale Kubernetes-markedet anslått til 3,13 milliarder dollar i år, med en forventet vekst til 8,41 milliarder dollar innen 2031, tilsvarende en årlig vekstrate på 21,85 %. Tallene dekker forvaltede tjenester, støtteavtaler og verktøy bygget rundt plattformen, og de underbygger bildet av en teknologi som har gått fra eksperimentell infrastruktur til en fast linje i de fleste IT-budsjetter.
CNCF sin egen undersøkelse, offentliggjort 20. januar 2026, plasserer produksjonsbruken av Kubernetes blant containerbrukere til 82 %, opp fra tidligere år. 98 % av de spurte har innført skyfødte teknikker i en eller annen form, og organisasjonen peker på at kulturelle faktorer, ikke selve teknologien, nå er den avgjørende bremseklossen for videre modning i mange virksomheter.
Veksten i markedstallene henger delvis sammen med hvor mange verktøy og forvaltede tjenester som nå bygges rundt kjerneprosjektet. Der Kubernetes selv er gratis og åpen kildekode, hentes inntektene i økende grad fra støtteavtaler, sikkerhetsovervåking, kostnadsstyring og administrerte kontrollplan hos de store skyleverandørene. Det er også derfor tidspunktet for når AKS, EKS og GKE tar inn en ny versjon som 1.37 har direkte kommersiell betydning, ikke bare teknisk interesse.
Hva dette betyr for norske og nordiske virksomheter
For norske selskaper som kjører Kubernetes on-premise eller i AWS Stockholm-regionen (eu-north-1) og Azures norske regioner er tidslinjen for administrert støtte det som avgjør tempoet. Bedrifter med egendrevne klynger kan i teorien oppgradere så snart 1.37 er ute, men bør først kjøre gjennom testene knyttet til SELinux og containerd-versjon beskrevet over. Bedrifter på AKS, EKS eller GKE er derimot bundet av leverandørenes egne tidsplaner, og AKS-kunder har her et forsprang siden Microsoft allerede har publisert konkrete datoer for norsk og europeisk bruk.
Kombinasjonen av strengere krav til dokumentert sikkerhet under NIS2 og digitalsikkerhetsloven og de nye funksjonene for pod-sertifikater og krypterte helsesjekker gjør at flere norske plattformteam trolig vil prioritere 1.37-oppgraderingen høyere enn en gjennomsnittlig kvartalsversjon. Samtidig er avhengigheten av containerd 2.0 en påminnelse om at Kubernetes-oppgraderinger sjelden er isolerte. De drar ofte med seg oppgraderinger lenger ned i stabelen.
Slik forbereder du oppgraderingen til 1.37
Før produksjonsklynger flyttes til 1.37 bør plattformteam gjennom noen konkrete steg. Sjekk først containerd-versjonen på alle noder, siden 1.37 forutsetter 2.0 eller nyere for full kompatibilitet med de fjernede kubelet-flaggene. Deretter bør SELinux-status testes eksplisitt i et ikke-produksjonsmiljø, spesielt for klynger som blander RHEL- og Fedora-baserte noder med andre distribusjoner.
kubectl version --short
kubectl get nodes -o wide
kubectl get --raw /apis/metrics.k8s.io/v1beta1/nodes
crictl info | grep -i version
Kommandoene over gir et raskt situasjonsbilde: hvilken klientversjon som brukes, hvilket operativsystem nodene kjører, om Metrics API allerede svarer, og hvilken containerd-versjon som er installert. Team som fortsatt er på eldre containerd bør planlegge den oppgraderingen som et eget trinn, gjerne i samme vedlikeholdsvindu som selve Kubernetes-oppgraderingen for å unngå to separate nedetidsperioder.
Vanlige fallgruver ved store Kubernetes-oppgraderinger
Den tekniske jobben med å oppgradere en klynge er sjelden det som tar lengst tid i store organisasjoner. Godkjenningsløp, endringshåndtering og koordinering mellom team som eier ulike deler av infrastrukturen spiser ofte mer tid enn selve kommandoene. Når en ny versjon som 1.37 i tillegg krever en samtidig containerd-oppgradering, må planen omfatte flere lag i stabelen samtidig, noe som gjerne betyr flere godkjenninger og flere testrunder enn en ordinær patch.
CNCF peker selv på at kulturelle og organisatoriske faktorer, ikke teknologien, nå er den vanligste bremseklossen for videre Kubernetes-modning i store virksomheter. Det stemmer med erfaringen fra plattformteam som beskriver SELinux- og containerd-avhengighetene i 1.37 som overkommelige tekniske oppgaver, men der selve prosessen med å få sikkerhets-, drift- og applikasjonsteam til å teste og godkjenne endringen samtidig er den egentlige flaskehalsen.
Konkurransebildet: hvordan 1.37 påvirker valget mellom skyleverandørene
Tidslinjen for 1.37 legger til enda et datapunkt i sammenligningen mellom de store administrerte Kubernetes-tjenestene. Azure har historisk vært raskest med å publisere eksakte support-datoer, noe som gjentar seg denne runden med konkrete tall for forhåndsvisning, GA og avslutning av support helt frem til 2028. AWS og Google har tradisjonelt fulgt tett etter i faktisk leveringstid, selv om de ikke publiserer like detaljerte datoer så tidlig i prosessen.
For virksomheter som velger sky basert på hvor raskt de får tilgang til nye Kubernetes-funksjoner, betyr dette at forspranget på nye versjoner fortsatt kan veie i Azures favør, mens AWS og Google typisk konkurrerer på bredere tjenesteøkosystem og pris rundt selve klyngedriften. Dette er ett av flere punkter norske virksomheter bør veie når de vurderer multi-cloud-strategier for containerdrift.
Prediksjoner: hva skjer videre med Kubernetes
- DRA blir standardveien for GPU-styring innen 2027. Med DRAResourceClaimDeviceStatus på GA-nivå og helsestatus-API-et rett bak, er det sannsynlig at flere AI-plattformer bygger direkte på DRA fremfor egne GPU-plugins.
- Containerd 2.0 blir de facto minstekrav. Når kubelet-flagg som forutsetter det nye kjøretidsmiljøet fjernes for godt, vil flere distribusjoner og administrerte tjenester tvinge gjennom oppgraderingen som del av neste større plattformoppdatering.
- Flere klynger demper SELinux-håndhevelse midlertidig. Noen team vil trolig velge å midlertidig dempe SELinux-håndhevelse under overgangen til 1.37 fremfor å risikere driftsstans, noe sikkerhetsansvarlige bør følge tett.
- Metrics-API-stabilitet åpner for et nytt lag med kommersielle overvåkingsverktøy. En formelt stabil API senker terskelen for tredjepartsverktøy som bygger direkte på metrics.k8s.io i stedet for egne agenter.
- Pod-sertifikater reduserer avhengigheten av eksterne certificate managers. Over de neste versjonene er det ventet at flere klynger går bort fra tredjeparts sertifikatstyring til fordel for den innebygde løsningen, særlig i regulerte bransjer som bank og offentlig sektor i Norden.
Ofte stilte spørsmål om Kubernetes 1.37
Når ble Kubernetes 1.37 sluppet?
Kubernetes 1.37 fikk generell tilgjengelighet onsdag 26. august 2026, etter at funksjonsfrys landet 17. juni og to release candidates ble sluppet i august samme år.
Hva er den mest kritiske brytende endringen i 1.37?
SELinuxMount, som nå er stabil og slått på som standard, regnes som den mest risikable endringen fordi den kan stoppe poder fra å starte i klynger som kjører SELinux i enforcing-modus.
Må jeg oppgradere containerd før jeg går til 1.37?
Ja, hvis klyngen din er avhengig av kubelet-flagg som ble faset ut i versjon 1.36, forutsetter fjerningen av disse flaggene i 1.37 at nodene kjører containerd 2.0 eller nyere.
Når får AKS, EKS og GKE støtte for 1.37?
Azure AKS har publisert forhåndsvisning i september 2026 og generell tilgjengelighet i oktober 2026. AWS EKS og Google GKE hadde ved publiseringstidspunktet ikke offentliggjort tilsvarende eksakte datoer.
Hva er nytt for AI- og GPU-arbeidslaster i denne versjonen?
Dynamic Resource Allocation får flere modne funksjoner i 1.37, blant annet at DRAResourceClaimDeviceStatus når generell tilgjengelighet, noe som gir bedre statusinnsikt i GPU- og akseleratorressurser for AI-arbeidslaster.
Er metrics.k8s.io trygt å bygge videre på nå?
Ja. Etter ni år i beta er API-et nå generelt tilgjengelig med formelle stabilitetsgarantier, noe som gjør det tryggere for både interne verktøy og tredjepartsløsninger å basere seg direkte på det.
Hvor mange organisasjoner kjører faktisk Kubernetes i produksjon?
Ifølge CNCF sin årlige undersøkelse, publisert 20. januar 2026, kjører 82 % av alle containerbrukere Kubernetes i produksjon, mens 98 % har tatt i bruk skyfødte teknikker i en eller annen form.
Bør jeg vente med å oppgradere til AKS, EKS eller GKE støtter 1.37?
Det avhenger av driftsmodell. Selvforvaltede klynger kan oppgradere så snart interne tester av SELinux og containerd-kompatibilitet er gjennomført, mens virksomheter på administrerte tjenester uansett må vente til leverandøren ruller ut støtte.
