Kubernetes 1.34 gikk inn i vedlikeholdsmodus 27. august 2026, og full støtteslutt (EOL) kommer 27. oktober 2026. Det som ser ut som en rutinemessig versjonsovergang har samtidig avslørt noe langt mer kostbart for tusenvis av selskaper: alle de tre store skyleverandørene, Amazon, Microsoft og Google, tar nå betydelig mer betalt for kunder som blir hengende igjen på gamle Kubernetes-versjoner. Hos Amazon EKS og Google GKE går kontrollplan-prisen fra 0,10 dollar til 0,60 dollar per klynge i timen, en seksdobling som i praksis betyr rundt 438 dollar i måneden per klynge i stedet for 73 dollar. Hos Azure kommer den samme kostnadsøkningen gjennom en egen Premium-tier med Long Term Support.
For norske og nordiske IT-avdelinger, som ofte kjører titalls eller hundrevis av klynger på tvers av produksjon, test og regionale miljøer, er dette ikke lenger et teoretisk problem. Det er en regning som dukker opp på neste fakturasyklus dersom oppgraderingsvinduet blir oversett.
Kubernetes 1.34 nærmer seg full støtteslutt
Kubernetes-prosjektet publiserte 1.34 med generell tilgjengelighet 27. august 2025. Ett år senere, nøyaktig 27. august 2026, gikk versjonen over i det prosjektet kaller vedlikeholdsmodus. Der mottar versjonen kun kritiske sikkerhetsrettelser, ingen nye funksjoner. 27. oktober 2026 stanser all patching helt, ifølge den offisielle utgivelsessiden til Kubernetes.
Kubernetes-prosjektet har lenge fulgt en fast livssyklus der tre mindre versjoner støttes samtidig, altså den nyeste versjonen og de to foregående (N, N-1 og N-2). Når 1.37 etter hvert blir gjeldende, faller 1.34 helt utenfor det åpne kildekode-prosjektets støttevindu. Det er her skyleverandørenes egne, betalte støtteprogrammer overtar for kunder som ikke rekker å oppgradere i tide.
Hva skjer teknisk når en versjon går ut på dato
Selve programvaren slutter ikke å fungere den dagen støtten opphører. Klynger fortsetter å kjøre normalt. Det som endrer seg er sikkerhetsdekningen: nye sårbarheter i kontrollplanet, kubelet eller andre kjernekomponenter blir ikke lenger rettet for versjoner utenfor støttevinduet, med mindre man betaler for utvidet support hos skyleverandøren.
I praksis betyr dette to valg for et selskap som fortsatt kjører 1.34 etter oktober: enten oppgradere til en nyere, aktivt støttet versjon, eller bli automatisk flyttet inn i et betalt utvidet støtteprogram hos AWS, Google eller Microsoft. Hos både EKS og GKE skjer denne overgangen automatisk. Ingen advarsel utover det som står i dokumentasjonen, og ingen egen e-post før neste faktura viser den nye timesprisen.
AWS EKS: seks ganger prisen fra måned 15
Amazon Elastic Kubernetes Service har den klareste og mest dokumenterte modellen av de tre. Hver Kubernetes-versjon får 14 måneder standard support fra den blir tilgjengelig i EKS, til en kontrollplan-pris på 0,10 dollar per klynge i timen, omtrent 73 dollar i måneden. Etter det går versjonen automatisk inn i utvidet support i 12 måneder til, med en pris på 0,60 dollar per klynge i timen, omtrent 438 dollar i måneden, ifølge AWS sin offisielle prisside for EKS.
For Kubernetes 1.34 spesifikt ble EKS-versjonen tilgjengelig rundt starten av oktober 2025. Det betyr at standard support for 1.34 på EKS varer til rundt 2. desember 2026, og utvidet support løper deretter til rundt 2. desember 2027, ifølge AWS sin dokumentasjon om versjonslivssyklus. Totalt gir dette 26 måneders støtte per versjon, mot tidligere en langt kortere periode uten noe betalt alternativ i det hele tatt.
Man kan sjekke hvilken versjon en EKS-klynge kjører, og dermed hvor den befinner seg i støttesyklusen, direkte fra kommandolinjen:
aws eks describe-cluster --name mitt-klyngenavn --query "cluster.version" --output textGoogle GKE: samme 0,60 dollar-modell, men med et smutthull
Google Kubernetes Engine har landet på nesten identiske tall som AWS, men bygget opp litt annerledes. Standard klyngeforvaltningsgebyr er 0,10 dollar per klynge i timen, uten ekstra kostnad i de første cirka 14 månedene av en versjons levetid, ifølge Google Cloud sin offisielle prisside. Når en versjon går inn i den utvidede støtteperioden, måned 15 til rundt måned 24, legges det til et eget gebyr på 0,50 dollar per klynge i timen, slik at totalprisen også her lander på 0,60 dollar per klynge i timen.
Det finnes ett unntak. Google sin egen kunngjøring av utvidet support beskriver at gebyret på 0,50 dollar i timen er inkludert i GKE Enterprise-utgaven uten ekstra påslag. Selskaper som allerede betaler for GKE Enterprise, unngår altså den synlige prishoppet, men betaler i stedet gjennom den dyrere plattformlisensen. For alle andre, altså standard GKE-kunder på Extended-kanalen, er seksdoblingen like reell som hos AWS.
Azure AKS: Long Term Support krever Premium-nivå
Microsoft har valgt en litt annen struktur. AKS opererer med tre nivåer for klyngeforvaltning: en gratis Free-tier uten SLA, en Standard-tier med SLA til 0,10 dollar per klynge i timen, og en Premium-tier som i tillegg gir tilgang til Long Term Support (LTS), ifølge Microsofts egen dokumentasjon om AKS-nivåer.
Mens standard støtte for en AKS-versjon typisk varer 12 til 14 måneder fra tilgjengelighet, gir LTS på Premium-nivået 24 måneders støtte totalt, altså dobbelt så lenge, ifølge Microsofts kunngjøring av AKS Long Term Support fra juli 2025. Flere uavhengige kostnadsanalyser, deriblant ScaleOps og Microsoft Negotiations, oppgir Premium-tieren til 0,60 dollar per klynge i timen, det samme nivået som AWS og Google lander på for utvidet support, selv om Azures egen offentlige prisside ikke viser tallet i klartekst i alle visninger.
Den viktigste forskjellen fra AWS og Google er at Azure ikke flytter kunder inn i et dyrere nivå automatisk. Man må aktivt velge Premium-tier og aktivere LTS for en versjon. Det gjør Azure-modellen mer forutsigbar, men krever samtidig at teamene faktisk kjenner til at valget finnes før den gamle versjonen går ut på dato.
Slik sammenlignes utvidet support hos de tre skygigantene
Satt opp mot hverandre blir forskjellene, og likhetene, tydeligere. Alle tre leverandører konvergerer på samme timepris for utvidet støtte, men veien dit og varigheten av standardvinduet varierer.
| Leverandør | Standardpris | Utvidet pris | Standard varighet | Utvidet varighet | Automatisk overgang |
|---|---|---|---|---|---|
| AWS EKS | 0,10 $/time (~73 $/mnd) | 0,60 $/time (~438 $/mnd) | 14 måneder | 12 måneder | Ja |
| Google GKE | 0,10 $/time (~73 $/mnd) | 0,60 $/time (~438 $/mnd) | ~14 måneder | ~10 måneder | Ja (unntak: GKE Enterprise) |
| Azure AKS | 0,10 $/time (Standard-tier) | 0,60 $/time (Premium/LTS, ifølge tredjepartsanalyser) | 12-14 måneder | Opptil 24 mnd totalt | Nei, må velges aktivt |
Det påfallende er ikke at prisene er høye i seg selv, men at alle tre selskapene, uavhengig av hverandre, har landet på nøyaktig samme sluttpris: 0,60 dollar per klynge i timen. For et driftsteam med et blandet miljø av EKS, AKS og GKE-klynger betyr det at kostnadslogikken i det minste er konsistent på tvers av skyene, selv om veien dit varierer.
Kubernetes 1.34 sin livssyklus i detalj
For å forstå hvor akutt situasjonen er for selskaper som fortsatt kjører 1.34, hjelper det å se hele tidslinjen samlet, fra åpen kildekode-utgivelsen til når den siste betalte støtten faller bort på hver skyplattform.
| Milepæl | Dato |
|---|---|
| Kubernetes 1.34 generell tilgjengelighet (åpen kildekode) | 27. august 2025 |
| Kubernetes 1.34 tilgjengelig i Amazon EKS | ~2. oktober 2025 |
| Vedlikeholdsmodus (kun kritiske rettelser, åpen kildekode) | 27. august 2026 |
| Full EOL for åpen kildekode-versjonen | 27. oktober 2026 |
| Slutt på EKS standard support (start av 0,60 $/time) | ~2. desember 2026 |
| Slutt på EKS utvidet support | ~2. desember 2027 |
Merk at åpen kildekode-prosjektets EOL-dato, 27. oktober 2026, ikke er det samme som datoen skyleverandørene begynner å ta ekstra betalt. AWS gir kundene et par ekstra uker med standard pris etter selve EOL-datoen, fordi EKS-klokken starter når versjonen ble lansert i EKS, ikke når den ble lansert oppstrøms. Det er en detalj mange team går glipp av når de planlegger oppgraderinger ut fra Kubernetes-prosjektets egne datoer alene.
Historisk bakgrunn: fra kort levetid til betalt teknisk gjeld
Modellen med betalt utvidet support er relativt ny. For få år siden var virkeligheten enklere og strengere: en Kubernetes-versjon hadde et fast, kort støttevindu, og når det løp ut, var alternativet å oppgradere, uten noe betalt mellomsteg. Det tvang frem hyppige oppgraderinger, men ga også lite fleksibilitet for regulerte bransjer med lange endringsprosesser.
Google var tidlig ute med å formalisere en betalt mellomløsning. Utvidet support-modellen med et eget gebyr på 0,50 dollar i timen ble beskrevet i Google Cloud sin offisielle kunngjøring allerede i 2024. AWS fulgte etter med sin egen 14 pluss 12-måneders modell for EKS, som i løpet av 2025 ble en fast del av prisdokumentasjonen. Microsoft kom sist med sin dedikerte AKS Long Term Support-plan, lansert i juli 2025, som ga alle da støttede Kubernetes-versjoner mulighet for et 24-måneders støttevindu mot ekstra betaling.
Det som startet som unntak for enkeltkunder med spesielle behov, er nå en fast, dokumentert del av standard prissetting hos alle tre leverandørene. Teknisk gjeld har fått en offisiell prislapp, fakturert månedlig.
Hvorfor leverandørene innfører disse gebyrene nå
Det er flere krefter som trekker i samme retning. For det første er drift av eldre, uvedlikeholdte kontrollplan reelt sett dyrere for skyleverandørene selv. Bakoverkompatible sikkerhetsrettelser og separate testløp for gamle versjoner krever ressurser som ikke lenger går til hovedutviklingen.
For det andre er det et rent økonomisk insentiv. Kostnadsblogger som CloudFix og CloudZero peker begge på at prisøkningen fungerer som et sterkt press for å få kunder til å oppgradere raskere, samtidig som den gir leverandørene en ny, forutsigbar inntektsstrøm fra kunder som uansett ikke rekker å følge tempoet i oppgraderinger. Jo flere klynger som blir stående, jo mer inntekt genereres fra en tjeneste leverandørene uansett må drifte videre av sikkerhetshensyn.
For det tredje handler det om regulatorisk press. Finansinstitusjoner, offentlig sektor og andre bransjer med strenge endringsprosesser trenger ofte lengre stabilitetsvinduer enn det åpen kildekode-prosjektets tre-versjoners policy gir rom for. Betalt utvidet support løser det problemet, men flytter samtidig kostnaden for treg endringstakt fra et rent driftsproblem til en synlig budsjettpost.
Hva dette koster bedrifter i praksis
Regnestykket er enkelt nok til å gjøre selv. Differansen mellom standard og utvidet support er omtrent 365 dollar i måneden per klynge, eller rundt 4.380 dollar i året, dersom klyngen blir stående i utvidet support et helt år. For selskaper med bare noen få klynger er dette en marginal kostnad. For større organisasjoner endrer bildet seg raskt.
| Antall klynger i utvidet support | Ekstra kostnad per måned | Ekstra kostnad per år |
|---|---|---|
| 10 klynger | ~3.650 $ | ~43.800 $ |
| 50 klynger | ~18.250 $ | ~219.000 $ |
| 100 klynger | ~36.500 $ | ~438.000 $ |
| 500 klynger | ~182.500 $ | ~2.190.000 $ |
Tallene er enkle utregninger basert på den offentlig publiserte prisdifferansen på 365 dollar per klynge i måneden, og forutsetter at klyngene blir stående i utvidet support gjennom hele perioden. Ingen av kildene i denne saken oppgir et samlet globalt markedstall for hvor mye utvidet support koster alle kunder til sammen, men eksemplene over viser hvorfor kostnadseksperter omtaler dette som noe som bør løftes til styrenivå i store organisasjoner, særlig i regulerte bransjer der oppgraderinger historisk har tatt lang tid.
Konsekvenser for norske og nordiske skybrukere
Ingen av kildene i denne saken oppgir tall spesifikt brutt ned på norske eller nordiske selskaper. Det finnes med andre ord ingen fersk, offentlig statistikk som viser hvor stor andel av norske Kubernetes-klynger som står i fare for å havne i utvidet support. Det som derimot er tydelig fra bransjekommentarer, er at finansnæringen, telekom og offentlig sektor, sektorer som er godt representert i Norge og resten av Norden, ofte har lengre og mer regelstyrte endringsprosesser enn gjennomsnittsselskapet.
Det gjør denne gruppen strukturelt mer utsatt for å bli stående på eldre versjoner når EOL-datoen passerer, uavhengig av om det skjer med vilje eller ikke. Kombinert med at norske virksomheter allerede rapporterer om sky som en voksende kostnadspost, kan en automatisk seksdobling av kontrollplan-prisen på tvers av dusinvis av klynger bli en betydelig, uventet linje i neste kvartalsrapport dersom oppgraderingsplaner ikke er på plass i god tid før oktober- og desemberfristene.
Slik unngår du å havne i utvidet support
Løsningen er i prinsippet enkel: oppgrader før fristen. I praksis krever det systematisk oversikt over hvilken versjon hver klynge kjører, og en plan for å teste og rulle ut nye versjoner i god tid.
- Kartlegg alle klynger og deres nåværende Kubernetes-versjon, inkludert test- og utviklingsmiljøer som lett blir glemt.
- Sett kalenderpåminnelser for standard support-slutt for hver versjon, ikke bare den generelle EOL-datoen fra Kubernetes-prosjektet.
- Test API-endringer og fjernede funksjoner i et eget miljø før produksjonsoppgradering, siden større versjonssprang ofte fjerner utdaterte API-er.
- Vurder om Azure AKS sin LTS-modell, som krever et aktivt valg, passer bedre for enkelte kritiske klynger enn å la dem gli inn i automatisk utvidet support.
- Bruk verktøy som overvåker versjonsstatus på tvers av sky-kontoer, slik at ansvaret ikke hviler på at én person husker fristene manuelt.
En rask kommandolinjesjekk av gjeldende klientversjon mot serverversjon er et godt utgangspunkt for å se hvor langt bak en klynge faktisk ligger:
kubectl version --output=jsonKonkurransedynamikk mellom skyleverandørene
Det mest interessante konkurransemessige trekket er hvor lite konkurranse det faktisk er på pris i denne kategorien. Når tre uavhengige selskaper med ulik kostnadsstruktur og ulik markedsposisjon lander på nøyaktig samme sluttpris, 0,60 dollar per klynge i timen, tyder det på at markedet har funnet et felles akseptert nivå for hva utvidet support bør koste, snarere enn at prisen er satt av reell priskonkurranse mellom leverandørene.
Differensieringen ligger i stedet i strukturen rundt prisen. AWS og Google flytter kunder automatisk inn i den dyrere modusen, noe som er enklere å administrere for leverandøren, men mindre fleksibelt for kunden. Azure krever et aktivt valg og tilbyr et lengre standardvindu i utgangspunktet, noe som kan gjøre AKS mer attraktivt for organisasjoner som vil unngå overraskelser, selv om den nominelle timeprisen ende opp på samme nivå.
For selskaper som kjører flere skyer samtidig, gir denne konvergensen i det minste en fordel: det er ikke lenger nødvendig å bygge helt separate kostnadsmodeller for hver plattform når det gjelder nettopp denne kostnadsposten.
Hva kostnadsmiljøet sier om trenden
Flere uavhengige kostnadsanalytikere har omtalt EKS-modellen som en reell felle for selskaper uten god versjonsstyring. Bloggen CloudZero beskriver den utvidede støtten som en direkte konsekvens av manglende oppgraderingsdisiplin, mens kostnadsoptimaliseringsselskapet CloudFix argumenterer for at fakturaen i praksis er den eneste varselmekanismen mange team får før prisøkningen slår inn. Analysebyrået bak nettstedet endoflife.ai peker på at selve regningen, ikke en forutgående e-post eller varsling, er det som i realiteten informerer kundene om at standardstøtten er over.
Den gjennomgående vurderingen i disse analysene er at seksdoblingen fungerer nettopp som tiltenkt: den er stor nok til å bli lagt merke til på et budsjett, men ikke så dramatisk at den tvinger frem en krisehåndtering. Det plasserer kostnaden et sted mellom en driftsdetalj og en reell FinOps-sak som bør følges opp systematisk, ikke bare når fakturaen kommer.
Prognoser: veien videre for skyleverandørenes supportmodeller
Basert på hvordan de tre leverandørene har beveget seg de siste par årene, er det mulig å skissere noen sannsynlige utviklingstrekk fremover.
- Flere leverandører vil trolig innføre bedre varslingssystemer i konsollene sine, gitt kritikken om at fakturaen i dag er den eneste reelle notifikasjonen.
- Prisnivået på 0,60 dollar per klynge i timen kan bli en de facto bransjestandard som andre managed Kubernetes-tilbydere også speiler, ettersom kundene allerede har akseptert nivået fra de tre store.
- Kubernetes 1.35 og 1.36 vil sannsynligvis følge samme mønster som 1.34, med de samme 14 pluss 12-måneders og 14 pluss 10-måneders vinduene hos henholdsvis EKS og GKE.
- Flere selskaper vil trolig etterspørre automatiserte oppgraderingsverktøy og versjonsstyring som en del av eksisterende FinOps-plattformer, for å unngå at menneskelig glemsel alene avgjør om en klynge havner i den dyre kategorien.
- Det er ventet at flere regulerte bransjer i Europa, inkludert i Norden, i økende grad vil budsjettere utvidet support som en fast kostnadspost fremfor et unntak, i takt med at endringsprosessene deres uansett er lengre enn 14 måneder.
Ofte stilte spørsmål om Kubernetes 1.34 og utvidet support
Når slutter Kubernetes 1.34 å motta sikkerhetsoppdateringer?
Åpen kildekode-versjonen mottar ingen flere rettelser etter 27. oktober 2026. Skyleverandørenes egne støttevinduer, som ofte strekker seg lenger, følger sine egne datoer knyttet til når versjonen ble tilgjengelig på den aktuelle plattformen.
Blir klyngen min automatisk dyrere når standardstøtten går ut?
Hos AWS EKS og Google GKE, ja. Overgangen til den høyere timeprisen skjer automatisk uten at man må gjøre noe aktivt. Hos Azure AKS må man derimot selv velge Premium-tier og aktivere Long Term Support for at det utvidede vinduet skal gjelde.
Hvor mye dyrere blir en klynge i utvidet support?
Både hos AWS og Google lander totalprisen på 0,60 dollar per klynge i timen, mot 0,10 dollar i standard support. Det tilsvarer omtrent 438 dollar i måneden mot 73 dollar, en seksdobling av kontrollplan-kostnaden.
Gjelder prisøkningen bare kontrollplanet, eller også arbeidsnodene?
Gebyrene som er omtalt her gjelder kontrollplan-forvaltningen. Kostnadene for de underliggende beregningsressursene, altså virtuelle maskiner eller noder som kjører arbeidslastene, kommer i tillegg og er uendret av denne prisendringen.
Finnes det noen måte å unngå gebyret helt uten å oppgradere?
Hos Google kan kunder med GKE Enterprise-lisens unngå det synlige tilleggsgebyret, siden det er inkludert i plattformprisen. Hos AWS og Azure finnes det ikke noe tilsvarende unntak: den eneste måten å unngå kostnaden på er å oppgradere til en versjon som fortsatt er innenfor standard support.
Hvor lenge kan man i teorien bli stående på en gammel versjon?
Hos EKS er det totale vinduet 26 måneder fra versjonen ble tilgjengelig i tjenesten, 14 måneder standard og 12 måneder utvidet. Hos GKE er det til sammen rundt 24 måneder. Hos AKS gir Premium-tier med LTS også opptil 24 måneder. Etter det er versjonen ikke lenger støttet i det hele tatt, uavhengig av hvor mye man er villig til å betale.
Påvirker dette Kubernetes 1.36 og 1.37 på samme måte?
Ja. Modellen er ikke unik for 1.34, men en fast del av hvordan alle tre leverandørene nå prissetter enhver Kubernetes-versjon som passerer sitt standard støttevindu. Neste versjon som rammes på samme måte er 1.35, med standard support hos EKS ventet å vare til rundt slutten av mars 2027.
