Kubernetes vs. Docker er en forkert sammenligning. Det er også den første, næsten alle teams foretager. Docker pakker din applikation ned i en container; Kubernetes kører tusindvis af disse containere på tværs af en flåde af maskiner og beslutter, hvilken der skal placeres hvor. Det er to af kerneteknologierne inden for containerisering, der befinder sig på to forskellige lag i stacken.
Så det virkelige spørgsmål er ikke, hvilken du vælger. Det er, om den sidstnævnte allerede er sine driftsomkostninger værd.
Tænk på en havn. Docker er containeren: standardmål, forseglet, stabelbar, og den er ligeglad med, om indholdet er kaffe eller bildele. Kubernetes er havneadministrationen: kranerne, planlægningen, manifestet der bestemmer, hvilken container der skal på hvilket skib, og mandskabet der genlaster containeren, hvis en kran taber den. Du kan drive en lille kajplads med et par containere og en notesblok. Rotterdam har brug for havneadministrationen.
Denne artikel forklarer, hvad containerisering er, hvad Docker og Kubernetes hver især gør, hvor den reelle sammenligning ligger, og hvordan du beslutter, hvornår orkestrering kan betale sig.
Den korte version:
Docker er en platform til containerisering. Den tager din applikation og dens afhængigheder og pakker dem ind i et image, der kører ens overalt. Kubernetes er en container-orkestrator: Den tager disse images og beslutter, hvilken maskine der skal køre dem, hvor mange kopier der skal findes, hvad der sker, hvis en af dem går ned, og hvordan trafikken finder frem til dem.
Kan man bruge Docker uden Kubernetes? Ja, og de fleste teams starter præcis dér. Det omvendte er ikke rigtig tilfældet. Kubernetes har brug for noget til at bygge container-images, og for de fleste organisationer er det "noget" stadig Docker.
To navne i den tabel fortjener en definition med det samme. Docker Compose er værktøjet til at definere og køre et setup med flere containere på en enkelt maskine. Docker Swarm er Dockers egen orkestrator, og vi vender tilbage til den længere nede.
Lad os gennemgå lagene.
Containerisering gør det muligt for udviklere at pakke softwarekode og alt, hvad der kræves for at køre den (frameworks, biblioteker og andre afhængigheder), ind i en enkelt, isoleret container. Når den først er pakket, er den mobil. Enhver applikation i en container kan flyttes til en anden infrastruktur og stadig køre, uanset hvilket operativsystem eller miljø der ligger under.
Denne portabilitet er selve formålet, og sikkerheden følger med, fordi det samme build opfører sig ens på enhver maskine, du placerer det på. Men husk, at ikke alt hører hjemme i en boks. Grafikintensive desktop-applikationer virtualiseres normalt i stedet på hypervisor-laget – det lag, der kører fulde virtuelle maskiner med deres eget operativsystem ved hjælp af værktøjer som Vagrant – fordi de har brug for hardwareadgang, som en container ikke kan give dem.
Før containere skrev udviklere kode i ét computermiljø for derefter at løbe ind i problemer, så snart de flyttede den. At gå fra Linux til Windows gjorde koden sårbar over for fejl og miljøspecifikke problemer. Containere løser dette ved at abstrahere softwaren væk fra værtsoperativsystemet, så fundamentet ikke længere flytter sig under den.
Applikationer får lov til at leve i uafhængige, indkapslede miljøer. Skalerbarhed, hurtigere implementering og tættere overensstemmelse mellem miljøer: Det er de primære fordele, og udbredelsen afspejler dem. Brugen af containere blandt backend-udviklere passerede 60 % allerede i 2020 (SlashData, State of Cloud Native Development), og det er kun taget til siden da: CNCF's seneste Annual Cloud Native Survey, der blev offentliggjort i januar 2026, viste, at 82 % af de organisationer, der bruger containere, nu kører Kubernetes i produktion, hvilket er en stigning fra 66 % to år tidligere.
Konceptet er i øvrigt ældre end Docker. Linux Containers (LXC) leverede containerteknologi længe før 2013. Det, Docker ændrede med sin open source-udgivelse det år, var udvikleroplevelsen, og det er sådan, det blev standardformatet for containere. Det er det stadig: Stack Overflow Developer Survey rangerer fortsat Docker blandt de mest anvendte udviklerværktøjer, langt foran alle andre containeriseringsværktøjer.
Docker er en containeriseringsplatform, der bruges til at udvikle, distribuere og køre applikationer som bærbare, selvstændige containere. Uanset om det er på en bærbar computer, i cloud-miljøer eller i datacentre, kan det køre stort set overalt.
Gennem årene har Docker opbygget en bred platform omkring denne kerne. Det betyder dog ikke, at ethvert Docker-værktøj altid er det oplagte valg. Feltet er konkurrencepræget, og flere af lagene har stærke alternativer.
En Docker-container er en kørende instans af et Docker-image: din applikation plus alt, hvad den behøver, isoleret fra værten og fra alle andre containere. Den låner værtens operativsystemkerne i stedet for at medbringe sin egen. Det er grunden til, at en container starter på få sekunder, mens en virtuel maskine tager minutter.
Tre komponenter får det til at fungere:
Du behøver ikke altid en Dockerfile. Udviklere kan hente et færdigt image fra et register som Docker Hub eller Azure Container Registry og spare arbejdet – der er masser at vælge imellem. Så for at køre en Docker-container skal du enten hente et image fra et offentligt register eller bygge dit eget med en Dockerfile.
Det er her, disciplinen viser sig, når du bygger dit eget. En midlertidig Dockerfile og en til produktion ligner ikke hinanden. Her er den struktur, vi bruger – et multi-stage build, der holder udviklingsafhængigheder ude af det endelige image, kører som en ikke-root-bruger og producerer et lille, reproducerbart artefakt:
# syntax=docker/dockerfile:1
# IC house-standard Node/TypeScript service image.
# Multi-stage: deterministic prod dependencies, minimal non-root runtime.
ARG NODE_VERSION=22.11.0 # IC: pin by digest in production
ARG APP_PORT=3000
# ---- Stage 1: install everything and build ----
FROM node:${NODE_VERSION}-bookworm-slim AS build
WORKDIR /app
ENV NODE_ENV=development
COPY package.json package-lock.json ./
RUN --mount=type=cache,target=/root/.npm npm ci
COPY . .
RUN npm run build # IC: expects a build script emitting to ./dist
# ---- Stage 2: production dependencies only ----
FROM node:${NODE_VERSION}-bookworm-slim AS prod-deps
WORKDIR /app
ENV NODE_ENV=production
COPY package.json package-lock.json ./
RUN --mount=type=cache,target=/root/.npm npm ci --omit=dev
# ---- Stage 3: runtime ----
FROM node:${NODE_VERSION}-bookworm-slim AS runtime
ARG APP_PORT
# tini gives us correct signal handling and zombie reaping as PID 1.
RUN apt-get update \
&& apt-get install -y --no-install-recommends tini \
&& rm -rf /var/lib/apt/lists/*
WORKDIR /app
ENV NODE_ENV=production PORT=${APP_PORT}
# Copy only what runtime needs, owned by the image's built-in non-root user.
COPY --chown=node:node --from=prod-deps /app/node_modules ./node_modules
COPY --chown=node:node --from=build /app/dist ./dist
COPY --chown=node:node package.json ./
# OCI provenance labels (IC: wire GIT_SHA / BUILD_DATE from CI).
ARG GIT_SHA=unknown
ARG BUILD_DATE=unknown
LABEL org.opencontainers.image.vendor="Imaginary Cloud" \
org.opencontainers.image.revision="${GIT_SHA}" \
org.opencontainers.image.created="${BUILD_DATE}"
USER node
EXPOSE ${APP_PORT}
# Docker-level healthcheck. In Kubernetes, prefer liveness/readiness probes.
HEALTHCHECK --interval=30s --timeout=3s --start-period=10s --retries=3 \
CMD node -e "fetch('http://localhost:'+process.env.PORT+'/health').then(r=>process.exit(r.ok?0:1)).catch(()=>process.exit(1))"
ENTRYPOINT ["tini", "--"]
CMD ["node", "dist/main.js"]HEALTHCHECK-linjen er en lille demonstration af artiklens hovedtese i miniature: den virker, men i det øjeblik du kører dette image i Kubernetes, overlader du den opgave til en liveness probe i stedet. Selve buildet forbliver det samme; laget omkring det ændrer sig.
Docker bruges til at sikre, at software opfører sig ens, uanset hvor det kører. I praksis dækker det fire ting:
Derefter formerer boksene sig. I takt med at antallet af containere vokser, stiger kompleksiteten ved at administrere dem også, og en velkendt række problemer opstår, som alle falder under orkestrering:
Dockers svar var Docker Swarm, deres egen teknologi til container-orkestrering. Og dette er den detalje, som de fleste sammenligninger overser: Swarm – ikke Docker-platformen som helhed – er den komponent, der reelt kan sammenlignes med Kubernetes.
Kubernetes er en teknologi til container-orkestrering i samme kategori som OpenShift eller Amazon ECS. Google introducerede den i 2014, et år efter lanceringen af Docker, og den styres nu af CNCF, Cloud Native Computing Foundation.
Den blev bygget til at planlægge, administrere, automatisere udrulningen af og skalere containeriserede applikationer. Med andre ord håndterer den kompleksiteten ved at køre et stort antal containere på tværs af mange servere, uden at et menneske skal stå på kajen og beslutte, hvor hver enkelt kasse skal placeres.
Det gør den via et open source-API, der regulerer, hvordan og hvor containere kører. Containere grupperes i pods, den grundlæggende driftsenhed i Kubernetes. Pods kører på nodes, maskinerne i klyngen, og control plane er det sæt af komponenter, der beslutter, hvad der skal køre hvor, og som løbende retter klyngen til, når virkeligheden afviger fra den ønskede tilstand. Når de er grupperet, kan pods skaleres op eller ned, og deres livscyklus kan styres deklarativt.
Så Kubernetes orkestrerer maskiner og placerer containere på dem i henhold til tilgængelige ressourcer og hver containers krav. Dit team definerer den ønskede tilstand for en klynge; platformen håndterer planlægning, forbindelsesstyring og gendannelse. Projektet bevæger sig hurtigt – Kubernetes nåede version 1.36 i 2026 – men den deklarative kerne har været stabil i årevis.
Kubernetes understøtter en lang række containerværktøjer, herunder Docker-images, hvilket bringer os tilbage til den sammenligning, vi startede med.
Hvis vi skal sammenligne Docker og Kubernetes ordentligt, er den retfærdige kamp Docker Swarm mod Kubernetes, da begge er teknologier til container-orkestrering. Docker fører markedet for containerisering. De vandt ikke orkestrering. Det gjorde Kubernetes, og det gjorde de overbevisende: Kubernetes-arkivet har omkring 115.000 GitHub-stjerner pr. 2026, mod et par tusinde for biblioteket bag Docker Swarm, som reelt har ligget stille i årevis. Forskellen i kommerciel support er endnu større, da alle større cloud-udbydere tilbyder en administreret Kubernetes-tjeneste.
Docker og Kubernetes er komplementære teknologier. Deres roller overlapper i den brede befolkning, men overlapper knap nok i praksis. Docker producerer kasserne. Kubernetes driver havnen.
Kubernetes bringer også en række funktioner, der begynder at betyde noget, når du kører mere end en håndfuld tjenester: load balancing, netværkspolitik, håndtering af hemmeligheder, isolering mellem arbejdsbelastninger, selvhelbredelse og evnen til at skalere på tværs af alle noder i klyngen.
At få mest muligt ud af Docker og Kubernetes sammen kræver, at man er ærlig omkring, hvor nyttige de hver især er for en. Ikke alle organisationer, der kører containere, har brug for en orkestrator. Teams med små applikationer og et lavt, kontrollerbart antal containere har det generelt ikke, og tilføjelsen af en koster dem mere, end den giver igen.
I takt med at softwarebehov vokser, skal de bagvedliggende applikationer også skalere. For at få gavn af en mikrotjeneste-arkitektur skal de omkringliggende krav være opfyldt. Ellers bliver containerisering en ekstra belastning i tech-stacken frem for en fordel.
Kubernetes, eller et lignende værktøj, er derfor ikke obligatorisk. Det anbefales kraftigt til infrastrukturer, der skal skalere og håndtere et højt antal containere på tværs af distribuerede systemer. Ved enhver reel skala er orkestrering nu normen snarere end undtagelsen: CNCF's undersøgelse fra 2026 viser, at 82 % af de adspurgte organisationer bruger Kubernetes i produktion, mens en yderligere del tester eller evaluerer det – udviklingen er gået stærkt mod administreret Kubernetes, ikke væk fra orkestrering.
De fordele, som disse organisationer rapporterer, er konsistente:
Dette skabte reel bekymring, da Kubernetes 1.20 annoncerede, at Docker-support i kubelet var forældet og ville blive fjernet i en fremtidig udgivelse. Mange udviklere læste det som afslutningen på Docker, og dermed afslutningen på kombinationen af Docker og Kubernetes. Kubernetes offentliggjorde en præcisering den 2. december 2020, Gå ikke i panik: Kubernetes og Docker, og forklarede, at det ikke var så dramatisk, som det lød.
Her er, hvad der rent faktisk skete. Inde i et Kubernetes-cluster henter og kører en komponent kaldet container runtime container-images, og kubelet er den agent på hver node, der kommunikerer med den. Docker var den mest populære runtime til den opgave, men den var aldrig designet til at blive indlejret i Kubernetes. Den er bygget til at blive styret af mennesker via en kommandolinje, ikke af et andet stykke software. Derfor havde Kubernetes brug for en shim, Dockershim, til at oversætte mellem kubelet og Docker – og under Docker fik den faktisk fat i containerd, den runtime på lavere niveau, som Docker selv bruger. Et ekstra lag, der skulle vedligeholdes, uden nogen funktionel gevinst.
Fjernelsen skete. Dockershim blev fjernet fra kubelet i Kubernetes 1.24, der blev udgivet i maj 2022, og containerd er nu standard-runtime på de fleste administrerede clusters, med CRI-O – en letvægts-runtime bygget udelukkende til Kubernetes – som det primære alternativ. Det, der ikke skete, var nogen form for brud på kompatibiliteten. Images bygget med Docker følger Open Container Initiative -standarden og kører på Kubernetes præcis som før: FAQ om fjernelse af dockershim indeholder detaljerne. Så er det her enden på Docker? Nej. Kubernetes stoppede med at bruge Docker som runtime. Det stoppede aldrig med at køre Docker-images. Og fire år senere kører de stadig uden ændringer.
Hver eneste artikel om dette emne sammenligner funktioner. Meget få nævner, hvad beslutningen koster, hvilket er den del, en CTO rent faktisk skal godkende.
Kubernetes er ikke et værktøj, man bare tager i brug. Det er en platformkapacitet, man finansierer. Selve clusteret er den billige del. De dyre dele er de folk, der holder det opdateret, opgraderingskadencen, vagtplanen, arbejdet med sikkerheds- og netværkspolitikker samt de måneder, hvor leveringstakten falder, mens teamet lærer systemet at kende. Managed services fra de store cloud-udbydere fjerner en stor del af den operationelle byrde. Men ikke ejerskabet.
Vi bruger en simpel test sammen med vores kunder, som vi kalder orkestreringstærsklen. Kubernetes tjener sig selv hjem, når mindst tre af disse fem udsagn er sande:
Færre end tre? Så er den ærlige anbefaling normalt Docker med en managed container-tjeneste såsom ECS, Cloud Run eller App Service, og en note i kalenderen om at genbesøge spørgsmålet om et år.
Vi følger vores egne anbefalinger. På en nylig maritim kommunikationsplatform (Sedna), satsede vi modsat orkestrering: I stedet for at oprette en klynge, migrerede vi kundens integrationsworkflows til skræddersyede tjenester på AWS – Terraform-defineret infrastruktur, CI/CD-pipelines og Lambda-funktioner – og skar deres omkostninger til workflow-værktøjer med 80 %. Under den grænseværdi er det som regel den løsning, der bedst kan betale sig.
I vores leverancearbejde gør det samme sig gældende: Teams, der tager Kubernetes i brug under denne grænseværdi, bruger mere tid på platformen end på selve produktet i de første to kvartaler, mens teams, der tager det i brug over grænseværdien, holder op med at betragte deployment som en begivenhed inden for omtrent samme periode.
Og så er der den risiko, som ingen budgetterer med: den herreløse klynge. En Kubernetes-installation, som ingen er finansieret til at vedligeholde, ender med at blive forældet, akkumulerer ikke-opdaterede komponenter og bliver sværere at forlade, end den var at tage i brug. Et skib, som ingen får løn for at losse. Det er et ledelsesmæssigt problem længe før, det bliver et teknisk.
Containerisering er ikke den rette tilgang til alle arbejdsbelastninger, men fordelene har gjort dem værd at bemærke: bedre applikationskvalitet, højere produktivitet, mindre nedetid og hurtigere reaktion på forandringer.
Så hvordan arbejder Docker og Kubernetes sammen om at levere det?
Kassen og havnen. De supplerer hinanden, og ved at kombinere dem med DevOps-praksis får du et fundament for mikrotjenester, der understøtter hurtig levering og skalerbare cloud-native applikationer. Hvilket betyder, at spørgsmålet aldrig har været, hvilken man skal vælge. Det handler om, hvorvidt din organisation har krydset tærsklen til orkestrering. Og hvis ikke endnu, hvornår det så sker.
Ikke Docker-runtime, men næsten helt sikkert Docker-værktøjerne. Kubernetes kører containere via containerd eller CRI-O, ikke via Docker. Du har stadig brug for noget til at bygge container-images, og Docker er fortsat det mest almindelige valg til dette formål, ligesom det er standardmåden, udviklere kører containere lokalt på.
Nej. Kubernetes erstattede Docker som container-runtime i sine egne noder i version 1.24 i maj 2022. Det erstattede ikke Docker som image-format eller build-værktøj, og images bygget med Docker kører på Kubernetes uden ændringer.
En Docker-container er en kørende instans af et Docker-image: en applikation pakket sammen med sine afhængigheder, isoleret fra værtsmaskinen. Den deler værtens operativsystemkerne, hvilket er grunden til, at den starter på få sekunder og bruger en brøkdel af de ressourcer, en virtuel maskine kræver.
Docker bruges til at pakke applikationer, så de kører identisk overalt: på en udviklers bærbare computer, i en CI-pipeline og i produktion. Det understøtter arkitekturer med mikrotjenester, fjerner miljøspecifikke fejl og giver deployment-pipelines et enkelt artefakt, der kan promoveres.
Docker Swarm passer til små klynger med enkle arbejdsbelastninger, især hvor et team allerede kender Docker Compose og ønsker orkestrering uden at skulle lære en ny driftsmodel. Det er enklere og hurtigere at lære end Kubernetes. Ulempen er et meget mindre økosystem, begrænset managed hosting og en skrumpende gruppe af ingeniører, der har erfaring med det.
Ja, og det bør mange organisationer gøre. En managed container-tjeneste som AWS ECS, Google Cloud Run eller Azure Container Apps kører containere i produktion med langt mindre driftsmæssig kompleksitet end Kubernetes. Ulempen er mindre kontrol og tættere binding til én cloud-udbyder.
Overvejer du, om Kubernetes er det værd for din organisation? Fra kommunikationsplatforme i maritim skala til serverless-migreringer på AWS, vi designer og driver cloud-native platforme som teams rent faktisk kan vedligeholde – og vi er lige så villige til at fortælle dig, hvornår du ikke har brug for en. Tal med vores team om, hvor jeres infrastruktur er på vej hen.
Marketing praktikant med særlig interesse for teknologi og forskning. I min fritid spiller jeg volleyball og forkæler min hund så meget som muligt.
Sikkerheds- og cloud-driftsekspert. Baggrund i offentlig transport, Finans, og regering. Handler normalt mønter på decentrale børser:)
People who read this post, also found these interesting:
.webp)
