Kubernetes внедрили, а эффекта нет: когда оркестратор оправдан

Кластер появился в отчёте для совета директоров как символ «современной платформы». В облачном кабинете горят worker-ноды, в вакансиях мелькает Kubernetes, в чате DevOps — бесконечные разборы YAML. А бизнес спрашивает простую вещь: релизы стали чаще и спокойнее? Простой сократился? Счёт за инфраструктуру хотя бы объясним? Часто ответ честный: оркестратор «есть», эффекта нет.

Речь не против Kubernetes, а про облачную платформу как инвестицию: когда managed K8s окупается, а когда компания оплачивает сложность, которую не умеет конвертировать в SLA и скорость поставки. Угол другой, чем у споров «нужен ли DevOps-ритуал»: здесь про ценность платформы, управление облачными затратами и реальность managed-кластеров.

Что обещали и что получили

Обещали: самолечение, автоскейл, одинаковые окружения, zero-downtime. Получили: kubectl вручную, один namespace на всё, базу в поде «временно», счета за простаивающие ноды и релизы всё тем же пятничным окном. Оркестратор не заменяет CI/CD, наблюдаемость и дисциплину лимитов. Он усиливает зрелый конвейер — и усиливает хаос, если конвейера нет.

• платформу заказали по моде, без метрики успеха;
• control plane managed, а эксплуатация приложений осталась кустарной;
• управление облачными затратами показывает, что вычислительные ресурсы растут, продукт — те же два релиза в месяц;
• знания о кластере у одного человека — bus factor как у старого «сервера под столом».

Когда оркестратор оправдан с точки зрения платформы

Если у вас один-два монолита, релизы раз в две недели и админ «на всё», облачная ценность чаще в managed БД, балансировщике и нормальных VM/Instance Groups, а не в полном Kubernetes.

управление облачными затратами: скрытая цена «кластера для галочки»

Считают control plane и забывают: избыточные worker’ы, балансировщики, registry, логи, мониторинг, NAT, трафик, время инженеров. Минимальный боевой контур-ready контур в облаке легко выходит на десятки тысяч рублей в месяц только за железо и сервисы — плюс 0,5–2 FTE или абонент на эксплуатацию. Если после года платформа не ускорила срок релизов и не снизила аварийность, вы купили статус, не рычаг.

Честный вопрос к архитектору: какую строку P&L улучшает этот кластер — выручку за счёт доступность, маржу за счёт утилизации, скорость гипотез? Если ответа нет, оркестратор рано.

Managed Kubernetes: что реально снимает провайдер

Yandex Managed Service for Kubernetes и аналоги берут на себя control plane, обновления плоскости управления, интеграции с VPC и реестром. Они не пишут за вас Helm-чарты, не ставят запросы и лимиты ресурсов, не чинят приложение без readiness-проб и не строят отчёт по облачным затратам. «Managed» снижает операционную боль платформы, но не отменяет необходимость platform-практик.

Типичная иллюзия: «раз кластер managed — можно без мониторинга и политики ресурсов». Итог — OOMKill, шумные соседи по нодам, сюрпризы в счёте за диски и Load Balancer.

Когда выгоднее остаться на более простой схеме

• сайт и пара API на VM + managed PostgreSQL;
• пара контейнеров на Docker Compose / одной VM;
• Instance Groups для одного stateless-сервиса с автоскейлом;
• serverless для редких задач и вебхуков.

Эти варианты дают облачную ценность быстрее: меньше нагрузка на внимание, короче срок до пользы, проще объяснить директору архитектуру за пять минут. Kubernetes имеет смысл, когда простые схемы уже упираются в операционную потолок.

Как отличить «платформу» от декорации

1. Релиз идет из CI в кластер без ручного kubectl на проде.
2. Есть тестовый контур, близкий к боевой контур, и откат.
3. Ресурсы ограничены, алерты на насыщение нод и ошибки деплоя живые.
4. Секреты не в Git в открытом виде.
5. Ежемесячно виден затраты per service или хотя бы per namespace.
6. Метрика бизнеса (частота релизов, MTTR, ошибка 5xx) сравнивается с исходный уровень «до K8s».

Если пунктов меньше трёх — сначала доберите дисциплину, иначе любой оркестратор останется дорогим декором.

Типовые провалы cloud-проектов с K8s

Перенос монолита «как есть» без разрезания и без готовности к probes — получаете сложный способ запускать один контейнер. Хранение state в кластере без оператора и бэкапов. Отсутствие бюджетных алертов: через квартал сюрприз от управление облачными затратами. Найм «человека с сертификатом» вместо продукта платформы с регламент. Смешение dev и боевой контур в одном кластере без политик — экономия, которая бьёт по инцидентам.

Чеклист: оставить, упростить или вырастить

• есть ли измеримая цель платформы на 6–12 месяцев;
• сравнили ли полная стоимость владения с VM + управляемая БД + CI;
• готово ли приложение к rolling update;
• кто дежурит по кластеру и что в регламент;
• виден ли waste: пустые ноды, забытые Load Balancer, старые PVC;
• нужен ли полный K8s или хватит Instance Groups / Compose.

FAQ

Мы уже заплатили за кластер — откатываться стыдно? Стыднее год платить за простой. Часть сервисов можно вернуть на VM, оставив K8s там, где он реально нужен.

Managed всегда лучше self-hosted? Для большинства МСБ в РФ — да, если нет жёстких причин держать control plane у себя.

K8s обязателен для «облачной стратегии»? Нет. Облачная стратегия — про управляемость, стоимость и скорость. Оркестратор — один из инструментов.

С чего начать, если эффекта нет? С метрик релиза и затраты map. Потом — либо упрощение, либо дозревание CI/observability, либо осмысленный POC на одном сервисе.

Как разговаривать с бизнесом про платформу

Директору не нужен рассказ про Controllers и CRD. Ему нужны три числа: стоимость владения за год, частота успешных релизов, среднее время восстановления после инцидента. Если после внедрения Kubernetes эти числа не улучшились, оркестратор не «недостаточно настроили» — его ценность для этой компании пока не доказана. Иногда правильный ход — сузить кластер до двух сервисов, а монолит вернуть на VM: меньше шума, понятнее управление облачными затратами, спокойнее поддержка.

Полезный критерий через полгода: может ли новый инженер за день разобраться, как запустить сервис и что делать при сбое? Если нет — платформа слишком сложна относительно зрелости команды, и эффект бизнеса будет нулевым, сколько бы логотипов CNCF ни висело в чате.

Следующий шаг

Если Kubernetes в облаке есть, а бизнес-эффект не объясняете без слайда с логотипом — пора честно решить: довести платформу до управляемого состояния или упростить архитектуру. Оба пути нормальны; дороже всего вечный промежуточный статус.

Разобрать утилизацию, схему окружений и целесообразность managed K8s можно в рамках облачных решений — с упором на ценность платформы и предсказуемый счёт, а не на «кластер ради кластера».