Kubernetes: когда он помогает, а когда добавляет сложность
Практический взгляд на оркестрацию контейнеров - для каких компаний Kubernetes решает реальные задачи и когда он создаёт больше проблем, чем устраняет.
Kubernetes к 2018 году превратился в стандартный ответ на вопрос "как мы управляем контейнерами в продакшне". Это зрелая платформа с большим сообществом и реальными успешными внедрениями у крупных компаний. При этом я регулярно вижу ситуации, когда команды внедряют Kubernetes не потому что решают конкретную проблему, а потому что "так правильно" или "все так делают".
Результат - инфраструктура, которую никто не понимает до конца, и которую стало сложнее, а не проще эксплуатировать.
Что Kubernetes реально решает
Kubernetes создан для конкретного класса задач. Он хорош, когда:
- В инфраструктуре работает много небольших сервисов, и нужно управлять их жизненным циклом: деплой, перезапуск при падении, масштабирование под нагрузку.
- Разные команды деплоят свои сервисы независимо, и нужна платформа, которая предоставляет единый способ это делать.
- Нагрузка нестабильна, и нужно автоматически выделять и освобождать ресурсы.
- Компания работает в нескольких облаках или датацентрах и нужна переносимость.
Если ни один из этих пунктов не описывает реальную ситуацию - Kubernetes, скорее всего, преждевременное усложнение.
Что Kubernetes добавляет помимо пользы
Управление кластером Kubernetes - это отдельная операционная задача. Вот что появляется вместе с ним:
- Сетевая модель, которая сложнее стандартной. Сервисы, неймспейсы, ingress, политики - это не настраивается за один день и требует понимания.
- Хранилище. Состояние в Kubernetes - это отдельный разговор. Базы данных в Kubernetes требуют аккуратного подхода.
- Мониторинг и логирование. Инструменты для наблюдения за кластером - это отдельный стек, который нужно освоить и поддерживать.
- Обновление кластера. Kubernetes активно развивается. Поддержание актуальной версии - это регулярная работа, которую нельзя игнорировать.
- Квалификация команды. Нельзя поставить Kubernetes и уйти. Нужны люди, которые понимают, как это работает, и умеют диагностировать проблемы.
Для компании с 5-10 сервисами и командой из 3-5 разработчиков это может быть избыточно. Для компании с 50+ сервисами и несколькими командами - это уже осмысленный выбор.
Три вопроса перед принятием решения
Первый: сколько у нас независимо деплоящихся сервисов сейчас - и сколько планируется через год? Если меньше десяти - Kubernetes, вероятно, преждевременен.
Второй: есть ли в команде человек или несколько людей, которые готовы стать операторами кластера - не разработчиками, а именно операторами инфраструктуры? Без этого Kubernetes превращается в чёрный ящик, который работает до первой серьёзной проблемы.
Третий: что мы сейчас используем для деплоя, и какую конкретную проблему с этим мы решаем переходом на Kubernetes? Если ответ "ну, у нас Docker Compose, и в целом работает, но хочется как у больших" - это не проблема, это желание. Лучше сначала убедиться, что проблема реальная.
Альтернативы, о которых стоит знать
Если Kubernetes преждевременен - есть промежуточные решения. Docker Compose достаточен для многих небольших команд в продакшне. Управляемые контейнерные сервисы у облачных провайдеров снимают часть операционной нагрузки. Простые платформенные сервисы вроде managed PaaS позволяют деплоить без погружения в оркестрацию.
Переход к Kubernetes имеет смысл - но он должен быть продиктован реальными задачами, а не готовностью технологии.