Docker Compose en Kubernetes zijn geen directe vervangers
| Criterium | Docker Compose | Kubernetes | Opmerking |
|---|---|---|---|
| Lokale development | Uitstekend | Mogelijk, meestal zwaarder | Compose heeft lagere instapkosten |
| Single-host productie | Uitstekend | Vaak overkill | Docker documenteert dit scenario |
| Multi-node HA | Geen native cluster scheduler | Uitstekend | Kubernetes bewaakt workloads over nodes |
| Self-healing | Restart op host | Uitstekend | Kubernetes vervangt ook Pods en reageert op node-uitval |
| Autoscaling | Handmatig | HPA | Scaling op basis van metrics |
| Rolling updates | Handmatig | HPA | Deployment bevat RollingUpdate en rollback |
| Operationele kosten | Lager | Hoger | Cluster vraagt extra platform en expertise |
Docker Compose definieert declaratief services, netwerken, volumes, configs en secrets van een containerapplicatie. De Compose Specification is het aanbevolen formaat. [1]
Kubernetes beheert containerized workloads en services in een cluster en biedt onder meer service discovery, load balancing, storage orchestration, rollouts, rollbacks en scaling. [8]
De echte vraag is dus of het project clusterorkestratie nodig heeft of dat één goed beheerde host voldoende is.
Waar Docker Compose sterk in is
Compose brengt images, environment variables, netwerken, volumes, healthchecks, dependencies, secrets en configs samen in één model. [1][3]
Dezelfde definitie kan met overrides worden gebruikt in development, CI, staging en productie. Docker documenteert dit patroon. [2]
Dat houdt de instapkosten en operationele complexiteit laag.
Compose in productie: één server is een gedocumenteerd scenario
Docker documenteert Compose expliciet voor productie en noemt één server het eenvoudigste deploymentmodel. [2]
In productie zijn een apart `compose.production.yaml`, aangepaste poorten en variables, geen code-bind-mounts en passende restart policies gebruikelijk. [2]
Als alle containers op één host draaien, blijft die host een gedeeld foutdomein.
Healthchecks, dependencies en restarts
Met `depends_on` en `condition: service_healthy` kan Compose wachten tot een dependency zijn healthcheck doorstaat. [3][4]
Het veld `restart` ondersteunt onder meer `no`, `always`, `on-failure` en `unless-stopped`. [3][7]
Deze resilience blijft beperkt tot dezelfde Docker host.
Scaling met Compose: replicas zijn nog geen cluster
`docker compose up --scale SERVICE=N` en `docker compose scale` starten meerdere service-instances. [6]
In het standaard productiemodel van Docker blijft Compose op één server draaien. [2]
De Compose Deploy Specification definieert `replicas`, `placement`, `resources`, `update_config` en `rollback_config`, maar `deploy` is optioneel en kan worden genegeerd als een implementatie het niet ondersteunt. [5][3]
Wat Kubernetes toevoegt boven één host
Kubernetes bewaakt gewenste workload-state via controllers. Deployment is de gebruikelijke abstractie voor stateless applicaties en beheert Pods via ReplicaSets. [10]
Het platform kan replicas over nodes verdelen, aantallen bewaken, stabiele endpoints via Services bieden en op failures reageren. [8][10][15]
Dat control-plane-gedrag is het belangrijkste verschil met Compose.
Self-healing: procesfout tegenover node-uitval
| Functie | Docker Compose | Kubernetes | Verschil |
|---|---|---|---|
| Containerrestart | Ja | Ja | Beide kunnen processen herstarten |
| Recovery na node-uitval | Nee | Ja | Kubernetes kan Pod op andere node plaatsen |
| Replicas bewaken | Handmatig | Declaratief | Controllers bewaken gewenste state |
| Autoscaling op metrics | Nee | Ja | HPA past replicas periodiek aan |
| Stabiel endpoint | Compose-netwerk | Service | Service abstraheert wisselende Pods |
| CPU/RAM scheduling | Binnen één host | Cluster scheduler | Scheduler houdt rekening met requests |
Compose kan een container opnieuw starten volgens de restart policy zolang de Docker host werkt. [7]
Kubernetes kan daarnaast Pods vervangen, replica-aantallen handhaven en workloads opnieuw schedulen als een node uitvalt. [12]
Readiness kan een onklare Pod uit Service-backends halen en liveness kan een containerrestart activeren. Verkeerd ingestelde liveness probes kunnen zelf uitval veroorzaken. [16]
Netwerk en service discovery
Compose maakt applicatienetwerken en communicatie via servicenames mogelijk, voldoende voor veel single-host-applicaties. [1]
Kubernetes Service levert een stabiel IP-adres of hostname voor een dynamische set Pods. [15]
In een multi-node cluster is dit extra belangrijk omdat Pods van node en IP kunnen wisselen.
Autoscaling en resourcebeheer
Compose ondersteunt handmatig scaling, maar heeft geen equivalent van HPA op basis van clustermetrics. [6]
HorizontalPodAutoscaler kan replica-aantallen aanpassen op basis van CPU, geheugen of custom metrics. [13]
Kubernetes ondersteunt ook `requests` en `limits`; de scheduler gebruikt requests bij het kiezen van een node. [14]
Deployments, rolling updates en rollback
Bij Compose bestaat een deployment vaak uit een nieuwe image bouwen of ophalen en de relevante containers opnieuw maken. Docker documenteert bijvoorbeeld `docker compose up --no-deps -d web`. [2]
Deployment bevat RollingUpdate, revision history en `kubectl rollout undo`. [11]
Voor frequente deployments met meerdere replicas biedt Kubernetes deze mechanismen rechtstreeks in de orkestratielaag.
Databases en stateful workloads
Compose kan databases met volumes draaien als het team het single-host-model accepteert en backups, replicatie en recovery zelf beheert.
StatefulSet behoudt stabiele Pod-identiteiten en kan persistent storage koppelen. [17]
StatefulSet maakt een database niet automatisch highly available. Replicatie, consistentie, backups en disaster recovery blijven afhankelijk van database en architectuur.
De operationele kosten van Kubernetes tellen mee
De Kubernetes-documentatie stelt dat een production-quality cluster planning vereist voor resilience, toegang, beschikbaarheid en resources. [9]
Kubernetes is geen volledig PaaS. Logging, monitoring, alerting en andere platformcomponenten blijven optioneel en uitbreidbaar. [8]
Managed Kubernetes vermindert control-plane-werk, maar workloadconfiguratie, netwerk, resources, storage en troubleshooting blijven bij het team.
Microservices zijn geen automatisch argument voor Kubernetes
Kubernetes ondersteunt distributed en dynamische workloads, maar meerdere services creëren op zichzelf nog geen clusterbehoefte. [8]
Frontend, API, worker, Redis en PostgreSQL kunnen prima in Compose draaien als één host genoeg is en availability-eisen dat toelaten.
Betere criteria zijn host-failure-tolerantie, replicas, autoscaling, SLO's, deploymentfrequentie en aantal teams.
Wanneer echt migreren naar Kubernetes
| Vraag | Compose is logisch wanneer | Kubernetes is logisch wanneer |
|---|---|---|
| Hostuitval | Externe recovery voldoende is | Workload automatisch node-uitval moet overleven |
| Schaal | Alles op één host past | Meerdere nodes en autoscaling nodig zijn |
| Deployments | Eenvoudig recreate of eigen proces volstaat | Gecontroleerde multi-replica-rollouts nodig zijn |
| Team | Eén of enkele teams een eenvoudige stack beheren | Veel teams een gedeeld platform nodig hebben |
| Aantal services | Aantal alleen geen clusterprobleem is | Operations standaardisatie en automatisering vragen |
| Platform | Operationele eenvoud prioriteit heeft | Policies, scheduling en clusterabstracties nodig zijn |
Migratie is zinvol wanneer het single-host-model een operationele beperking wordt, niet simpelweg omdat `compose.yaml` langer wordt.
Concrete signalen zijn doorgaan na node-uitval, automatische plaatsing van meerdere replicas, autoscaling, gecontroleerde rollouts van veel services, een gedeeld platform of gestandaardiseerde resource- en netwerkpolicies. [8][9][12][13]
Zonder deze eisen kan Kubernetes meer complexiteit dan waarde toevoegen.
Een praktisch groeipad
Een gangbaar pad is Dockerfile per applicatie, Compose voor development en integratie en daarna ook Compose in productie zolang één host voldoet.
Voor Kubernetes is het verstandig workloads waar mogelijk stateless te maken, sessions en files te externaliseren, goede health endpoints toe te voegen en resources, secrets en storage vooraf te ontwerpen.
Compose kan lokaal blijven bestaan terwijl productie Kubernetes gebruikt.
- Begin met SLO's en beschikbaarheid.
- Als één host volstaat, beoordeel eerst Compose.
- Als hostuitval de applicatie niet mag stoppen, ontwerp multi-node.
- Bij dynamische load, beoordeel HPA.
- Voor gecontroleerde multi-replica-rollouts biedt Kubernetes ingebouwde controllers.
- Verplaats een database niet naar Kubernetes alleen omdat de applicatie daar draait.
- Neem clusterbeheer, observability, netwerk en upgrades mee in de kosten.
- Kies het eenvoudigste model dat de eisen haalt.
