Деплой и инфра
Compose vs Kubernetes: тест с выбором ответа
Суть Тест с выбором на синтез по всему юниту Compose vs Kubernetes: scope оркестрации, reconciliation, self-healing, gated-выкатки и налог на сложность относительно реального масштаба.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов поперёк всего юнита. Каждый отражает реальное решение об оркестрации — не определение для заучивания, а компромисс, который надо взвесить относительно масштаба, который у тебя реально есть.
Цель
Убедись, что связываешь scope оркестрации, reconciliation loop, self-healing, gated-выкатки и налог на сложность — и можешь решить, какой вес заслуживает конкретная нагрузка.
Викторина
Completed
Команда держит API, Postgres, Redis и worker на одной арендованной машине при скромном трафике. Нужна устойчивость к падению контейнера и один декларативный файл. Какой вес оркестрации подходит и почему?
Heads-up Это классическая ошибка «слишком рано». Маленькая команда будет владеть control plane, CNI, RBAC, ingress и YAML-разрастанием, чтобы self-heal по машинам, которых у неё нет. Мигрируй, когда реальный потолок виден — а не гипотетический.
Heads-up Так теряются единый декларативный файл Compose, именованные сети, порядок зависимостей и one-command up/down — ради нуля выгоды. Compose это пол для multi-container приложений; опускаться ниже — это ручной дрейф.
Heads-up Managed k8s снимает операции с control plane, но не концептуальную сложность — ты всё равно владеешь pods, сетью, RBAC и YAML. Это намного тяжелее, чем нужно этой однохостовой нагрузке.
Викторина
Completed
Что reconciliation loop в Kubernetes даёт такого, чего restart: always в Compose принципиально не может?
Heads-up Дело не в скорости. restart: always и так делает перезапуск на том же хосте; ценность loop в том, чтобы пережить потерю узла, чего Compose не умеет — у него нет multi-node scheduling.
Heads-up YAML в Kubernetes известно больше, а не меньше — pods, services, deployments, ingress. Это разрастание — часть налога на сложность за reconciliation, а не выгода.
Heads-up Reconciliation опирается на readiness- и liveness-probes, чтобы понимать, что значит «здоровый» — он добавляет health gating, а не убирает его.
Викторина
Completed
Сервису нужно выкатить новый релиз с нулевым downtime и автоматическим откатом, если новая версия нездорова. Чем тут отличаются Compose и Kubernetes Deployment?
Heads-up У Compose вообще нет gated-выкатки по readiness. Он перезапускает на месте с окном downtime — health-гейт и автоматический откат это именно то, что даёт только reconciliation loop.
Heads-up Всё наоборот. Rolling updates с gating по readiness встроены в Deployment; Compose перезапускает на месте. Никакой mesh для базовых rolling updates не нужен.
Heads-up Kubernetes Deployment хранит историю выкаток и может откатиться автоматически, когда новые pods не проходят readiness. У Compose такого механизма нет.
Викторина
Completed
Какие честные сигналы говорят, что нагрузка реально переросла Docker Compose?
Heads-up Размер файла не сигнал. Compose нормально держит много сервисов на одном хосте; к переходу вынуждает потребность в возможностях, которых у Compose нет — multi-node scheduling, self-healing по машинам — а не число строк.
Heads-up И Compose, и Kubernetes запускают образы контейнеров; этот общий глагол скрывает настоящую разницу. Использование образов — не повод менять оркестратор.
Heads-up Инструменты наблюдаемости ортогональны весу оркестрации — дашборды можно поставить и на один Compose-хост. Переход на k8s диктуют нужды scheduling и доступности, а не дашборды.
Викторина
Completed
Опросы стабильно ставят операционную сложность на первое место среди болей Kubernetes (~70% пользователей), а кластеры обычно держат 30–50% утилизации. Как это читает senior?
Heads-up Сложность встроена в работу распределённого control plane, а не вызвана мисконфигом. Даже хорошо настроенные кластеры несут концептуальный и операционный вес; вопрос в том, оправдан ли он твоим масштабом.
Heads-up 30–50% утилизации — это про выделенную против используемой ёмкости кластера и запас, а не про утечку памяти в рантайме. Это отражает over-provisioning относительно реальной нагрузки.
Heads-up Managed k8s снимает операции с control plane, но не концептуальную сложность и не экономику утилизации — ты всё равно владеешь pods, сетью и right-sizing кластера.
Викторина
Completed
Команде нужна multi-node устойчивость и zero-downtime выкатки, но она не хочет владеть control plane или учить весь Kubernetes. Как senior формулирует их варианты?
Heads-up Эта ложная бинарность как раз и гонит к преждевременному k8s. Swarm, Nomad и managed PaaS дают multi-node устойчивость и gated-выкатку задолго до того, как оправдан self-managed Kubernetes.
Heads-up Managed k8s снимает операции с control plane, но сохраняет всю концептуальную поверхность — pods, сеть, RBAC, YAML. Managed PaaS или Swarm часто легче для команд, которым нужны лишь scaling и выкатка.
Heads-up Самодельный multi-host Compose за балансировщиком не даёт ни self-healing, ни переноса при потере узла, ни gated-выкатки — ты вручную собираешь хрупкий оркестратор. Специализированный middle-ground инструмент — лучший ответ.
Итог
Сквозная линия — одно решение: возможности против налога на сложность, взвешенные относительно твоего реального масштаба. Scope оркестрации (один хост против многих узлов) и reconciliation loop — вот что разделяет инструменты; self-healing, gated-выкатки и autoscaling — то, что покупает loop, ценой control plane, CNI, RBAC и YAML-разрастания. Ты уходишь с Compose при реальном потолке одного хоста, реальной нужде в доступности или реальной нужде в выкатке/autoscaling — и даже тогда ответ часто middle ground (Swarm, Nomad, managed PaaS), а не self-managed Kubernetes. Покупай вес, который заслужил твой трафик.