Kubernetes для компании: когда он оправдан, а когда нет

Kubernetes обсуждают на каждой конференции и в каждой вакансии DevOps. Для части компаний оркестратор действительно снижает риск простоев и ускоряет релизы. Для большинства МСБ он добавляет стоимость и сложность раньше, чем появляется измеримая отдача. Ниже — разбор без хайпа: что даёт K8s, когда он лишний, сколько стоит владение и какой путь безопаснее «прыжка с FTP сразу в боевой кластер».

Разворачивать Managed Kubernetes в Yandex Cloud или гибрид имеет смысл только после того, как более простые варианты исчерпаны или заведомо не подходят. Иначе через год у вас дорогая платформа и те же ручные релизы.

Что оркестратор реально меняет

K8s управляет контейнерами: деплой, масштабирование, сеть, health-проверки, rolling update. Он не чинит плохой код, не заменяет CI/CD и не превращает монолит в микросервисы сам по себе. Без пайплайна, лимитов и мониторинга «кластер есть», а выкладки всё равно через kubectl в пятницу вечером.

• Плюсы. Self-healing подов, горизонтальный автомасштабирование, единая модель окружений при зрелом GitOps, изоляция команд namespace’ами.
• Минусы. Нужны люди, стратегия секретов, понятный registry, бюджет на наблюдаемость. Cognitive load выше, чем у пары VM.

Когда Kubernetes пока не нужен

Если совпадает три и больше пунктов — сначала закройте базовый DevOps:

• одно два приложения (Bitrix, монолит PHP/Node), релизы реже раза в неделю;
• один два сервера и админ «на всё»;
• нет стабильного тестовый контур или он сильно отличается от боевой контур;
• Git и проверка кода ещё не стали нормой;
• аргумент «все внедряют K8s» без метрик нагрузки и SLA;
• нет бюджета на 0,5–1 FTE platform или абонентское сопровождение.

Для такого профиля обычно хватает VM или VPS в облаке, managed-базы и Docker Compose. Вы получите результат за недели, а не за квартал, как бывает при создании сложной платформы.

Сигналы, что оркестратор оправдан

Пример «да»: SaaS с восемью сервисами, десятки тысяч активных пользователей, релизы несколько раз в неделю. Пример «нет»: корпоративный сайт и форма заявок, два разработчика, релиз раз в две недели.

Альтернативы для малого и среднего бизнеса

Многие маркетинговые «кейсы Kubernetes» на деле закрываются Instance Groups и managed PostgreSQL за долю бюджета и сроков. Сравните полная стоимость владения до выбора оркестратора — не после покупки кластера.

Сколько стоит владение

Счёт идёт не только за control plane. Минимальный боевой контур-ready кластер в облаке — порядка 25–60 тыс. ₽/мес на worker’ы, диски, балансировщик и трафик. Эксплуатация (ingress, сертификаты, обновления версий, алерты) — 0,5–2 FTE или абонент от десятков тысяч ₽/мес. Плюс registry, GitOps, метрики, логи, секреты.

Если разница в миллион рублей в год не покупает SLA, скорость релизов или экономию на железе — финансово K8s не оправдан. VM+Compose часто укладывается заметно дешевле managed-кластера с людьми.

Managed Kubernetes vs свой кластер

Для большинства клиентов разумный старт — Yandex Managed Service for Kubernetes: control plane у провайдера, связка с VPC, ALB, Container Registry и Lockbox, автомасштабирование node groups. Свой kubeadm на своих серверах имеет смысл при жёсткой локализации или уже имеющейся виртуализации — но бюджет на platform-команду нужно закладывать явно.

«Managed» не отменяет запросы и лимиты ресурсов, пайплайн и дежурство по приложениям. Провайдер чинит плоскость управления, не ваш кривой Helm без проб.

Путь без большого взрыва

1. Стабильный Git и CI/CD с версионируемыми артефактами.
2. Приложение в Docker — одинаково на тестовый стенд разработки/тест/бой.
3. Тестовый контур на Compose или в отдельном namespace.
4. Перенос stateless-сервисов в K8s; БД — в managed, не в «голых» подах.
5. GitOps (манифесты в Git) и наблюдаемость до go-live.

Прыжок «монолит по FTP → боевой контур K8s» почти всегда заканчивается откатом на VM и разочарованием совета директоров.

Красные флаги проектов

• кластер заказали «чтобы было» — через год дорогая платформа простаивает;
• нет CI/CD, деплой руками через kubectl — хуже, чем SSH на одну VM;
• PostgreSQL в поде без оператора и бэкапов;
• один человек «знает Kubernetes» — критичный bus factor;
• нет запросы и лимиты ресурсов — OOMKill и миф «K8s глючит»;
• эксперименты сразу в боевой контур namespace.

Чеклист для руководителя

1. Если у вас больше трёх сервисов с независимым деплоем и автомасштабирование нужно чаще, чем раз в квартал, возможно, стоит рассмотреть POC Kubernetes. Если же у вас ещё нет стабильного CI/CD или бюджета на полноценную платформу, лучше сначала сосредоточиться на базе DevOps. have»?
2. ALB + Instance Groups уже исчерпаны?

Четыре и больше «да» — имеет смысл POC. Ноль–два — сначала база DevOps. Три — часто достаточно промежуточного шага без полного оркестратора.

Частые вопросы

Bitrix и 1С в Kubernetes? Обычно нет: сайт и ERP живут на VM; K8s — для окружающих API, очередей, фронтовых сервисов.

Можно «чуть-чуть Kubernetes»? POC на тестовом контуре — да. Боевой контур на трёх nano-нодах без мониторинга — нет.

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

Что делать, если кластер уже купили без эффекта? Честный аудит: либо довести CI/observability, либо упростить часть сервисов обратно на VM/Compose.

Связка с DevOps-зрелостью

Оркестратор оправдан как следующий слой после того, как команда уже умеет собирать артефакты, катить на тестовом контуре и откатываться. Если сейчас релиз — это архив по FTP и молитва, Kubernetes лишь усложнит путь к той же молитве. Сначала доведите CI, секреты, мониторинг и хотя бы один предсказуемый откат. Потом решайте, нужен ли общий scheduler на много сервисов.

Полезный промежуточный шаг для многих МСБ — контейнеры на VM или Instance Groups без полной платформы. Вы получаете воспроизводимость окружений и проще масштабируете один сервис, не оплачивая сразу всю сложность кластера. Когда сервисов станет много и одинаковый операционный опыт начнёт экономить недели — вот тогда POC Managed Kubernetes выглядит рационально, а не модно.

И ещё один честный фильтр: если единственный аргумент за Kubernetes — «так проще нанять людей», посчитайте полная стоимость владения обучения и текучки. Иногда дешевле усилить Compose/VM практики и managed-сервисы облака, чем строить platform-команду ради модного стека.

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

Если вам сказали «без Kubernetes нельзя» — спросите, какую бизнес метрику он улучшит и сколько стоит альтернатива. Часто ответ — нормальный CI/CD и managed database, а не кластер.

Если метрики показывают, что вы выросли из VM и Compose, спроектируйте миграцию в managed Kubernetes и GitOps без остановки бизнеса в рамках DevOps и CI/CD.