Три года назад я с гордостью выкатил наш первый кластер Kubernetes. Помню тот день, когда все сервисы поднялись, health-check позеленел, и я написал в общий чат: «Всё, теперь мы как большие». Тогда мне казалось, что мы сэкономим кучу денег на инфраструктуре и будем масштабироваться одним движением руки. Сейчас, спустя десятки инцидентов и несколько бюджетных циклов, я могу честно сказать: Kubernetes обошёлся нам заметно дороже, чем любая другая технология в стеке. И дороже не только в деньгах.
Первое, о чём почти никто не считает, — это люди. Kubernetes не покупают, его осваивают. Нам понадобился инженер, который действительно понимает, что происходит с control plane, почему под висит в Pending и как читать события в кластере. Это не задача на пару вечеров после работы. Мы платили за обучение, за сертификацию, за время, которое сильные разработчики тратили не на продукт, а на борьбу с YAML. По сути, мы завели ещё один продукт внутри компании — внутреннюю платформу, у которой никогда не будет пользователей снаружи, но всегда будут требования внутри.
Второй слой расходов — инфраструктурный. Когда я считал смету до переезда, я сравнивал цену пары виртуальных машин с ценой нод. Это была ошибка новичка. В реальности добавились управляемый control plane, балансировщики, ingress-контроллеры, отдельный кластер под мониторинг, хранилище для логов, приватный реестр образов, бэкапы etcd, а заодно сетевой трафик между зонами, который незаметно капает каждый день. Плюс n+1 ноды на всякий случай, потому что «а вдруг упадёт зона». Каждый из этих пунктов выглядит мелочью, но вместе они превращают скромный стартапный бюджет в нечто, что приходится защищать на каждом совещании.
Третий и, пожалуй, самый болезненный пункт — скорость. Раньше, чтобы выкатить фикс, мне хватало одной команды в терминале. Теперь это образ, тег, манифест, политики, секреты, проверка ресурсов, пробы, и только потом — долгожданный rollout. Я не жалуюсь на процесс как таковой: он безопаснее и предсказуемее. Но я честно признаю, что за иллюзию порядка мы платим временем. А время инженеров — самый дорогой ресурс, который у нас есть.
Дальше начинается то, что я называю «налогом на сложность». Мы купили коммерческую поддержку, потому что без неё некоторые вопросы решались неделями. Мы подписались на дополнительные сервисы логирования и трейсинга, потому что встроенных средств категорически не хватало. Мы наняли консультантов, когда миграция застопорилась. Ни один из этих чеков не был в первоначальном расчёте, но все они были неизбежны. И самое забавное: чем больше мы строили, тем больше нам хотелось строить дальше — операторы, service mesh, GitOps, политики безопасности. Инструменты для управления инструментами. Классическая снежная лавина.
При этом я не хочу сказать, что Kubernetes — зло. Вовсе нет. Когда у вас десятки команд, сотни сервисов, строгие требования к отказоустойчивости и потребность в едином стандарте деплоя, он окупается и даже спасает. Проблема в другом: многие тащат его туда, где достаточно пары контейнеров и нормального CI. Я видел проекты из трёх сервисов на кластере с двумя дюжинами надстроек, и там оркестрация стоила дороже, чем сам продукт. Это не технический выбор, это выбор из соображений престижа.
Если вы сейчас стоите перед таким решением, вот что я бы посоветовал исходя из своего опыта. Считайте полную стоимость владения, а не только цену нод: зарплаты, обучение, поддержку, мониторинг, трафик и время на эксплуатацию. Начинайте с управляемого решения, чтобы не тратить силы на то, что должны делать за вас. Проверьте, действительно ли вам нужны все эти абстракции прямо сейчас, или достаточно простого оркестратора контейнеров и хорошего пайплайна. И обязательно заложите в план бюджет на внутреннюю платформу — потому что вы её построите, хотите вы этого или нет. А ещё честно спросите себя: мы уходим в Kubernetes, чтобы решить конкретную боль, или чтобы красиво выглядеть на конференции?
В итоге я не жалею о переезде, но я стал гораздо спокойнее относиться к модным технологиям и внимательнее — к цифрам. Kubernetes — это не билет в светлое будущее, а инструмент со своей ценой и своим порогом входа. А как у вас на проектах: оркестрация уже приносит больше пользы, чем хлопот, или вы всё ещё считаете её рентабельность? Поделитесь цифрами и историями — уверен, вместе мы соберём куда более честную картину, чем любая маркетинговая презентация.
Первое, о чём почти никто не считает, — это люди. Kubernetes не покупают, его осваивают. Нам понадобился инженер, который действительно понимает, что происходит с control plane, почему под висит в Pending и как читать события в кластере. Это не задача на пару вечеров после работы. Мы платили за обучение, за сертификацию, за время, которое сильные разработчики тратили не на продукт, а на борьбу с YAML. По сути, мы завели ещё один продукт внутри компании — внутреннюю платформу, у которой никогда не будет пользователей снаружи, но всегда будут требования внутри.
Второй слой расходов — инфраструктурный. Когда я считал смету до переезда, я сравнивал цену пары виртуальных машин с ценой нод. Это была ошибка новичка. В реальности добавились управляемый control plane, балансировщики, ingress-контроллеры, отдельный кластер под мониторинг, хранилище для логов, приватный реестр образов, бэкапы etcd, а заодно сетевой трафик между зонами, который незаметно капает каждый день. Плюс n+1 ноды на всякий случай, потому что «а вдруг упадёт зона». Каждый из этих пунктов выглядит мелочью, но вместе они превращают скромный стартапный бюджет в нечто, что приходится защищать на каждом совещании.
Третий и, пожалуй, самый болезненный пункт — скорость. Раньше, чтобы выкатить фикс, мне хватало одной команды в терминале. Теперь это образ, тег, манифест, политики, секреты, проверка ресурсов, пробы, и только потом — долгожданный rollout. Я не жалуюсь на процесс как таковой: он безопаснее и предсказуемее. Но я честно признаю, что за иллюзию порядка мы платим временем. А время инженеров — самый дорогой ресурс, который у нас есть.
Дальше начинается то, что я называю «налогом на сложность». Мы купили коммерческую поддержку, потому что без неё некоторые вопросы решались неделями. Мы подписались на дополнительные сервисы логирования и трейсинга, потому что встроенных средств категорически не хватало. Мы наняли консультантов, когда миграция застопорилась. Ни один из этих чеков не был в первоначальном расчёте, но все они были неизбежны. И самое забавное: чем больше мы строили, тем больше нам хотелось строить дальше — операторы, service mesh, GitOps, политики безопасности. Инструменты для управления инструментами. Классическая снежная лавина.
При этом я не хочу сказать, что Kubernetes — зло. Вовсе нет. Когда у вас десятки команд, сотни сервисов, строгие требования к отказоустойчивости и потребность в едином стандарте деплоя, он окупается и даже спасает. Проблема в другом: многие тащат его туда, где достаточно пары контейнеров и нормального CI. Я видел проекты из трёх сервисов на кластере с двумя дюжинами надстроек, и там оркестрация стоила дороже, чем сам продукт. Это не технический выбор, это выбор из соображений престижа.
Если вы сейчас стоите перед таким решением, вот что я бы посоветовал исходя из своего опыта. Считайте полную стоимость владения, а не только цену нод: зарплаты, обучение, поддержку, мониторинг, трафик и время на эксплуатацию. Начинайте с управляемого решения, чтобы не тратить силы на то, что должны делать за вас. Проверьте, действительно ли вам нужны все эти абстракции прямо сейчас, или достаточно простого оркестратора контейнеров и хорошего пайплайна. И обязательно заложите в план бюджет на внутреннюю платформу — потому что вы её построите, хотите вы этого или нет. А ещё честно спросите себя: мы уходим в Kubernetes, чтобы решить конкретную боль, или чтобы красиво выглядеть на конференции?
В итоге я не жалею о переезде, но я стал гораздо спокойнее относиться к модным технологиям и внимательнее — к цифрам. Kubernetes — это не билет в светлое будущее, а инструмент со своей ценой и своим порогом входа. А как у вас на проектах: оркестрация уже приносит больше пользы, чем хлопот, или вы всё ещё считаете её рентабельность? Поделитесь цифрами и историями — уверен, вместе мы соберём куда более честную картину, чем любая маркетинговая презентация.