En klynge kan kun flyttes, hvis det, der ligger rundt om den, også kan. Kubernetes giver et fælles sprog for at beskrive applikationer, og det sprog forstår alle konforme udbydere. Bindingen opstår i de valg, der træffes ved siden af: hvor data ligger, hvordan pods får adgang, hvem der styrer trafikken, og hvilke af udbyderens tjenester applikationerne kalder.
Ledelsens version af emnet, hvor langt containere bringer en virksomhed, står på exit-plan.dk. Her er listen til den, der tegner og driver platformen.
Hvad konformitet dækker
Konformitetsprogrammet hos CNCF, Kubernetes’ fond under Linux Foundation, skal sikre, at hver leverandørs udgave understøtter de krævede API’er, så det er muligt at skifte mellem leverandører. Programmet siger intet om udbyderens egne tilføjelser. Det er vores læsning af programmets formål, og det er hele pointen her: alt uden for de krævede API’er er jeres eget ansvar at holde flytbart.
Ti steder, bindingen sætter sig
- Lagerklasser. Manifester, der nævner en bestemt udbyders lagerklasse ved navn, kan ikke køre andre steder uden ændring. Brug neutrale klassenavne, som I selv definerer pr. klynge.
- Annoteringer på load balancere og indgange. Udbyderspecifikke annoteringer styrer fx certifikater, interne adresser og helbredstjek. Saml dem ét sted, så de kan skiftes uden at røre hver applikation.
- Identitet for pods. Hos de tre store er der hver sin mekanisme til at give pods adgang til udbyderens tjenester. Kan I lægge adgangen gennem et eget system til hemmeligheder, er der ét sted at skifte.
- Containerregistret. Ligger aftrykkene i udbyderens register, skal de flyttes, og alle henvisninger skal rettes. Et register med jeres eget domænenavn foran gør skiftet mindre.
- Den administrerede database. Ligger databasen som en tjeneste hos udbyderen, er den ofte det tungeste led. Om den er bygget på en åben motor eller udbyderens egen, afgør, hvor stort arbejdet bliver; se Databaser: det, der afgør, om flytningen lykkes.
- Køer, funktioner og hændelser. Kalder applikationerne udbyderens egne beskedtjenester, er det kode, der skal ændres. Se Applikationer bygget på udbyderens egne tjenester.
- Operatører og tilføjelser fra udbyderen. Udvidelser, som udbyderen har installeret i klyngen, og egne ressourcetyper, der kun findes dér, følger ikke med.
- Overvågning og logs. Sendes alt direkte til udbyderens tjeneste, skal alarmer og dashboards bygges om. Et åbent format og en opsamler, I selv styrer, holder døren åben.
- Infrastruktur som kode. Er klyngen og netværket beskrevet med udbyderens egne moduler, skal beskrivelsen skrives om. Værktøjet er selv en afhængighed, se Terraform og OpenTofu.
- Version. Udbyderne følger Kubernetes-udgaverne med forskellig hast. Kører I på en udgave, den nye udbyder ikke tilbyder, skal I opgradere først.
Neutral er et valg pr. punkt
Ikke alle punkter skal holdes neutrale. En administreret database kan være det rigtige valg, fordi den sparer arbejde hver dag, og så er bindingen prisen for den besparelse. Beslutningen skal bare træffes bevidst og skrives ned. For hvert punkt har I tre muligheder: brug udbyderens tjeneste og accepter bindingen, brug den med et lag imellem, så skiftet bliver mindre, eller drift det selv.
Skriv valget ned i en kort note pr. punkt: hvad I valgte, hvorfor, og hvad et skift vil kræve. Noten er det, der gør klyngen flytbar på papiret, før den nogensinde er flyttet.
Prøv det i lille skala
Den eneste måde at vide, om klyngen kan flyttes, er at flytte et stykke af den. Tag én applikation med data, og få den op i en tom klynge hos en anden udbyder eller på egne servere. Det, der fejler, er listen over de bindinger, I ikke kendte. Gentag øvelsen, når platformen har ændret sig væsentligt.
Hvad det kræver, og hvad det koster at lade være
Gennemgangen af de ti punkter for en eksisterende klynge tager for en arkitekt, der kender den, fra tre dage til to uger, afhængigt af hvor mange teams og applikationer der er. Prøveflytningen af én applikation kommer oveni med nogle dage. For en ny platform koster det næsten intet at vælge neutralt fra starten; det er en linje i designet frem for et projekt bagefter.
Lader I være, vokser bindingerne stille, fordi hver enkelt tjeneste er bekvem at tage i brug. Den dag et skifte bliver aktuelt, af pris, af ejerskab eller af krav fra en kunde, er der ingen oversigt over, hvad det vil kræve, og overslaget bliver et gæt.
Det skal I lade være med
- At sige, at platformen er flytbar, fordi den kører Kubernetes · konformiteten dækker de fælles API’er og ikke resten.
- At forbyde alle udbyderens tjenester · det kan koste mere i daglig drift, end et skifte nogensinde vil.
- At lade bindingerne stå uden note · uden note kan ingen regne på et skifte.
Det skal valget kunne vise
- ☐ De ti punkter gennemgået for jeres klynge.
- ☐ En note pr. punkt med valg, begrundelse og hvad et skift kræver.
- ☐ Neutrale navne på lagerklasser og samlede annoteringer, hvor det er valgt.
- ☐ En prøveflytning af én applikation med data.
Kilder
- CNCF, Certified Kubernetes Software Conformance, læst 8. november 2026.
- Kubernetes, Releases, læst 8. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Tag de ti punkter, og sæt et kryds ved dem, jeres klynge bruger i dag. Skriv derefter noten for de tre tungeste.
Læs også: Også den europæiske udbyder skal kunne forlades · Data i Kubernetes
→ Kontakt · Tlf. 70 13 63 23 · Jurisdiktions- og afhængighedsvurdering hos Nielco IT
