Docker Compose a Kubernetes nejsou přímé náhrady
| Kritérium | Docker Compose | Kubernetes | Komentář |
|---|---|---|---|
| Lokální vývoj | Výborný | Možný, obvykle těžší | Compose má nižší vstupní náklady |
| Produkce na jednom hostu | Výborný | Často zbytečně složitý | Docker tento scénář dokumentuje |
| Multi-node HA | Bez nativního cluster scheduleru | Výborný | Kubernetes udržuje workloads přes nody |
| Self-healing | Restart na hostu | Výborný | Kubernetes nahrazuje Pods a reaguje na výpadky nodů |
| Autoscaling | Ruční | HPA | Scaling podle metrik |
| Rolling updates | Ruční | HPA | Deployment obsahuje RollingUpdate a rollback |
| Provozní náklady | Nižší | Vyšší | Cluster vyžaduje další platformu a znalosti |
Docker Compose deklarativně popisuje služby, sítě, volumes, configs a secrets kontejnerové aplikace. Compose Specification je doporučený formát. [1]
Kubernetes spravuje containerized workloads a služby v clusteru a poskytuje service discovery, load balancing, storage orchestration, rollouty, rollbacky a scaling. [8]
Skutečná otázka je, zda projekt potřebuje orchestraci clusteru, nebo stačí dobře spravovaný jeden host.
V čem je Docker Compose silný
Compose sjednocuje images, environment variables, sítě, volumes, healthchecks, dependencies, secrets a configs. [1][3]
Stejnou definici lze s overrides používat v development, CI, staging i produkci. Docker tento model dokumentuje. [2]
To drží vstupní provozní náklady nízko.
Compose v produkci: jeden server je podporovaný scénář
Docker výslovně dokumentuje Compose v produkci a označuje jeden server za nejjednodušší model nasazení. [2]
V produkci dává smysl oddělit `compose.production.yaml`, upravit porty a proměnné, odstranit bind mounty kódu a nastavit restart policies. [2]
Pokud všechny kontejnery běží na jednom hostu, tento host zůstává společnou doménou selhání.
Healthchecks, závislosti a restarty
S `depends_on` a `condition: service_healthy` může Compose čekat na úspěšný healthcheck závislosti. [3][4]
Pole `restart` podporuje `no`, `always`, `on-failure` a `unless-stopped`. [3][7]
Tato odolnost zůstává omezená na stejný Docker host.
Škálování v Compose: repliky nejsou cluster
`docker compose up --scale SERVICE=N` a `docker compose scale` mohou spustit více instancí služby. [6]
Ve standardním modelu popsaném Dockerem běží Compose v produkci na jednom serveru. [2]
Compose Deploy Specification definuje `replicas`, `placement`, `resources`, `update_config` a `rollback_config`, ale `deploy` je volitelný a nepodporovaná implementace ho může ignorovat. [5][3]
Co Kubernetes přidává nad jeden host
Kubernetes udržuje požadovaný stav pomocí controllerů. Deployment je běžná abstrakce pro stateless aplikace a spravuje Pods přes ReplicaSets. [10]
Platforma umí rozdělovat repliky na nody, udržovat jejich počet, poskytovat stabilní endpointy přes Services a reagovat na chyby. [8][10][15]
Hlavní rozdíl je v této control-plane logice, ne v YAML.
Self-healing: výpadek procesu proti výpadku nodu
| Funkce | Docker Compose | Kubernetes | Rozdíl |
|---|---|---|---|
| Restart kontejneru | Ano | Ano | Oba mohou restartovat proces |
| Recovery po výpadku nodu | Ne | Ano | Kubernetes může Pod spustit na jiném nodu |
| Udržování replik | Ruční | Deklarativní | Controllery udržují požadovaný stav |
| Autoscaling podle metrik | Ne | Ano | HPA periodicky upravuje repliky |
| Stabilní endpoint | Compose síť | Service | Service abstrahuje měnící se Pods |
| Scheduling CPU/RAM | Na jednom hostu | Cluster scheduler | Scheduler zohledňuje requests |
Compose může restartovat kontejner podle restart policy, pokud Docker host funguje. [7]
Kubernetes může navíc nahrazovat Pods, udržovat repliky a reschedulovat workloads při nedostupnosti nodu. [12]
Readiness může odebrat nepřipravený Pod ze Service backendů a liveness může vyvolat restart. Špatná liveness probe může sama způsobit výpadky. [16]
Síť a service discovery
Compose vytváří aplikační sítě a komunikaci přes názvy služeb, což stačí pro mnoho single-host aplikací. [1]
Kubernetes Service poskytuje stabilní IP nebo hostname pro dynamickou množinu Pods. [15]
V multi-node clusteru je to důležité, protože Pods mohou měnit node i IP.
Autoscaling a správa zdrojů
Compose podporuje ruční scaling, ale neposkytuje controller obdobný HPA založený na metrikách clusteru. [6]
HorizontalPodAutoscaler může měnit počet replik podle CPU, paměti nebo vlastních metrik. [13]
Kubernetes podporuje `requests` a `limits`; scheduler používá requests při výběru nodu. [14]
Nasazení, rolling updates a rollback
V Compose obvykle nasazení znamená vytvořit nebo stáhnout nový image a znovu vytvořit příslušné kontejnery. Docker dokumentuje například `docker compose up --no-deps -d web`. [2]
Deployment obsahuje RollingUpdate, historii revizí a `kubectl rollout undo`. [11]
Pro časté nasazování více replik poskytuje Kubernetes tyto mechanismy přímo v orchestraci.
Databáze a stateful workloads
Compose může provozovat databáze s volumes, pokud tým přijímá single-host model a sám řeší backupy, replikaci a recovery.
StatefulSet zachovává stabilní identity Pods a může je spojit s persistent storage. [17]
StatefulSet automaticky nevytvoří vysokou dostupnost databáze. Replikace, konzistence, backupy a disaster recovery závisí na databázi a architektuře.
Provozní náklady Kubernetes jsou součást rozhodnutí
Dokumentace Kubernetes uvádí, že production-quality cluster vyžaduje plánování odolnosti, přístupů, dostupnosti a zdrojů. [9]
Kubernetes není kompletní PaaS. Logging, monitoring, alerting a další části platformy zůstávají volitelné a rozšiřitelné. [8]
Managed Kubernetes snižuje práci kolem control plane, ale konfigurace workloadů, síť, zdroje, storage a troubleshooting zůstávají týmu.
Microservices nejsou automatický důvod pro Kubernetes
Kubernetes je vhodný pro distribuované a dynamické workloads, ale několik služeb samo o sobě nevytváří potřebu clusteru. [8]
Frontend, API, worker, Redis a PostgreSQL mohou fungovat v Compose, pokud stačí jeden host a dostupnost to dovoluje.
Lepší kritéria jsou tolerance výpadku hostu, repliky, autoscaling, SLO, frekvence nasazení a počet týmů.
Kdy opravdu migrovat na Kubernetes
| Otázka | Compose dává smysl, když | Kubernetes dává smysl, když |
|---|---|---|
| Výpadek hostu | Externí recovery je dostatečné | Workload má automaticky přežít výpadek nodu |
| Škála | Vše se vejde na jeden host | Potřebujete více nodů a autoscaling |
| Nasazení | Jednoduché recreate nebo vlastní proces stačí | Potřebujete řízené multi-replica rollouty |
| Tým | Jeden nebo několik týmů spravuje jednoduchý stack | Více týmů potřebuje společnou platformu |
| Počet služeb | Počet sám o sobě není cluster problém | Provoz vyžaduje standardizaci a automatizaci |
| Platforma | Prioritou je provozní jednoduchost | Potřebujete policies, scheduling a cluster abstrakce |
Migrace dává smysl, když single-host model začne být provozním omezením, ne jen když se prodlouží `compose.yaml`.
Reálné signály jsou pokračování po výpadku nodu, automatické umisťování replik, autoscaling, řízené rollouty více služeb, sdílená platforma nebo standardní resource a network policies. [8][9][12][13]
Bez těchto požadavků může Kubernetes přidat více složitosti než hodnoty.
Praktická cesta růstu projektu
Častý postup je Dockerfile pro každou aplikaci, Compose pro development a integraci a pak Compose i v produkci, dokud stačí jeden host.
Před Kubernetes je vhodné udělat části pokud možno stateless, externalizovat sessions a soubory, přidat správné health endpoints a navrhnout resources, secrets a storage.
Compose může zůstat lokálním nástrojem i při produkčním Kubernetes.
- Začněte SLO a dostupností.
- Pokud stačí jeden host, zvažte nejprve Compose.
- Pokud výpadek hostu nesmí aplikaci zastavit, potřebujete multi-node návrh.
- Při dynamické zátěži zvažte HPA.
- Pro řízené multi-replica rollouty má Kubernetes vestavěné controllery.
- Databázi nepřesouvejte do Kubernetes jen proto, že tam běží aplikace.
- Započítejte provoz clusteru, observability, síť a upgrades.
- Vyberte nejjednodušší model, který splní požadavky.
