docker run чи docker compose up запускає контейнери на одному сервері і на цьому зупиняється. У продакшені з'являються задачі, які ця команда не розв'язує:
- сервер упав - хто перезапустить контейнери на іншому сервері?
- навантаження зросло - як запустити ще п'ять копій застосунку і розподілити між ними трафік?
- новий реліз - як замінити контейнери по одному, щоб сайт не зупинявся, і відкотитися, якщо нова версія не стартує?
- контейнер «завис», але процес живий - хто це помітить і перезапустить?
- секрети й конфігурація - як доставити їх на всі сервери безпечно?
Оркестратор - система, якій описують бажаний стан («має працювати 4 копії образу app:a1b2c3, з такими ресурсами й перевірками стану»), а вона сама постійно підтримує його на кластері серверів:
- розподіляє контейнери по вузлах з урахуванням ресурсів;
- перезапускає й переносить їх при збоях;
- робить поступові оновлення й відкати;
- дає внутрішню мережу, балансування й пошук сервісів за іменем;
- керує секретами й конфігурацією.
Основні варіанти:
- Kubernetes - стандарт індустрії, величезна екосистема, але й складність: окремі знання, налаштування, супровід. Часто як керований сервіс (EKS, GKE, AKS);
- Docker Swarm - вбудований у Docker, значно простіший, підходить для невеликих кластерів;
- PaaS поверх Docker - Kamal, Coolify, Dokploy: деплой і оновлення без повноцінного оркестратора;
- керовані контейнерні сервіси - AWS ECS/Fargate, Google Cloud Run, Fly.io.
Чи потрібна оркестрація завжди: ні. Невеликий застосунок на одному-двох серверах чудово живе з Compose, політиками перезапуску й простим скриптом деплою. Kubernetes окупається, коли сервісів і серверів багато, а команда готова його підтримувати.