Деплой и инфра
Compose vs Kubernetes: тест на воспроизведение
Воспроизведение по памяти бьёт перечитывание. На каждый промпт скажи или запиши полный ответ из головы прежде, чем открыть модельный — именно усилие припоминания закрепляет дерево решений об оркестрации.
Восстанови хребет юнита — scope оркестрации, reconciliation loop, self-healing, gated-выкатки, налог на сложность и middle ground — не подглядывая в урок.
- 01И Docker Compose, и Kubernetes «запускают контейнеры». В чём фундаментальная разница в том, чем они оркестрируют?
- 02Что такое reconciliation loop и почему это единственный механизм, отделяющий Kubernetes от Compose?
- 03Как работает zero-downtime rolling update с автоматическим откатом в Kubernetes и что вместо этого делает Compose?
- 04Что такое «налог на сложность» Kubernetes и какими конкретными числами он описывается?
- 05Какие конкретные сигналы говорят, что нагрузка реально переросла Docker Compose?
- 06Почему выбор между Compose и Kubernetes не бинарный и что лежит посередине?
Если ты смог восстановить каждый ответ по памяти, ты держишь хребет юнита: scope оркестрации отделяет менеджер процессов одного хоста от распределённого control plane; reconciliation loop — механизм, покупающий self-healing, gated-выкатки и autoscaling; налог на сложность (control plane, CNI, RBAC, YAML-разрастание, ~70% называют его болью №1, 30–50% утилизации, пятизначные счета) — это цена; сигналы уйти с Compose — реальный потолок одного хоста, реальная нужда в доступности или реальная нужда в выкатке/autoscaling; а выбор никогда не бинарный — Swarm, Nomad и managed PaaS лежат посередине. Покупай вес, который заслужил твой масштаб.