Kubernetes 1.36 er nå generelt tilgjengelig, og Amazon EKS begynte å støtte versjonen 2. juni 2026. For norske og nordiske IT-avdelinger som driver alt fra bankinfrastruktur til AI-treningsklynger på Kubernetes, er dette mer enn en rutineoppdatering. Utgivelsen fjerner en gammel sikkerhetsrisiko for godt, gjør brukernavnerom produksjonsklare, og legger et nytt fundament for hvordan team styrer tilgang i store, delte klynger. Samtidig strammer AWS inn støttevinduet på en måte som tvinger frem en oppgraderingsplan de fleste organisasjoner ennå ikke har.

Denne analysen går gjennom hva som faktisk er nytt, hva som forsvinner, hvordan skyleverandørene håndterer overgangen ulikt, og hva det betyr for team i Norge, Sverige, Danmark og Finland som drifter Kubernetes-klynger i produksjon.

Kubernetes 1.36: datoene du må kjenne til

Kubernetes-prosjektet ga ut versjon 1.36 oppstrøms 22. april 2026, som første store utgivelse det året. Amazon EKS og Amazon EKS Distro fulgte etter drøyt seks uker senere: støtte for 1.36 ble annonsert 2. juni 2026, ifølge AWS’ offisielle kunngjøring. Fra den datoen kunne kunder opprette nye EKS-klynger direkte på 1.36 eller oppgradere eksisterende klynger.

Selve utrullingen på EKS gikk i flere trinn. Plattformversjon 1.36.1/eks.3 kom 2. juni, en oppfølger (eks.4) kom allerede dagen etter med sikkerhetsrettelser, og 22. juni fulgte 1.36.2/eks.6 med ytterligere herding. En mellomliggende plattformversjon, eks.5, ble aldri offentliggjort til kundene, noe som er uvanlig og tyder på at teamet fanget opp et problem internt før den nådde produksjon.

Det viktigste tallet for driftsteam er likevel støttevinduet. Ifølge AWS’ dokumentasjon for versjonslivssyklus går standardstøtte for 1.36 ut 2. august 2027, med utvidet støtte som varer helt til 2. august 2028. Det gir til sammen 26 måneder: 14 måneder standardstøtte og 12 måneder utvidet støtte, regnet fra EKS-lanseringen, ikke fra oppstrømsutgivelsen. Team som planlegger langsiktig infrastruktur bør merke seg at klokka begynner å tikke fra 2. juni 2026, ikke fra april.

MilepælDatoKommentar
Oppstrøms utgivelse (Kubernetes-prosjektet)22. april 2026Første store 2026-utgivelse
Amazon EKS-støtte starter2. juni 2026Plattformversjon 1.36.1/eks.3
Sikkerhetsoppdatering eks.43. juni 2026Rettelser dagen etter lansering
Plattformversjon eks.622. juni 2026eks.5 ble aldri sluppet offentlig
Slutt på standardstøtte2. august 202714 måneder fra EKS-lansering
Slutt på utvidet støtte2. august 202826 måneder totalt

Brukernavnerom blir produksjonsklart: hvorfor det betyr noe

Den mest betydningsfulle sikkerhetsendringen i 1.36 er at brukernavnerom i pods (user namespaces) nå har nådd generell tilgjengelighet. Funksjonsbryteren som tidligere måtte slås på manuelt, er fjernet, og funksjonen er på som standard i støttede miljøer. I praksis betyr det at en container kan kjøre som root inni sin egen container, uten at det root-privilegiet mappes til faktisk root på vertsnoden.

Det høres kanskje teknisk ut, men konsekvensen er konkret: et vellykket containerutbrudd gir ikke lenger automatisk full kontroll over noden. For team som kjører flerleiermiljøer, altså klynger der flere kunder eller avdelinger deler samme infrastruktur, tetter dette et av de mest fryktede angrepsscenarioene i Kubernetes-verdenen. Norske skyteam som driver delte klynger for flere forretningsenheter, bør prioritere denne migreringen høyt.

Sammen med brukernavnerom kommer også Mutating Admission Policies til generell tilgjengelighet. Dette lar administratorer definere CEL-baserte regler som endrer ressurser direkte i API-serveren, uten å måtte bygge og drifte egne eksterne webhook-tjenester. Det kutter en hel kategori infrastruktur som tidligere krevde egen overvåking, skalering og feilsøking. Totalt inneholder 1.36 18 forbedringer som har nådd stabil status, inkludert fire funksjoner knyttet til Dynamic Resource Allocation (DRA), som er spesielt relevant for team som kjører GPU-arbeidslaster.

Det som forsvinner: gitRepo-plugin og IPVS

Kubernetes 1.36 er også utgivelsen der prosjektet endelig kutter to lenge advarte funksjoner. Volumtypen gitRepo har vært merket som utfaset siden versjon 1.11, altså i over fem år, men i 1.36 er den permanent deaktivert og kan ikke lenger slås på igjen. Manifester som fortsatt refererer til denne volumtypen, vil rett og slett feile etter oppgradering. Sikkerhetsanalyser har lenge pekt på gitRepo som en unødvendig angrepsflate, siden den lot podder klone vilkårlige Git-repositorier direkte inn i kjøretiden uten skikkelig tilgangskontroll.

IPVS-modus i kube-proxy, som ble merket utfaset allerede i versjon 1.35, forsvinner også fra det aktive settet med støttede nettverksalternativer i 1.36. Klynger som fortsatt lener seg på IPVS for lastbalansering internt, må migrere til alternative implementasjoner før oppgradering, ellers risikerer de brudd i tjenesteoppdagelse.

En tredje endring er mer gradvis: feltet .spec.externalIPs på Service-objekter er nå formelt merket utfaset (KEP-5707). Det fjernes ikke i 1.36, men klynger vil begynne å se advarsler i loggene når dette feltet brukes. Full fjerning er planlagt til versjon 1.43, så team har flere utgivelsessykluser på seg til å migrere bort fra mønsteret, ifølge AWS’ oversikt over utvidet støtte.

KYAML og ServiceAccount-token: mindre synlige, men viktige endringer

To andre endringer får mindre oppmerksomhet, men påvirker den daglige driften. KYAML, en strengere delmengde av YAML-formatet designet for å eliminere klassiske feilkilder i konfigurasjonsfiler, når generell tilgjengelighet i 1.36. Fra og med denne versjonen avviser valideringen farlige YAML-mønstre som standard, i stedet for bare å gi en advarsel slik den gjorde tidligere. Det er en liten endring på papiret, men den kan bryte eksisterende CI/CD-pipeliner som har levd med “nesten korrekte” manifester i årevis.

Ekstern signering av ServiceAccount-tokener, kjent som KEP-740, går fra beta til stabil status i denne utgivelsen. For sikkerhetsteam betyr det en mer moden, standardisert måte å utstede identitetsbevis til arbeidslaster på, uten å være avhengig av den innebygde token-kontrolleren i API-serveren. Det passer godt sammen med en bredere trend der Kubernetes-klynger integreres tettere med eksterne identitetsleverandører og null-tillit-arkitektur.

Skyleverandørene: ulik hastighet på støtten

AWS var raskt ute med 1.36-støtte, med drøyt seks uker fra oppstrømslansering til generell tilgjengelighet på EKS. Det er en typisk syklus for Amazon, som de siste årene har prioritert å ligge tett opp mot Kubernetes-fellesskapets egen utgivelsestakt. AWS holder i tillegg fast ved sin modell med 14 måneders standardstøtte pluss 12 måneders utvidet støtte, en modell som har vært konsistent siden 2024, ifølge AWS’ kunngjøring om utvidet støtte fra den gang ordningen ble innført.

Dette er relevant for norske team fordi AWS fortsatt er den klart største skyleverandøren i det norske markedet. Ifølge en oversikt fra stateglobe.com over skyleverandører i Norge holder AWS rundt 45 prosent markedsandel i 2026, mens Microsoft Azure ligger på 23 prosent og Google Cloud Platform på 12 prosent. Med andre ord: for nesten halvparten av norske skyarbeidslaster er AWS’ 1.36-tidslinje den som faktisk teller.

Verken Azure Kubernetes Service eller Google Kubernetes Engine har på researchtidspunktet publisert offisielle, daterte kunngjøringer om 1.36-støtte som matcher detaljnivået AWS har lagt fram. Det er verdt å følge med på, siden mange nordiske virksomheter kjører multi-cloud-strategier og trenger samkjørte versjonsplaner på tvers av leverandører for å unngå at én klynge henger etter en annen i sikkerhetsoppdateringer.

Nordisk kontekst: skymarkedet vokser raskere enn resten av Europa

Kubernetes 1.36 kommer i en periode der Norden peker seg ut som noen av de raskest voksende skymarkedene i Europa. Ifølge en analyse fra The Register om europeisk skyinfrastruktur forblir Storbritannia og Tyskland de største markedene målt i absolutte tall, men Irland, Norge, Danmark og Finland vokser raskest i relativ takt. Det handler dels om ny AI-datasenterkapasitet, dels om at nordiske virksomheter i økende grad flytter kjernesystemer til sky som en del av digitaliseringsstrategier drevet av både konkurransepress og myndighetskrav.

Veksten skjer samtidig med at nordiske selskaper i økende grad går bort fra én enkelt skyleverandør. Bransjerapporter peker på at multi-cloud nå er normen snarere enn unntaket blant større nordiske virksomheter, og at FinOps-styring (kostnadsstyring på tvers av skyplattformer) integreres tettere inn i drift av hybride og multiskyplattformer. Kubernetes fungerer i praksis som limet som gjør denne strategien mulig, siden containeriserte arbeidslaster kan flyttes mellom AWS, Azure og GCP uten å skrive om applikasjonskoden fra bunnen.

Det gjør versjonsstyring på tvers av leverandører til en reell driftsutfordring. Et team som kjører produksjonslast delt mellom EKS og AKS, må forholde seg til to forskjellige støttevinduer, to forskjellige oppgraderingsprosesser og potensielt to forskjellige tidspunkt for når sikkerhetsfunksjoner som brukernavnerom faktisk blir tilgjengelige i produksjon.

Bransjedata: hvor mye kjøres faktisk på Kubernetes nå?

Skalaen Kubernetes har nådd, gjør hver større versjonsendring til noe langt mer enn en teknisk fotnote. Ifølge CNCFs årlige Cloud Native-undersøkelse kjører nå 82 prosent av alle som bruker containere Kubernetes i produksjon, opp fra 66 prosent i 2023. Det er en økning på 16 prosentpoeng på tre år, og bekrefter at Kubernetes har gått fra å være ett av flere alternativer til å bli standardplattformen for containerdrift.

Red Hats skyytelsesundersøkelse for 2026 underbygger bildet: 70 prosent av organisasjonene kjører nå Kubernetes på tvers av flere skyleverandører samtidig, mens 79 prosent bruker Kubernetes til infrastruktur- eller plattformtjenester internt, ifølge Red Hats rapport om flåtestyring for Kubernetes. Samme rapport viser at 71 prosent av organisasjonene nå kjører data-, analyse- eller AI/ML-arbeidslaster direkte på Kubernetes, en tydelig kobling til hvorfor DRA-forbedringene i 1.36 er relevante for GPU-tunge miljøer.

Fremover-blikket er like tydelig. Portworx’ “Voice of Kubernetes”-rapport for 2026 finner at 84 prosent av organisasjonene forventer å bygge minst halvparten av sine nye applikasjoner på Kubernetes innen fem år, ifølge Portworx by Pure Storages rapport. Med andre ord: plattformen vokser fortsatt kraftig, selv etter over et tiår i produksjon hos de fleste store teknologiselskaper.

NøkkeltallVerdiKilde
Andel containerbrukere som kjører Kubernetes i produksjon82 % (opp fra 66 % i 2023)CNCF Cloud Native Survey 2026
Organisasjoner som kjører Kubernetes på tvers av flere skyer70 %Red Hat, 2026
Organisasjoner som kjører AI/ML-arbeidslaster på Kubernetes71 %Red Hat, 2026
Forventer å bygge minst halvparten av nye apper på Kubernetes innen 5 år84 %Portworx, 2026
AWS’ markedsandel i Norge~45 %stateglobe.com, 2026
Azures markedsandel i Norge~23 %stateglobe.com, 2026
Total EKS-støtteperiode for 1.3626 månederAWS EKS-dokumentasjon

Historisk kontekst: fra kvartalsvise brudd til strammere livssykluser

Kubernetes-prosjektet har historisk hatt et rykte for hyppige, tidvis brå brytende endringer mellom versjoner. Tidlige år av prosjektet var preget av at klyngeadministratorer måtte lese lange endringslogger nøye for hver oppgradering, siden API-er kunne forsvinne uten lang varslingsperiode. De siste årene har prosjektet beveget seg mot en mer forutsigbar modell, der funksjoner som gitRepo og IPVS-modus varsles utfaset i god tid før de faktisk fjernes, ofte flere år i forveien slik som med gitRepo siden versjon 1.11.

Denne strammere tilnærmingen til livssyklus er også synlig hos skyleverandørene selv. AWS innførte sin modell med standardstøtte pluss utvidet støtte i 2024, en direkte respons på tilbakemeldinger fra kunder som slet med å holde tritt med Kubernetes’ opprinnelige tempo på tre store utgivelser i året. Ved å love et fast 26-måneders vindu, uansett hvor mange oppstrøms-utgivelser som kommer i mellomtiden, gir AWS driftsteam en mer forutsigbar planleggingshorisont enn de hadde for bare noen år siden.

Hva 1.36 betyr for AI- og ML-arbeidslaster

De fire DRA-forbedringene (Dynamic Resource Allocation) som når stabil status i 1.36, er kanskje den mest undervurderte delen av utgivelsen sett fra et AI-perspektiv. DRA gjør det mulig for Kubernetes å behandle spesialisert maskinvare, som GPU-er og annen akselerert databehandling, mer fleksibelt enn den eldre, statiske ressursmodellen tillot. Det gjør det enklere å dele GPU-ressurser mellom flere podder, planlegge arbeidslaster basert på faktisk maskinvarekapasitet, og unngå at dyre GPU-noder står halvutnyttet.

Dette faller sammen med at store skyleverandører bygger stadig mer AI-infrastruktur i Norden, deriblant nye datasenterprosjekter i Norge knyttet til AI-trening. Når slike anlegg orkestreres av Kubernetes internt, blir modenheten i GPU-ressursstyring i 1.36 direkte relevant for hvor effektivt kapital investert i maskinvare faktisk utnyttes. Kombinert med at brukernavnerom nå er produksjonsklart, gir dette operatører et sterkere sikkerhetsgrunnlag for å dele GPU-klynger mellom flere team eller kunder, uten at ett kompromittert treningsjobb kan eskalere til full nodetilgang.

Konkurransebildet: EKS mot AKS mot GKE på versjonsstøtte

Når man sammenligner hvordan de tre store skyleverandørene håndterer Kubernetes-versjonering, er forskjellen i åpenhet slående. AWS publiserer detaljerte, daterte livssyklustabeller for hver versjon, komplett med eksakte datoer for standardstøtte og utvidet støtte flere år fram i tid. Denne graden av forutsigbarhet gjør det enklere for norske driftsteam å planlegge oppgraderinger i god tid, budsjettere for migreringsarbeid, og unngå akutte “brannslukningsoppgraderinger” like før støtten går ut.

For team som kjører multi-cloud, betyr mangelen på tilsvarende offentlig, datert dokumentasjon fra andre leverandører på researchtidspunktet at man i praksis må bygge egne interne oversikter for å holde styr på hvilken klynge som kjører hvilken versjon, og når hver av dem mister støtte. Dette er en driftsrisiko som ofte undervurderes: en glemt, utdatert klynge uten sikkerhetsoppdateringer er langt vanligere enn de fleste sikkerhetsteam liker å innrømme.

Regelverk og etterlevelse: hva betyr dette for NIS2-pliktige virksomheter?

For norske virksomheter som faller inn under NIS2-regelverket, altså EUs direktiv for nettverks- og informasjonssikkerhet, har sikkerhetsforbedringene i 1.36 en praktisk side utover selve teknologien. Vår tidligere dekning av NIS2 i Norge viser at rundt 5.000 norske virksomheter omfattes av digitalsikkerhetsloven, med bøter på opptil 4 prosent av global omsetning ved alvorlige brudd. Isolasjon mellom arbeidslaster, altså at ett kompromittert system ikke automatisk gir tilgang til andre, er et sentralt krav i mange av risikovurderingene som ligger til grunn for loven.

Brukernavnerom i pods gir sikkerhetsteam et konkret, dokumenterbart tiltak å vise til i en revisjon: en teknisk kontroll som direkte reduserer konsekvensen av et containerutbrudd. Det er ikke det samme som full etterlevelse, men det er nettopp den typen forsvar-i-dybden-tiltak revisorer og tilsynsmyndigheter ser etter når de vurderer om en virksomhet har gjort “tilstrekkelige tekniske og organisatoriske tiltak”, slik NIS2-teksten formulerer det. Finanssektoren og kraftsektoren, to bransjer med tung tilstedeværelse i Norge og begge underlagt strenge krav, bør derfor vurdere 1.36-oppgradering som del av sitt NIS2-arbeid for 2026 og 2027, ikke som en frittstående IT-oppgave.

Samtidig er det verdt å understreke at en versjonsoppgradering alene ikke oppfyller noe regulatorisk krav. Brukernavnerom må faktisk aktiveres og testes, og de andre kontrollene i klyngen, som nettverkspolicyer, admission-kontroll og logging, må fortsatt være på plass. Utgivelsen senker terskelen for god praksis, men fjerner ikke behovet for en helhetlig sikkerhetsarkitektur.

Praktiske skritt for norske driftsteam

Før en oppgradering til 1.36 bør driftsteam gjennomføre noen konkrete kontroller. Først: søk gjennom alle manifester etter referanser til gitRepo-volumtypen, siden disse vil feile umiddelbart etter oppgradering uten forvarsel i selve applikasjonskoden. Dette gjøres enklest med et enkelt grep-søk mot hele manifestrepositoriet.

grep -rn "gitRepo" --include="*.yaml" --include="*.yml" .
kubectl get pods --all-namespaces -o json | jq '.items[].spec.volumes[]? | select(.gitRepo != null)'

Deretter bør team kartlegge om noen tjenester bruker externalIPs-feltet, siden dette nå trigger advarsler i loggene selv om funksjonaliteten fortsatt virker fram til versjon 1.43. Til slutt: undersøk om klyngen fortsatt bruker IPVS-modus i kube-proxy, siden dette er fjernet fra det aktive settet i 1.36 og krever migrering til alternativ nettverksimplementasjon før oppgradering kan gjennomføres trygt.

For team som ønsker å aktivere brukernavnerom i pods, bør dette testes grundig i et separat miljø først, siden funksjonen endrer hvordan filrettigheter og eierskap håndteres inni containeren. Applikasjoner som er hardkodet til å forvente å kjøre som faktisk root, kan oppføre seg uventet når root kun eksisterer innenfor det mappede navnerommet.

Markedspåvirkning: hva koster oppgraderingen bedrifter?

Selv om Kubernetes-oppgraderinger i seg selv er gratis, er de sjelden kostnadsfrie i praksis. Testing, validering av manifester, og eventuell omskriving av volumdefinisjoner som bruker gitRepo, krever ingeniørtid som må planlegges inn i kvartalsbudsjetter. For større organisasjoner med dusinvis av klynger fordelt på flere team, kan en full 1.36-migrering strekke seg over flere måneder når man tar høyde for stage-miljøer, kanarioppsett og gradvis utrulling til produksjon.

Samtidig peker vår tidligere dekning av AWS’ FinOps-agent på at så mye som 29 prosent av skyforbruket i mange organisasjoner går til bortkastede ressurser, ofte overprovisjonerte noder eller podder som aldri skaleres ned. De forbedrede DRA-funksjonene i 1.36 gir et konkret verktøy for å angripe nettopp dette problemet på GPU-siden, ved å gjøre ressursallokering mer presis. For finansteam som styrer skybudsjetter i norske virksomheter, kan bedre GPU-utnyttelse i praksis oppveie noe av migreringskostnaden over tid, spesielt i organisasjoner som allerede investerer tungt i AI-infrastruktur.

Det er også en indirekte kostnadsside ved å ikke oppgradere. Klynger som blir liggende på eldre versjoner etter at standardstøtten utløper, mister tilgang til sikkerhetsoppdateringer med mindre organisasjonen betaler ekstra for utvidet støtte, der det tilbys. Kostnaden ved et sikkerhetsbrudd i en uoppgradert klynge, med tilhørende gransking, varsling og mulig NIS2-relatert bot, overstiger normalt migreringskostnaden med god margin. De fleste sikkerhetsansvarlige vil derfor argumentere for at oppgradering bør behandles som en forsikringspremie, ikke en valgfri IT-oppgave.

Fem prognoser for resten av 2026 og inn i 2027

  • Azure og Google følger etter innen tredje kvartal. Gitt AWS’ seks ukers responstid er det sannsynlig at både AKS og GKE ruller ut egen 1.36-støtte i løpet av høsten 2026, selv om ingen av dem har publisert en offisiell dato på researchtidspunktet.
  • Brukernavnerom blir standard i flere administrerte tjenester. Nå som funksjonen har nådd generell tilgjengelighet oppstrøms, vil flere administrerte Kubernetes-tjenester trolig aktivere den som standard for nye klynger innen 2027, ikke bare som en valgfri innstilling.
  • Multiskyversjonsstyring blir et eget verktøysegment. Med 70 prosent av organisasjoner allerede på multiskystrategier, forventes flere kommersielle og åpen kildekode-verktøy for å spore versjonsdrift og støttevinduer på tvers av EKS, AKS og GKE samtidig.
  • DRA-modenheten driver mer GPU-deling i nordiske AI-anlegg. Ettersom flere AI-datasenterprosjekter i Norge og Norden går i produksjon, vil de fire stabiliserte DRA-funksjonene trolig bli en forutsetning for effektiv utnyttelse av GPU-kapasitet i delte klynger.
  • Presset for å fjerne externalIPs helt øker før 2027. Selv om full fjerning formelt er satt til versjon 1.43, vil sikkerhetsmiljøet trolig legge press på raskere migrering, gitt at feltet historisk har vært knyttet til nettverkskonfigurasjonsfeil i produksjon.

Ofte stilte spørsmål om Kubernetes 1.36

Når ble Kubernetes 1.36 sluppet?
Oppstrøms ble versjonen sluppet 22. april 2026. Amazon EKS begynte å støtte den 2. juni 2026.

Hvor lenge får Kubernetes 1.36 support på Amazon EKS?
Standardstøtte varer til 2. august 2027, og utvidet støtte til 2. august 2028. Det gir totalt 26 måneder fra EKS-lanseringen.

Hva er den viktigste sikkerhetsendringen i 1.36?
At brukernavnerom i pods (user namespaces) har nådd generell tilgjengelighet, slik at et containerutbrudd ikke lenger automatisk gir root-tilgang på selve noden.

Må jeg endre manifestene mine før jeg oppgraderer?
Ja, hvis de bruker gitRepo-volumtypen. Denne er permanent deaktivert i 1.36 og vil forårsake feil ved oppgradering. Sjekk også bruk av IPVS-modus i kube-proxy og feltet externalIPs.

Støtter Azure AKS og Google GKE Kubernetes 1.36?
På researchtidspunktet har verken Azure eller Google publisert offisielle, daterte kunngjøringer om 1.36-støtte med samme detaljnivå som AWS. Følg leverandørenes egne versjonssider for oppdateringer.

Hvor stor andel bedrifter kjører faktisk Kubernetes i produksjon?
82 prosent av containerbrukere kjører Kubernetes i produksjon ifølge CNCFs 2026-undersøkelse, opp fra 66 prosent i 2023.

Hvorfor er dette relevant for norske skyteam spesielt?
AWS har omtrent 45 prosent markedsandel i det norske skymarkedet, og Norge er blant de raskest voksende skymarkedene i Europa. AWS’ 1.36-tidslinje påvirker dermed en betydelig andel av norsk skyinfrastruktur direkte.

Hva bør jeg gjøre først hvis jeg drifter en eldre Kubernetes-versjon?
Kartlegg avhengigheter til gitRepo og IPVS, test brukernavnerom i et ikke-produksjonsmiljø, og legg en oppgraderingsplan som tar høyde for at standardstøtten for 1.36 går ut 2. august 2027.

Relatert dekning