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

Почему стандартные оркестраторы не всегда подходят

Kubernetes и Nomad — зрелые инструменты, но они проектировались под общие сценарии. Если ваша платформа должна управлять одновременно функциями (короткоживущими процессами) и контейнерными приложениями (долгоживущими), приходится идти на компромиссы. Например, в Kubernetes для функций обычно используют отдельные решения (Knative, OpenFaaS), что усложняет единую модель ресурсов и тарификацию. Собственный оркестратор позволяет с самого начала заложить общую абстракцию — allocation plane, которая связывает жизненный цикл сервиса с выделением ресурсов и биллингом.

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

Критерии выбора: когда писать свой оркестратор

Прежде чем отказываться от проверенных решений, оцените следующие факторы:

  • Уникальная ресурсная модель. Если вам нужно единое управление функциями и контейнерами с общей тарификацией, стандартные оркестраторы потребуют множества костылей.
  • Контроль над планировщиком. Когда алгоритмы размещения задач тесно связаны с бизнес-правилами (например, учёт стоимости ресурсов в реальном времени), собственный планировщик даёт гибкость.
  • Размер команды и экспертиза. Собственный оркестратор — это долгосрочная инвестиция. Если у вас нет инженеров, готовых глубоко разбираться в containerd, сетях и хранении, лучше не начинать.
  • Требования к производительности. Иногда стандартные решения добавляют задержки или накладные расходы, которые критичны для serverless-сценариев.

Если хотя бы два пункта из списка для вас критичны, возможно, стоит рассмотреть гибридный подход: использовать готовые компоненты (например, containerd для запуска контейнеров) и написать только недостающий слой оркестрации.

Пример Inquir Compute: что дал собственный оркестратор

В проекте Inquir Compute переход от FaaS к PaaS потребовал объединения функций и контейнеров в одной ресурсной модели. Собственный оркестратор с allocation plane и планировщиком позволил:

  • Упростить тарификацию: ресурсы выделяются и учитываются в момент выполнения задачи, будь то функция или контейнер.
  • Снизить задержки за счёт оптимизации планировщика под короткие задачи.
  • Использовать containerd как надёжный рантайм, не привязываясь к Kubernetes API.

Однако разработка заняла много времени и потребовала решения нетривиальных задач: отказоустойчивость, масштабирование, сбор логов и метрик. Без сильной команды такой проект легко может застрять на стадии прототипа.

Типичные ошибки и как их избежать

Даже при наличии ресурсов легко допустить ошибки, которые сведут на нет все преимущества. Вот наиболее распространённые:

  • Недооценка сложности. Собственный оркестратор — это не только планировщик, но и сеть, хранилище, безопасность, обновления. Начинайте с минимального жизнеспособного продукта, используя готовые компоненты.
  • Отсутствие чётких критериев успеха. Определите заранее, какие метрики (задержка, стоимость, удобство для пользователей) должны улучшиться по сравнению с готовым решением.
  • Игнорирование сообщества. Вокруг Kubernetes и Nomad есть экосистема плагинов и инструментов. Собственный оркестратор потребует создавать всё с нуля, если не интегрироваться с существующими стандартами (например, CRI).
  • Попытка заменить всё сразу. Не обязательно отказываться от Kubernetes полностью — можно использовать его для одних задач, а собственный оркестратор для других, если это оправдано.

Например, в Inquir Compute разработчики сознательно оставили containerd в качестве рантайма, чтобы не изобретать велосипед. Это позволило сосредоточиться на уникальной логике планирования и биллинга.

Практические шаги для принятия решения

Если вы задумываетесь о собственном оркестраторе, начните с анализа текущих проблем. Задайте себе вопросы: какие задачи не решаются стандартными инструментами? Сколько времени и денег потребуется на разработку и поддержку? Есть ли у команды опыт в системном программировании и распределённых системах? Проведите пилотный проект на ограниченном наборе сервисов, чтобы оценить трудозатраты. И помните: главное — не технология ради технологии, а решение конкретных бизнес-задач.