Kubernetes — хороший инструмент, который слишком часто внедряют не потому, что он нужен, а потому, что он есть у всех. Результат предсказуем: небольшая команда получает систему, которую не умеет сопровождать, и тратит на её обслуживание больше, чем на развитие продукта. Эта статья о том, как понять, нужен ли оркестратор именно вам, и что делать, если пока нет.

Когда достаточно одного сервера и Docker Compose

Для многих проектов честный ответ — «пока не нужен». Признаки того, что вы в этой группе:

  • Приложение состоит из нескольких сервисов: веб, база, кэш, один-два воркера. Все они помещаются на один сервер с запасом.
  • Нагрузка предсказуема. Нет пиков в десятки раз, нет сезонности, которая требует быстро добавлять мощности.
  • Команда маленькая: один-три разработчика, нет выделенного инженера по инфраструктуре.
  • Простой в несколько минут при обновлении или перезапуске допустим, и бизнес это подтверждает.
  • Релизы выходят несколько раз в неделю или реже.

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

Важно: «один сервер» не означает «настроен руками». Описание окружения в репозитории, автоматическая выкладка через CI и возможность развернуть всё заново из кода нужны на любом масштабе. Без них переход на оркестратор позже будет мучительным, а с ними он будет вопросом нескольких недель.

Когда оркестратор действительно нужен

Kubernetes решает конкретные задачи, и если они у вас есть, он окупается.

  • Много сервисов и много серверов. Когда сервисов десятки, а серверов больше нескольких, ручное распределение и перезапуск перестают масштабироваться. Оркестратор размещает, перезапускает и переносит сервисы сам.
  • Неравномерная нагрузка. Если нужно автоматически добавлять экземпляры при росте трафика и убирать при спаде, оркестратор делает это по метрикам.
  • Обновления без простоя. Постепенная выкладка новой версии с автоматическим откатом при ошибках — встроенная возможность, которую на Compose приходится собирать вручную.
  • Несколько команд на одной платформе. Изоляция пространств имён, квоты ресурсов, единые правила доступа и выкладки для разных команд.
  • Требование к отказоустойчивости. Если выход из строя сервера должен быть незаметен для пользователей, нужен механизм, который переносит нагрузку автоматически.

Если из этого списка у вас одна задача, возможно, её проще решить точечно. Если три и больше — оркестратор, скорее всего, оправдан.

Скрытая стоимость

Стоимость Kubernetes — не серверы. Это компетенции и время.

Компетенции

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

Обновления

Kubernetes выпускает новые версии регулярно, старые перестают поддерживаться. Обновление кластера — это работа, которую нельзя пропускать годами: накопленный разрыв в версиях превращает обновление в миграцию. Управляемый кластер у облачного провайдера снимает часть этой работы, но не всю: приложения, ингресс-контроллер, системные компоненты обновлять всё равно вам.

Наблюдаемость

Логи и метрики в кластере не лежат на диске сервера, где их можно посмотреть. Нужна система сбора логов, сбор метрик с узлов и подов, алерты на состояние кластера, а не только приложения. Это отдельные компоненты, которые тоже нужно развернуть и сопровождать.

Сложность конфигурации

Манифесты, Helm-чарты, сетевые политики, ограничения ресурсов, секреты, права доступа. Для небольшого приложения объём конфигурации может превышать объём самого приложения. Это не плохо само по себе, но это код, который нужно писать, ревьюить и поддерживать.

Промежуточные варианты

Между «один сервер» и «кластер Kubernetes» есть несколько ступеней, и часто нужная вам именно там.

  • Два-три сервера с Compose и балансировщиком. Приложение в нескольких экземплярах, база с репликой, прокси распределяет трафик. Закрывает отказ одного сервера и позволяет обновляться по очереди.
  • Docker Swarm. Оркестратор, встроенный в Docker, с гораздо более простой моделью. Подходит, когда нужно распределение по нескольким узлам без сложностей полноценного кластера. Экосистема вокруг него меньше, и это нужно учитывать.
  • Управляемый Kubernetes у провайдера. Если оркестратор нужен, но управлять узлами не хочется. Провайдер отвечает за управляющий слой и обновления узлов, вы — за то, что внутри. Это снижает порог входа, но не отменяет необходимость компетенций.
  • Платформы поверх контейнеров. Сервисы, которые принимают контейнер и сами решают, где его запускать. Минимум управления, максимум ограничений. Хороши для простых веб-приложений, плохи для всего, что требует тонкой настройки.

Как принять решение

Ответьте письменно на несколько вопросов. Если на большинство ответ «нет», Kubernetes пока не нужен.

  1. У нас есть задача, которую невозможно или дорого решить без оркестратора? Назовите её конкретно.
  2. В команде есть человек, который сопровождал кластер в рабочей среде и разбирал инциденты? Или мы готовы такого человека нанять либо привлечь на сопровождение?
  3. Мы готовы тратить время на обновления кластера и компонентов регулярно, а не раз в три года?
  4. Наше приложение готово к оркестратору: не хранит состояние на локальном диске, конфигурируется через окружение, корректно завершает работу по сигналу, отдаёт проверки готовности?
  5. Мы посчитали стоимость не только серверов, но и времени команды на сопровождение в течение года?

Четвёртый вопрос часто упускают. Приложение, которое не готово к оркестратору, в кластере работает хуже, чем на одном сервере: его перезапускают в неудобный момент, оно теряет файлы, оно не сообщает о готовности. Подготовка приложения — отдельная работа, которую нужно сделать до переезда, и она полезна независимо от того, состоится ли переезд.

Если решение «да», начинайте с управляемого кластера и одного приложения, а не с переноса всего сразу. Если «пока нет», вложите усилия в описание инфраструктуры в коде, автоматическую выкладку и мониторинг: это то, что потребуется в любом случае, и то, что делает будущий переход безболезненным. На странице настройки Kubernetes и CI/CD мы описываем, с чего начинаем в обоих случаях.

Что дальше

Если сомневаетесь, какой вариант подходит вашему проекту, покажите нам текущую инфраструктуру: в рамках бесплатного экспресс-аудита за 48 часов мы скажем, где достаточно одного сервера, а где оркестратор действительно оправдан.