Kubernetes: что обнаруживают основатели после миграции
Честный разбор операционных и финансовых реалий Kubernetes для компаний среднего размера - то, чего не говорят в презентациях про контейнеры.
Kubernetes стал де-факто стандартом для запуска контейнеризованных приложений. Крупные облачные провайдеры предлагают managed-сервисы, которые убирают операционную сложность управления кластером. Конференции и блоги полны историй успеха. Складывается ощущение, что для любого серьёзного продукта - это очевидный выбор.
Я хочу добавить к этой картине то, что обычно остаётся за кадром - реалии, которые компании обнаруживают через 6-12 месяцев после миграции на Kubernetes.
Первый сюрприз: счёт за облако вырос
Kubernetes добавляет собственный слой ресурсопотребления. Системные компоненты кластера - control plane, мониторинг, логирование, сетевые плагины - требуют ресурсов, которые не работают напрямую на ваши приложения. В managed-сервисах это частично скрыто, но не бесплатно.
Более существенная проблема - переаллокация ресурсов. Kubernetes работает на основе запросов и лимитов ресурсов, которые команды задают для своих сервисов. На практике запросы часто выставляются с запасом. В результате ноды кластера заняты на 20-30% вместо 60-70%, а платит компания за всё выделенное железо.
Это не проблема Kubernetes - это проблема отсутствия дисциплины ресурсного планирования. Но Kubernetes делает её видимой и масштабируемой.
Второй сюрприз: нужна специализированная экспертиза
"Managed Kubernetes убирает операционную сложность" - это правда, но не вся правда. Управлять кластером не нужно. Но понимать, как Kubernetes работает, для диагностики проблем всё равно нужно.
Когда сервис периодически перезапускается - нужно разбираться в liveness probes и resource limits. Когда деплой встаёт - понимать, что происходит с rolling updates и pod disruption budgets. Когда стоимость кластера неожиданно растёт - уметь читать метрики и находить, где ресурсы расходуются напрасно.
Это отдельная дисциплина. Хороший backend-разработчик не является автоматически специалистом по Kubernetes. Если в команде нет человека с этой экспертизой - операционные проблемы будут накапливаться.
Третий сюрприз: сложность не исчезает, она перемещается
До Kubernetes: "как задеплоить изменение в продакшн?". После Kubernetes: "как правильно настроить helm chart, почему pod не стартует, как работает ingress, как настроить horizontal pod autoscaler?".
Сложность не уменьшается - она переходит с уровня операционной системы и конфигурации серверов на уровень Kubernetes-абстракций. Для опытной команды это улучшение. Для команды без этого опыта - это другой вид той же проблемы.
Когда Kubernetes оправдан
Несколько ситуаций, где Kubernetes даёт реальную ценность:
- Много независимых сервисов (10+), которые нужно деплоить и масштабировать по-разному.
- Нужна возможность масштабировать конкретный сервис под нагрузку без затрагивания остальных.
- Несколько команд деплоят независимо, и нужно управлять изоляцией и ресурсами.
- Есть инженеры с реальным опытом Kubernetes или бюджет на их привлечение.
Если этих условий нет - более простая инфраструктура (managed-сервисы, PaaS, контейнеры без оркестратора) часто лучше соответствует потребностям и дешевле в эксплуатации.
Вопросы перед принятием решения о Kubernetes
- Сколько у вас независимо деплоируемых сервисов сейчас и через два года?
- Есть ли в команде или на рынке доступны инженеры с реальным опытом Kubernetes?
- Какова стоимость обучения команды или найма нужных специалистов?
- Что конкретно в текущей инфраструктуре не работает так, как нужно - и решит ли это Kubernetes?
- Посчитана ли полная стоимость владения: не только кластер, но и инженерное время на эксплуатацию?
Kubernetes - отличный инструмент для тех задач, для которых он создан. Но "Kubernetes потому что так делают большие компании" - это не техническое решение.