Mange virksomheder kan klare sig med containere på nogle få virtuelle servere eller med en platformstjeneste, hvor udbyderen kører applikationen. Kubernetes giver mening, når I har mange tjenester, der skal skaleres og opdateres hver for sig, og et team, der kan drive platformen året rundt.
Spørgsmålet dukker ofte op, når infrastrukturen alligevel skal flyttes. Det er et godt tidspunkt at stille det, fordi en flytning til en europæisk udbyder kan blive enklere, hvis platformen bliver mindre.
Docker og Kubernetes løser to forskellige ting
Docker er et værktøj til at pakke en applikation og alt, den skal bruge, i en container og køre den på én maskine. Kubernetes er et system til at køre mange containere på en gruppe maskiner: det fordeler dem, genstarter dem, når de fejler, og skifter dem ud ved en ny udgave. Søgningen “kubernetes vs docker” sammenligner altså et pakkeformat med et styresystem for en hel klynge.
Det betyder, at I godt kan bruge containere uden Kubernetes. En virtuel server med Docker og en enkel opsætning til at starte containerne kan køre en håndfuld applikationer i årevis.
Tre måder at køre det samme på
Virtuelle servere med eller uden containere. I driver styresystemet og applikationerne. Det er det letteste at flytte mellem udbydere, fordi alle har virtuelle servere, se Virtuelle servere.
En platformstjeneste. Udbyderen kører applikationen, og I leverer koden eller containeren. I slipper for styresystem og klynge, men bindes til udbyderens måde at gøre det på. Hvilke europæiske udbydere der har hvad, står i Hvad mangler hos de europæiske?.
Kubernetes, administreret eller eget. I driver applikationerne og deres beskrivelse i klyngen; ved administreret Kubernetes driver udbyderen kontrolplanen, på egne servere driver I det hele. Se Managed Kubernetes i Europa.
Det, Kubernetes koster i kompetencer
Rettelser fra projektet går kun til de tre nyeste mindre udgaver, og en udgave er dækket i omtrent tolv måneder. For at blive på en vedligeholdt udgave skal klyngen derfor opgraderes mindst én gang om året, også når den er administreret, fordi udbyderen før eller siden lukker for gamle udgaver. Opgraderingen kræver, at nogen læser ændringerne, tester applikationerne og har en plan, hvis noget fejler.
Ud over opgraderinger kræver platformen viden om netværk i klyngen, lager, rettigheder, overvågning og fejlsøgning af containere, der genstarter uden forklaring. Den viden skal findes hos mere end én person, og den skal være der om natten, hvis klyngen bærer forretningskritiske systemer. Har I ikke folkene, skal de købes hos en leverandør, og så er Kubernetes også en leverandørbinding.
Spørgsmål, der afgør det
- Hvor mange tjenester har I, og skal de skaleres og opdateres uafhængigt af hinanden?
- Hvor ofte udgiver I nye versioner, og skal det ske uden nedetid?
- Varierer belastningen så meget, at I har brug for at skalere automatisk?
- Har I i dag mindst to personer, der kan drive en klynge, eller en leverandør, der kan?
- Kører I allerede Kubernetes, og ville det koste mere at bygge det ned end at beholde det?
Svarer I nej til de første tre, er virtuelle servere eller en platformstjeneste sandsynligvis nok. Svarer I ja til flere af dem, og har I folkene, kan Kubernetes betale sig. Er svaret blandet, kan nogle systemer ligge i en klynge og resten på virtuelle servere.
Når I har den i forvejen
Har I allerede en klynge hos en amerikansk udbyder, er flytningen et naturligt tidspunkt at spørge, om den skal med. Bygges den ned til virtuelle servere, falder en del af bindingerne til udbyderens identitet, lager og indgang bort, og en europæisk udbyder med et smallere katalog kan være nok. Beholdes den, skal bindingerne kortlægges, se Fra EKS, AKS og GKE til en europæisk klynge.
Hvad det kræver, og hvad det koster at lade være
Afklaringen tager kort tid: en til to arbejdsdage for den, der kender systemerne, med spørgsmålene ovenfor og en liste over tjenesterne. Selve valget har større følger. I jeres regnestykke hører timer til opgraderinger og vagt, uddannelse, eventuel leverandørsupport og forbrug hos udbyderen på den ene side, og den tid, en mere enkel platform sparer eller koster i daglig udvikling, på den anden. Hvad der påvirker prisen, og hvordan I får et tilbud, står under pris og tilbud.
Stiller I ikke spørgsmålet, flytter klyngen med af vane. I får en platform, der skal opgraderes og bemandes, uden at nogen har set på, om den giver jer noget, virtuelle servere ikke kunne.
Det skal I lade være med
- At vælge Kubernetes, fordi alle andre gør det · tag udgangspunkt i antal tjenester og folk.
- At regne administreret Kubernetes som drift uden arbejde · opgraderinger og applikationer er stadig jeres.
- At bygge en klynge ned uden at se på, hvad den gør i dag · automatisk genstart og skalering skal erstattes.
Det skal valget kunne vise
- ☐ Antal tjenester og hvor ofte de opdateres.
- ☐ Hvem der kan drive en klynge, og hvem der afløser.
- ☐ En plan for mindst én opgradering om året, hvis I vælger Kubernetes.
- ☐ En begrundelse for valget, skrevet ned.
Kilder
- Kubernetes, Releases og Patch Releases, læst 8. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Skriv jeres tjenester op, og besvar de fem spørgsmål for dem. Svarene er grundlaget for valget af platform hos en ny udbyder.
Læs også: Med en IT-chef: hvor meget kan én person flytte? · Flyt, tilpas eller byg om
→ Kontakt · Tlf. 70 13 63 23 · Jurisdiktions- og afhængighedsvurdering hos Nielco IT
