Docker Compose a Kubernetes nie sú priame náhrady
| Kritérium | Docker Compose | Kubernetes | Komentár |
|---|---|---|---|
| Lokálny vývoj | Výborný | Možný, zvyčajne ťažší | Compose má nižšie vstupné náklady |
| Produkcia na jednom hoste | Výborný | Často zbytočne zložitý | Docker tento scenár dokumentuje |
| Multi-node HA | Bez natívneho cluster schedulera | Výborný | Kubernetes udržiava pracovné zaťaženia cez uzly |
| Self-healing | Reštart na hoste | Výborný | Kubernetes nahrádza Pods a reaguje na výpadky uzlov |
| Autoscaling | Ručný | HPA | Škálovanie podľa metrík |
| Rolling updates | Ručný | HPA | Deployment obsahuje RollingUpdate a rollback |
| Prevádzkové náklady | Nižšie | Vyššie | Klaster vyžaduje ďalšiu platformu a znalosti |
Docker Compose deklaratívne opisuje služby, siete, volumes, configs a secrets kontajnerovej aplikácie. Compose Specification je odporúčaný formát. [1]
Kubernetes spravuje kontajnerové pracovné zaťaženia a služby v klastri a poskytuje service discovery, load balancing, storage orchestration, rollouty, rollbacky a škálovanie. [8]
Skutočná otázka je, či projekt potrebuje orchestráciu klastra, alebo stačí dobre spravovaný jeden host.
V čom je Docker Compose silný
Compose spája images, environment variables, siete, volumes, healthchecks, dependencies, secrets a configs do jedného modelu. [1][3]
Rovnakú definíciu možno s override súbormi používať v development, CI, staging aj produkcii. Docker tento model dokumentuje. [2]
To drží vstupnú prevádzkovú zložitosť nízko.
Compose v produkcii: jeden server je dokumentovaný scenár
Docker výslovne dokumentuje Compose v produkcii a označuje jeden server za najjednoduchší model nasadenia. [2]
V produkcii dáva zmysel oddeliť `compose.production.yaml`, upraviť porty a premenné, odstrániť bind mounty kódu a nastaviť restart policies. [2]
Ak všetky kontajnery bežia na jednom hoste, tento host zostáva spoločnou doménou zlyhania.
Healthchecks, závislosti a reštarty
S `depends_on` a `condition: service_healthy` môže Compose čakať na úspešný healthcheck závislosti. [3][4]
Pole `restart` podporuje `no`, `always`, `on-failure` a `unless-stopped`. [3][7]
Táto odolnosť zostáva obmedzená na rovnaký Docker host.
Škálovanie v Compose: repliky nie sú klaster
`docker compose up --scale SERVICE=N` a `docker compose scale` môžu spustiť viac inštancií služby. [6]
V štandardnom modeli popísanom Dockerom beží Compose v produkcii na jednom serveri. [2]
Compose Deploy Specification definuje `replicas`, `placement`, `resources`, `update_config` a `rollback_config`, ale `deploy` je voliteľný a nepodporovaná implementácia ho môže ignorovať. [5][3]
Čo Kubernetes pridáva nad jeden host
Kubernetes udržiava požadovaný stav pomocou controllerov. Deployment je bežná abstrakcia pre stateless aplikácie a spravuje Pods cez ReplicaSets. [10]
Platforma môže rozdeľovať repliky na uzly, udržiavať ich počet, poskytovať stabilné endpointy cez Services a reagovať na chyby. [8][10][15]
Hlavný rozdiel je v tejto control-plane logike, nie v YAML.
Self-healing: výpadok procesu proti výpadku uzla
| Funkcia | Docker Compose | Kubernetes | Rozdiel |
|---|---|---|---|
| Reštart kontajnera | Áno | Áno | Oba môžu reštartovať proces |
| Recovery po výpadku uzla | Nie | Áno | Kubernetes môže Pod spustiť na inom uzle |
| Udržiavanie replík | Ručne | Deklaratívne | Controllery udržiavajú požadovaný stav |
| Autoscaling podľa metrík | Nie | Áno | HPA periodicky upravuje repliky |
| Stabilný endpoint | Compose sieť | Service | Service abstrahuje meniace sa Pods |
| Scheduling CPU/RAM | Na jednom hoste | Cluster scheduler | Scheduler zohľadňuje requests |
Compose môže reštartovať kontajner podľa restart policy, ak Docker host funguje. [7]
Kubernetes môže navyše nahrádzať Pods, udržiavať repliky a znovu plánovať pracovné zaťaženia pri nedostupnosti uzla. [12]
Readiness môže odobrať nepripravený Pod zo Service backendov a liveness môže vyvolať reštart. Zlá liveness probe môže sama spôsobiť výpadky. [16]
Sieť a service discovery
Compose vytvára aplikačné siete a komunikáciu cez názvy služieb, čo stačí pre mnohé single-host aplikácie. [1]
Kubernetes Service poskytuje stabilnú IP alebo hostname pre dynamickú množinu Pods. [15]
V multi-node klastri je to dôležité, pretože Pods môžu meniť uzol aj IP.
Autoscaling a správa zdrojov
Compose podporuje ručné škálovanie, ale neposkytuje controller podobný HPA založený na metrikách klastra. [6]
HorizontalPodAutoscaler môže meniť počet replík podľa CPU, pamäte alebo vlastných metrík. [13]
Kubernetes podporuje `requests` a `limits`; scheduler používa requests pri výbere uzla. [14]
Nasadenia, rolling updates a rollback
V Compose nasadenie zvyčajne znamená vytvoriť alebo stiahnuť nový image a znovu vytvoriť príslušné kontajnery. Docker dokumentuje napríklad `docker compose up --no-deps -d web`. [2]
Deployment obsahuje RollingUpdate, históriu revízií a `kubectl rollout undo`. [11]
Pri častých nasadeniach viacerých replík poskytuje Kubernetes tieto mechanizmy priamo v orchestrácii.
Databázy a stateful pracovné zaťaženia
Compose môže prevádzkovať databázy s volumes, ak tím prijíma single-host model a sám rieši backupy, replikáciu a recovery.
StatefulSet zachováva stabilné identity Pods a môže ich spájať s persistent storage. [17]
StatefulSet automaticky nevytvorí vysokú dostupnosť databázy. Replikácia, konzistencia, backupy a disaster recovery závisia od databázy a architektúry.
Prevádzkové náklady Kubernetes patria do rozhodnutia
Dokumentácia Kubernetes uvádza, že production-quality klaster vyžaduje plánovanie odolnosti, prístupov, dostupnosti a zdrojov. [9]
Kubernetes nie je kompletný PaaS. Logging, monitoring, alerting a ďalšie časti platformy zostávajú voliteľné a rozšíriteľné. [8]
Managed Kubernetes znižuje prácu okolo control plane, ale konfigurácia pracovných zaťažení, sieť, zdroje, storage a troubleshooting zostávajú tímu.
Microservices nie sú automatický dôvod na Kubernetes
Kubernetes je vhodný pre distribuované a dynamické pracovné zaťaženia, ale niekoľko služieb samo osebe nevytvára potrebu klastra. [8]
Frontend, API, worker, Redis a PostgreSQL môžu fungovať v Compose, ak stačí jeden host a dostupnosť to dovoľuje.
Lepšie kritériá sú tolerancia výpadku hosta, repliky, autoscaling, SLO, frekvencia nasadení a počet tímov.
Kedy naozaj migrovať na Kubernetes
| Otázka | Compose dáva zmysel, keď | Kubernetes dáva zmysel, keď |
|---|---|---|
| Výpadok hosta | Externé recovery je dostatočné | Pracovné zaťaženie má automaticky prežiť výpadok uzla |
| Škála | Všetko sa zmestí na jeden host | Potrebujete viac uzlov a autoscaling |
| Nasadenia | Jednoduché recreate alebo vlastný proces stačí | Potrebujete riadené multi-replica rollouty |
| Tím | Jeden alebo niekoľko tímov spravuje jednoduchý stack | Viac tímov potrebuje spoločnú platformu |
| Počet služieb | Počet sám osebe nie je cluster problém | Prevádzka vyžaduje štandardizáciu a automatizáciu |
| Platforma | Prioritou je prevádzková jednoduchosť | Potrebujete policies, scheduling a cluster abstrakcie |
Migrácia dáva zmysel, keď single-host model začne byť prevádzkovým obmedzením, nie len keď sa predĺži `compose.yaml`.
Reálne signály sú pokračovanie po výpadku uzla, automatické umiestňovanie replík, autoscaling, riadené rollouty viacerých služieb, zdieľaná platforma alebo štandardné resource a network policies. [8][9][12][13]
Bez týchto požiadaviek môže Kubernetes pridať viac zložitosti než hodnoty.
Praktická cesta rastu projektu
Častý postup je Dockerfile pre každú aplikáciu, Compose pre development a integráciu a potom Compose aj v produkcii, kým stačí jeden host.
Pred Kubernetes je vhodné urobiť časti podľa možnosti stateless, externalizovať sessions a súbory, pridať správne health endpoints a navrhnúť resources, secrets a storage.
Compose môže zostať lokálnym nástrojom aj pri produkčnom Kubernetes.
- Začnite SLO a dostupnosťou.
- Ak stačí jeden host, zvážte najprv Compose.
- Ak výpadok hosta nesmie aplikáciu zastaviť, potrebujete multi-node návrh.
- Pri dynamickej záťaži zvážte HPA.
- Pre riadené multi-replica rollouty má Kubernetes vstavané controllery.
- Databázu nepresúvajte do Kubernetes len preto, že tam beží aplikácia.
- Započítajte prevádzku klastra, observability, sieť a upgrades.
- Vyberte najjednoduchší model, ktorý splní požiadavky.
