Det tunge ved at flytte en klynge fra EKS, AKS eller GKE er de ting, klyngen har lænet sig op ad hos udbyderen: identitet, lager, indgang og overvågning. Deployments, services og de andre manifester, der beskriver jeres applikationer, kan som regel køre på en anden konform klynge med få ændringer.
EKS er Amazons administrerede Kubernetes, AKS Microsofts og GKE Googles. Alle tre er konforme med Kubernetes’ fælles API’er, og det samme gælder de europæiske tjenester, der skriver sig op til CNCF’s program. Konformiteten dækker de fælles API’er. Alt det, hver udbyder har bygget rundt om, skal I selv finde en afløser for.
Fire bindinger, der skal kortlægges
Login og identitet for pods. En pod, den mindste enhed af en eller flere containere, skal ofte hente en nøgle eller læse fra et lager hos udbyderen. Hos de tre store sker det med deres egne mekanismer: EKS Pod Identity hos Amazon, Microsoft Entra Workload ID på AKS og Workload Identity Federation på GKE. Ved en flytning skal hver eneste af disse koblinger erstattes, og det betyder, at nøgler, roller og rettigheder skal bygges op på ny hos den nye udbyder eller i et eget system til hemmeligheder.
Lager. Vedvarende volumener bestilles gennem en lagerklasse, der peger på udbyderens drivere. Navnet på klassen står ofte direkte i manifesterne. Hos den nye udbyder findes andre klasser med andre egenskaber. Hvordan EKS’, AKS’ og GKE’s lagerdrivere er bygget, er ikke gennemgået her; det, I skal gøre, er at liste hver lagerklasse, I bruger, og hvad den kan: størrelse, ydelse, øjebliksbilleder og zonebinding. Data skal flyttes for sig, se Data i Kubernetes.
Indgang og load balancere. Trafik ind i klyngen styres af udbyderens load balancere og ofte af særlige annoteringer i manifesterne, som kun den udbyder forstår. Certifikater kan være udstedt og fornyet af udbyderens egen tjeneste. Kortlæg hver indgang, hvilke annoteringer den bruger, og hvor certifikatet kommer fra.
Overvågning og logs. Metrikker og logs fra klyngen sendes ofte direkte til udbyderens overvågningstjeneste, og alarmer, dashboards og opbevaringstid er sat op dér. Det hele skal genopbygges, også det, der er dokumentation for drift over for revision eller kunder. Se Overvågning og logs.
Hertil kommer tre mindre poster, der ofte glemmes: registret, hvor containeraftrykkene ligger, udbyderens system til nøgler og hemmeligheder og den DNS-zone, der peger på klyngens indgange.
Versionen kan sætte tidsplanen
Støtteperioderne er forskellige og står i udbydernes egen dokumentation, læst 8. november 2026. Hos EKS har en mindre udgave standardsupport i 14 måneder fra udgivelsen og derefter udvidet support i 12 måneder; udvidet support er slået til som standard og afregnes ekstra ifølge AWS. AKS understøtter tre generelt tilgængelige udgaver ad gangen, og udvidet support kræver, at long-term support slås til.
Det betyder to ting for flytningen. Kører I på en udgave i udvidet support, kan den nye udbyder kræve en nyere udgave fra starten, og så er flytningen også en opgradering. Og planlægger I flytningen tæt på et supportophør, kan I ende med at opgradere den gamle klynge kort før, I forlader den. Læg derfor flytningen, så den enten kommer før en tvungen opgradering eller lige efter.
En fremgangsmåde i fire trin
- Liste. Gå alle manifester og Helm-diagrammer igennem, og marker hver linje, der nævner udbyderen: lagerklasser, annoteringer, identiteter, registre og tjenester uden for klyngen.
- Afløsere. Find for hver markering, hvad den nye udbyder tilbyder, eller hvad I selv skal drive.
- Prøveklynge. Byg en prøveklynge hos den nye udbyder med én applikation og dens data, og kør den igennem en opgradering og en gendannelse.
- Rækkefølge. Flyt applikationer uden data først og dem med data sidst.
Trinene er generel viden om flytning af klynger. Hvordan selve omstillingen af trafik og DNS planlægges, står i Omstillingen.
Hvad det kræver, og hvad det koster at lade være
Kortlægningen af bindingerne tager for én klynge med en håndfuld applikationer typisk fra en til to uger for en, der kender klyngen. Med mange teams, egne operatører og flere miljøer kan det løbe op i en måned eller mere. Prøveklyngen kommer oveni. Selve kroneudgiften kommer fra arbejdstimer, parallel drift af to klynger og en periode med dobbelt overvågning, og beløbene hører hjemme i jeres egen beregning.
Springes kortlægningen over, viser bindingerne sig én ad gangen under flytningen, ofte som en applikation, der starter fint og så ikke kan læse sin nøgle eller skrive til sit volumen. Hver af dem forlænger den periode, hvor I betaler for to miljøer.
Det skal I lade være med
- At måle flytningen på antallet af manifester · tiden går til det, der omgiver dem.
- At flytte og opgradere i samme skridt uden at vide det · tjek versionen hos den nye udbyder først.
- At lade identiteten være til sidst · den rører alle applikationer, der henter nøgler eller data.
Det skal valget kunne vise
- ☐ En liste over alle linjer i manifesterne, der nævner den nuværende udbyder.
- ☐ En afløser eller en egen løsning for identitet, lager, indgang og overvågning.
- ☐ Kubernetes-udgaven hos den nye udbyder sammenholdt med den, I kører i dag.
- ☐ En prøveklynge, der har klaret en opgradering og en gendannelse.
Kilder
- AWS, Amazon EKS Kubernetes versions, læst 8. november 2026.
- Microsoft Learn, Supported Kubernetes versions in AKS, læst 8. november 2026.
- AWS, EKS Pod Identities, læst 8. november 2026.
- Microsoft Learn, Workload identity on AKS, læst 8. november 2026.
- Google Cloud, Workload Identity Federation for GKE, læst 8. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Søg i jeres manifester efter udbyderens navn og tjenester, og tæl linjerne. Antallet giver et første billede af, hvor stort arbejdet er.
Læs også: Kubernetes gør jer ikke flytbare af sig selv · AWS- og Azure-tjenester oversat til europæiske byggesten
→ Kontakt · Tlf. 70 13 63 23 · Jurisdiktions- og afhængighedsvurdering hos Nielco IT
