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

Что Kubernetes реально решает хорошо

Не стану отрицать — есть задачи, где без него никуда. Автоматический перезапуск упавшего пода. Горизонтальное масштабирование по нагрузке. Балансировка между репликами без ручной настройки nginx. Canary-деплои, когда 5% трафика идёт на новую версию, а 95% — на старую. Это всё работает, и работает надёжно.

Если у вас микросервисная архитектура с десятками сервисов, команда DevOps, которая занимается только инфраструктурой, и нагрузка, которая действительно требует auto-scaling — Kubernetes оправдан. Это не мнение, это факт.

Что все забывают рассказать

Когда я слышу «Kubernetes — это просто», первый вопрос: «А кто будет это обслуживать?» Вот что скрывается за «простым» деплоем:

  • Ingress-контроллер. Без него у вас нет балансировки. Ставить нужно отдельно, настраивать отдельно. Nginx Ingress, Traefik, Ambassador — выбрать и настроить. Для маленького проекта это час-два, для нового инженера — день.
  • Stateful-сервисы. PostgreSQL, Redis, Kafka — всё это требует persistent volumes, правильного schedule, backup-стратегии. Без них у вас база данных умрет при первом же перезапуске пода.
  • Мониторинг и логи. Без ELK-стека или Datadog вы слепы. Pod упал — вы узнаёте об этом от клиента, который написал в чат.
  • Секреты. Kubernetes Secrets — это base64, не шифрование. Для prod нужно подключать Vault или Sealed Secrets. Ещё один слой абстракции.

Каждый из этих пунктов — отдельный проект. Не configuration, а проект. С документацией, тестами, мониторингом. И всё это — до того, как вы запустите первый контейнер с бизнес-логикой.

Чек-лист: когда Kubernetes действительно нужен

Перед тем как поднять кластер, ответьте на эти вопросы:

  1. У вас больше 20 реплик одного сервиса, которые нужно масштабировать автоматически? Если нет — вам, скорее всего, хватит docker-compose или даже одного VPS.
  2. Микросервисов больше 10? Если у вас 3 сервиса — это не микросервисная архитектура, это distributed monolith. Kubernetes для неё — избыточное усложнение.
  3. Есть выделенный DevOps? Kubernetes требует компетенций. Не «знаю что такое pod», а «умею читать events, понимаю cgroup, можем отладить OOMKill». Это отдельная роль.
  4. Бюджет позволяет? Минимальный prod-кластер в облаке — это $200–400 в месяц. Плюс экспертиза. Плюс время на миграцию. Окупается это только при соответствующей нагрузке.
  5. Нужен canary-деплой? Если вы не делаете сотни деплоев в день, ручной переключатель 5/95 через nginx upstream справляется за 5 минут.

Что использовать вместо Kubernetes

Для большинства проектов, с которыми я работаю:

  • Docker Compose + VPS. Один сервер, один docker-compose.yml, zero complexity. Масштабируется до 10 000–20 000 пользователей без проблем.
  • Managed Kubernetes. AWS EKS, Google GKE — снижают operational burden, но не убирают его полностью. Стоимость от $70/месяц за управление + ресурсы.
  • Serverless (Vercel, Render, Fly.io). Для frontend-проектов и API — вообще не нужно думать об инфраструктуре. Zero-config deployment, auto-scaling из коробки.
  • Nomad или Docker Swarm. Если Kubernetes кажется слишком тяжёлым, а кластеризация реально нужна — это промежуточные варианты с меньшим порогом входа.

Итог

Kubernetes — мощный инструмент. Но как и любой мощный инструмент, он требует навыков и опыта. Брать его «потому что все так делают» — всё равно что покупать грузовик для поездки в магазин за хлебом. Технически можно. Практически — зачем?

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