Три года назад я, воодушевлённый чужими докладами и красивыми схемами, затащил инфраструктуру небольшой студии в Kubernetes. Через четыре месяца мы откатились обратно на пару виртуальных серверов. Расскажу честно, что пошло не так, во что это обошлось и когда я снова стал убеждённым сторонником контейнерной оркестрации.
Для контекста: у нас было три сервиса — монолит API, воркер для очереди и небольшая админка, плюс база данных и кэш. Команда состояла из двух разработчиков и меня, человека с гордой должностью «и за инфраструктуру тоже». Долгое время всё это спокойно жило на одной машине через docker-compose, и жило на удивление неплохо.
Триггером стало накопление болей. Появился второй клиент с требованиями к изоляции окружений, релизы начали выходить по несколько раз в день, и один раз упавший воркер умудрился уронить веб-часть. Вот тогда я и вспомнил про Kubernetes: декларативные манифесты, самовосстановление, роллинг-обновления без простоя, одинаковые окружения для разработки и продакшена. Звучало как лекарство от всего сразу.
Где он реально окупается. Если у вас от пяти контейнеров, есть хотя бы один человек, который понимает сети и хранилища, и вы устали руками раскатывать версии по серверам — окупается. Особенно когда нужна автоподстройка числа узлов под нагрузку, ночные прогоны тяжёлых задач или несколько клиентских контуров из одного набора манифестов. И ещё сильнее это работает, когда кластер управляемый: облако само держит контрольную плоскость, а команда экономит часы на деплое.
Где не окупается. Один монолит, один сайт, две-три машины, деплой раз в неделю — Kubernetes превращается в дорогую игрушку. Я честно считал: контрольная плоскость, узлы, входной прокси, мониторинг, сбор логов, бэкапы, сертификаты, секреты. Плюс время на обучение. По моим прикидкам на поддержку кластера уходило больше часов в месяц, чем на сам продукт. При этом падало всё примерно с той же частотой, что и до переезда, просто теперь ещё и непонятнее.
Что использовать вместо. Для малого бизнеса прекрасно живёт связка виртуального сервера, docker-compose или podman, systemd для запуска, реверс-прокси для доменов и автоматических сертификатов, плюс Ansible для настройки и ночные бэкапы в объектное хранилище. Это скучно, но предсказуемо и дёшево. Есть и промежуточный вариант — управляемая платформа, куда вы отдаёте код, а масштабирование, сертификаты и логи берёт на себя провайдер.
Мои рекомендации читателям. Двигайтесь по шагам: сначала наведите порядок в деплое, вынесите конфигурацию в переменные окружения, настройте бэкапы и простой мониторинг с алертами. Потом посчитайте, сколько времени в месяц вы тратите на ручные операции и аварии. И только если счёт идёт на дни, а не на часы, смотрите в сторону оркестрации. И начинайте сразу с управляемого кластера, а не со сборки всего своими руками — сэкономите себе месяцы жизни.
Итог простой: Kubernetes — не религия, а инструмент под конкретный масштаб. Для одного-двух сервисов виртуальный сервер дешевле, проще и понятнее. Для растущей команды с десятком сервисов и потоком релизов он реально экономит нервы и время. А как у вас: на каком этапе роста вы решились перейти на оркестрацию и что стало той самой последней каплей?
Для контекста: у нас было три сервиса — монолит API, воркер для очереди и небольшая админка, плюс база данных и кэш. Команда состояла из двух разработчиков и меня, человека с гордой должностью «и за инфраструктуру тоже». Долгое время всё это спокойно жило на одной машине через docker-compose, и жило на удивление неплохо.
Триггером стало накопление болей. Появился второй клиент с требованиями к изоляции окружений, релизы начали выходить по несколько раз в день, и один раз упавший воркер умудрился уронить веб-часть. Вот тогда я и вспомнил про Kubernetes: декларативные манифесты, самовосстановление, роллинг-обновления без простоя, одинаковые окружения для разработки и продакшена. Звучало как лекарство от всего сразу.
Где он реально окупается. Если у вас от пяти контейнеров, есть хотя бы один человек, который понимает сети и хранилища, и вы устали руками раскатывать версии по серверам — окупается. Особенно когда нужна автоподстройка числа узлов под нагрузку, ночные прогоны тяжёлых задач или несколько клиентских контуров из одного набора манифестов. И ещё сильнее это работает, когда кластер управляемый: облако само держит контрольную плоскость, а команда экономит часы на деплое.
Где не окупается. Один монолит, один сайт, две-три машины, деплой раз в неделю — Kubernetes превращается в дорогую игрушку. Я честно считал: контрольная плоскость, узлы, входной прокси, мониторинг, сбор логов, бэкапы, сертификаты, секреты. Плюс время на обучение. По моим прикидкам на поддержку кластера уходило больше часов в месяц, чем на сам продукт. При этом падало всё примерно с той же частотой, что и до переезда, просто теперь ещё и непонятнее.
Что использовать вместо. Для малого бизнеса прекрасно живёт связка виртуального сервера, docker-compose или podman, systemd для запуска, реверс-прокси для доменов и автоматических сертификатов, плюс Ansible для настройки и ночные бэкапы в объектное хранилище. Это скучно, но предсказуемо и дёшево. Есть и промежуточный вариант — управляемая платформа, куда вы отдаёте код, а масштабирование, сертификаты и логи берёт на себя провайдер.
Мои рекомендации читателям. Двигайтесь по шагам: сначала наведите порядок в деплое, вынесите конфигурацию в переменные окружения, настройте бэкапы и простой мониторинг с алертами. Потом посчитайте, сколько времени в месяц вы тратите на ручные операции и аварии. И только если счёт идёт на дни, а не на часы, смотрите в сторону оркестрации. И начинайте сразу с управляемого кластера, а не со сборки всего своими руками — сэкономите себе месяцы жизни.
Итог простой: Kubernetes — не религия, а инструмент под конкретный масштаб. Для одного-двух сервисов виртуальный сервер дешевле, проще и понятнее. Для растущей команды с десятком сервисов и потоком релизов он реально экономит нервы и время. А как у вас: на каком этапе роста вы решились перейти на оркестрацию и что стало той самой последней каплей?