Деплой и инфра
Compose vs Kubernetes: прими решение об оркестрации
Прочитать дерево решений — не то же, что прогнать его под давлением. Возьми реальное multi-service приложение, запусти его на Compose, намеренно найди стену — упавший контейнер, мёртвый хост, выкатку, роняющую трафик — и затем напиши решение об оркестрации, которое защитишь на design review, опираясь на наблюдаемое, а не на догадку.
Преврати ментальную модель юнита в обоснованное доказательствами решение: подними реальный Compose-стек, прозондируй ровно там, где ломается его однохостовая модель, взвесь middle ground и выдай письменную рекомендацию по оркестрации, опирающуюся на измеренное поведение, а не на моду.
Запусти реалистичное multi-service приложение под Docker Compose, эмпирически установи, где ломается его однохостовая модель, и выдай защитимую рекомендацию по оркестрации (остаться на Compose, перейти на middle ground или взять Kubernetes), подкреплённую наблюдаемыми доказательствами и честным учётом налога на сложность.
- Рабочий docker-compose.yml, который запускает весь стек одной командой и переживает падение одного контейнера через restart: always (показано, а не заявлено).
- Зафиксированные доказательства двух режимов отказа: полная потеря стека при падении хоста и измеренное окно downtime при выкатке на месте (с числами, а не оценками).
- Одностраничная памятка-решение, излагающая допущения о масштабе, наблюдаемые пределы Compose, сравнение middle ground, учёт налога на сложность Kubernetes и финальную рекомендацию — каждое утверждение привязано к доказательству или к заявленному допущению.
- Рекомендация корректно сопоставляет возможности и нужду: не берёт Kubernetes ради возможностей, которые заявленный масштаб никогда не задействует, и не игнорирует потолок одного хоста, который допущения делают неприемлемым.
- Реализуй выбранный следующий шаг для сервиса API: например, перенеси стек на Docker Swarm (docker stack deploy) и покажи rolling update с gating по healthcheck, или задеплой API на managed PaaS и покажи zero-downtime выкатку — затем сравни операционные усилия с предсказанными.
- Подними тот же стек на локальном однонодовом Kubernetes (kind/k3s/minikube): напиши Deployment, Service и readiness probe, прогони rolling update и убей pod, чтобы увидеть, как reconciliation loop его заменяет — затем опиши, сколько YAML и концептуального overhead это заняло против файла Compose.
- Добавь чек-лист/runbook решения, который сможет переиспользовать коллега: три сигнала, оправдывающих уход с Compose, middle-ground варианты, ранжированные по весу, и вопросы, которые надо задать перед тем, как тянуться к self-managed Kubernetes.
- Смоделируй точку окупаемости: при каком трафике, размере команды или цели по доступности налог на сложность Kubernetes начинает окупаться для этого приложения? Вырази это конкретным порогом, а не ощущением.
Это решение, которое ты будешь защищать на реальных design review: гоняй приложение на самом лёгком подходящем весе, находи реальный потолок наблюдением, а не слухом, честно учитывай налог на сложность и только потом выбирай — Compose, middle ground или Kubernetes — строго относительно измеренных пределов и заявленного масштаба. Сделав это однажды на реальном стеке, ты превращаешь «просто возьми Kubernetes» из рефлекса в решение, которое можешь обосновать.