Kubernetes в продакшне:
когда помогает, а когда мешает
Kubernetes — правильный ответ на конкретный набор проблем. Для этих проблем он превосходен. Для всего остального — это операционная обуза. Индустрия плохо справилась с донесением этого, именно поэтому так много инженерных команд запускают Kubernetes-кластеры для трёх сервисов и восьми пользователей — и тратят непропорциональное время на борьбу с ingress-контроллерами и RBAC вместо создания продукта.
Что Kubernetes реально решает
Kubernetes создан для оркестрации большого количества контейнеров со сложными операционными требованиями. Он решает: планирование и bin-packing, rolling-развёртывания без простоя, горизонтальное автомасштабирование, мультитенантную изоляцию нагрузок через namespace и network policies, и самовосстановление через политики перезапуска подов. Если у вас есть эти проблемы — конкретно, если вы запускаете 10+ контейнеризированных сервисов с независимым развёртыванием и масштабированием — Kubernetes их решает хорошо.
Что он не решает: медленный код приложения, плохое планирование запросов к БД, неадекватную стратегию кеширования или фундаментальную сложность построения распределённых систем. Kubernetes — это инфраструктура, а не архитектура.
Реальная операционная стоимость
Производственный Kubernetes-кластер требует 0,5–1 выделенного SRE для правильной эксплуатации. Это не консервативная оценка — она отражает реальную стоимость управления: обновления версий кластера, управление пулами нод, отладка сетевых проблем, настройка storage-классов, обслуживание RBAC, обновления ingress-контроллера и управление TLS-сертификатами, реагирование на инциденты.
Если у вас команда из 5 инженеров, 0,5 FTE на операции кластера — это 10% всего инженерного потенциала на инфраструктуру, которая может быть не нужна в вашем масштабе.
Используйте Kubernetes, если у вас
- • 10+ контейнеризированных микросервисов
- • 5+ бэкенд-инженеров, работающих одновременно
- • Несколько деплоев в день на сервис
- • Пиковый трафик, требующий быстрого горизонтального масштабирования
- • Требования мультитенантной изоляции
- • Выделенный SRE для операций кластера
Избегайте Kubernetes, если у вас
- • Монолит или близкая к монолиту архитектура
- • Менее 10 инженеров суммарно
- • Менее 5 отдельных сервисов
- • Стартап моложе 18 месяцев в поиске PMF
- • Нет выделенного SRE или DevOps
- • Стабильный, предсказуемый трафик без пиков
Более простые альтернативы, заслуживающие внимания
Для 1–3 сервисов: Docker Compose на VM с systemd watchdog — легитимная производственная конфигурация. Для 3–10 сервисов: HashiCorp Nomad значительно проще в эксплуатации, чем Kubernetes, обеспечивая большинство важных функций планирования и развёртывания. Для команд, желающих нулевого управления инфраструктурой: управляемые платформы вроде Render или Railway берут развёртывание, масштабирование и инфраструктуру полностью на себя.
Когда использовать управляемый Kubernetes
Если вы определили, что Kubernetes — правильный инструмент для вашего масштаба и архитектуры, управляемый Kubernetes (где control plane обслуживается за вас) убирает самую сложную часть операций кластера. Управляемый Kubernetes Hyper App убирает нагрузку на control plane, сохраняя ваши данные и вычисления в Узбекистане для соответствия Закону № 213.
«Мы два года эксплуатировали Kubernetes с командой из 4 человек. Примерно 20% инженерного времени уходило на обслуживание кластера. После перехода на управляемый K8s это сократилось до менее 5%. Дополнительные 15% вернулись в продукт.»
— Engineering Manager, центральноазиатская SaaS-платформа