Nomad vs Kubernetes на VDS: что выбрать для оркестрации контейнеров

Nomad и Kubernetes обычно звучат в одном ряду, когда речь заходит об оркестрации контейнеров. Но за общей темой скрываются две довольно разные философии. Kubernetes стремится стать «операционной системой для дата-центра», а Nomad делает ставку на простоту, единый бинарь и минимализм.

В этой статье посмотрим на Nomad и Kubernetes через призму эксплуатации на VDS: когда имеет смысл разворачивать полный Kubernetes-кластер, а когда проще и дешевле обойтись Nomad (вплоть до single-node сценариев поверх Docker и systemd). Материал ориентирован на админов и DevOps, которые отвечают за прод.

Задача: оркестрация на VDS, а не в абстрактном облаке

В больших компаниях вопрос часто звучит как «что у нас по Kubernetes». Но если у вас несколько VDS, а не собственный дата-центр с сотнями нод, требования сильно отличаются:

• ограниченный бюджет на инфраструктуру и время админа;
• необходимость быстро поднимать окружения для pet-проектов, MVP, внутренних сервисов;
• часто один сервер (или несколько, но без отдельной команды SRE под кластер);
• желание получить преимущества оркестрации (деплой, рестарты, health-check’и, rolling-update), но без огромного зоопарка компонентов.

На таком фоне Kubernetes может оказаться избыточным. Он мощный, но требует немало операционной дисциплины: etcd, control-plane, CNI, CSI, ingress-контроллеры, RBAC, сертификаты, апгрейды. Даже в формате k3s/k0s это остаётся серьёзной системой.

Nomad же исторически создавался как компактный планировщик задач: один бинарь, минимальные зависимости, поддержка не только контейнеров, но и raw_exec, systemd и других типов workload’ов. И на VDS это даёт интересные сценарии.

Nomad vs Kubernetes: архитектурные отличия

Если сильно упростить, основное различие такое:

• Kubernetes — это целая платформа (control-plane, API, scheduler, etcd, контроллеры, admission, CRD), вокруг которой живёт огромная экосистема. Сильная сторона — декларативность и расширяемость.
• Nomad — это в первую очередь планировщик workload’ов с простым API и конфигами. Можно интегрировать Consul, Vault и сделать полноценный HashiStack, но база остаётся лёгкой.

Nomad проще развернуть и держать в порядке. Kubernetes требует больше предварительного дизайна кластера и регулярных процедур обслуживания.

Kubernetes из коробки даёт богатый функционал: сервисы, ингрессы, StatefulSet, CronJob, DaemonSet, автоскейлинг, network policies и многое другое. Но каждый плюс — это ещё один контроллер, состояние, ресурсы и ответственность.

Nomad в базовой поставке даёт:

• планировщик job’ов (long running, batch, system, periodic);
• разные драйверы исполнения (docker, exec, raw_exec, systemd и т. д.);
• сторонний сервис-дискавери (обычно Consul) при необходимости;
• интеграцию с Vault для секретов.

Если нужен «просто оркестратор» — запускать контейнеры/процессы и следить за их состоянием — Nomad часто ближе к задаче и проще в освоении.

Single-node сценарии: Nomad как умный systemd над Docker

Один из самых частых реальных сценариев: у вас есть один VDS (или несколько независимых), на нём Docker, несколько микросервисов, worker’ы, cron’ы. Всё крутится либо как systemd-сервисы, либо в Docker Compose. В какой-то момент хочется:

• иметь декларативные job-файлы под git;
• получить автоматический рестарт и health-check’и на уровне оркестратора;
• мигрировать сервисы между хостами без сильной завязки на конкретные имена серверов;
• но не поднимать для этого полный Kubernetes-кластер.

Здесь Nomad проявляет себя особенно хорошо. Single-node Nomad-кластер — это по сути демон и агент на одном хосте, управляющий Docker-контейнерами или systemd-процессами по job-описаниям.

Пример простой job’ы для Docker (упрощённо):

job "api" {
  datacenters = ["dc1"]
  type = "service"

  group "api" {
    count = 1

    task "api" {
      driver = "docker"

      config {
        image = "myorg/api:latest"
        ports = ["http"]
      }

      resources {
        cpu    = 500
        memory = 512
      }

      service {
        name = "api"
        port = "http"
        check {
          type     = "http"
          path     = "/health"
          interval = "10s"
          timeout  = "2s"
        }
      }
    }

    network {
      port "http" {
        to = 8080
      }
    }
  }
}

С таким подходом:

• job-описание лежит в git;
• деплой — это nomad job run или nomad job plan плюс nomad job run после утверждения;
• не нужно отдельно писать unit-файлы systemd для каждого сервиса;
• Nomad следит за перезапуском задач, ограничениями по CPU/RAM и health-check’ами.

Да, всё это умеет и Kubernetes, но его минимальный «вес» значительно выше, особенно на одном VDS.

Nomad и systemd: когда контейнеры не покрывают всё

В реальной инфраструктуре DevOps нередко приходится иметь дело не только с Docker-контейнерами, но и с:

• старым монолитом без контейнеризации;
• бинарями, которые должны работать в тесной связке с окружением хоста;
• агентами и системными сервисами, для которых контейнер — не лучший выбор.

Kubernetes официально про Docker и контейнеры (через контейнерные рантаймы), работа с bare metal процессами на ноде — это уже в зоне ответственности systemd / init.

Nomad, наоборот, изначально умеет работать с разными драйверами, включая raw_exec и systemd. Это даёт возможность описать в одном месте:

• web-приложение, работающее в Docker;
• background-воркер в том же образе;
• системный агент (например, бэкапы), запускаемый через systemd или exec.

В результате у вас единая точка обзора по workload’ам, даже если часть из них не контейнеризована.

Kubernetes: когда «монстр» действительно нужен

Несмотря на кажущуюся избыточность, Kubernetes остаётся де-факто стандартом для оркестрации в крупных и быстро растущих проектах. Есть сценарии, где Nomad будет уже компромиссом, а не облегчением:

• десятки и сотни сервисов, десятки нод, несколько VDS-пулов в разных регионах;
• сложные требования к сетевой политике, изоляции, multi-tenant окружениям;
• масштабная команда разработчиков, которая уже живёт в экосистеме Kubernetes;
• активное использование CRD, операторов, сервис-меша, сложных ingress’ов и т. д.

Если вы уже завязаны на инструменты, которые «умеют только в k8s» (Helm-чарты от вендоров, операторы БД, GitOps-платформы), уходить в Nomad может быть просто невыгодно.

Также Kubernetes выигрывает там, где необходимы:

• сложные схемы autoscaling’а (HPA/VPA);
• развитая модель RBAC и изоляции между командами;
• облачные интеграции: provisioner’ы для блок-стораджей, балансировщиков, managed-сервисов.

Для «жирных» VDS-кластеров (или bare metal), где устраивает дополнительная операционная сложность, Kubernetes — отличный выбор.

Nomad и оркестрация на нескольких VDS

Nomad не ограничивается single-node. Нормальный сценарий — несколько серверов: пара для control-plane (server-агенты) и несколько worker-нод (client-агенты). Архитектура здесь проще, чем у Kubernetes:

• Nomad server — хранит состояние кластера (использует встроенный Raft), планирует задачи;
• Nomad client — исполняет задачи на конкретном хосте и регулярно отчитывается серверу.

В простейшем варианте достаточно:

• развернуть Nomad server на 1–3 VDS (для отказоустойчивости — нечётное количество);
• поставить Nomad client на каждую рабочую VDS;
• настроить Docker или другой драйвер на клиентах;
• описать job’ы и развернуть их через API или CLI.

В отличие от Kubernetes, вам не нужно заботиться об отдельном etcd, CNI-плагинах, admission webhooks, контроллерах и прочем. Сетевой уровень можно строить классически: reverse-proxy (например, Nginx или HAProxy) на фронтовых машинах и обычные IP/порты на backend’ах. Если нужен сервис-дискавери, подключаете Consul.

Для сетевой части и безопасности контейнеров в связке с Nomad могут пригодиться подходы, о которых мы писали в материале про firewall для Docker и iptables/nftables.

DevOps-подход: как вписывается Nomad в CI/CD

С точки зрения DevOps-процесса Nomad похож на Kubernetes: вы описываете желаемое состояние и применяете его к кластеру. Отличия — в деталях и уровне сложности.

Типичный пайплайн с Nomad может выглядеть так:

1. CI собирает Docker-образ и пушит в реестр.
2. CI обновляет версию образа в HCL/job-файле (или подставляет тег через шаблонизатор).
3. CI выполняет nomad job plan для предварительного просмотра изменений.
4. После одобрения (manual job) выполняется nomad job run.

Плюсы для небольших команд:

• минимальный зоопарк YAML-манифестов, CRD, Helm-чартов;
• более простая модель: есть job, в ней группы и задачи;
• легче обучать новых админов и разработчиков.

При этом вы всё так же можете хранить декларативные описания в git, делать code review, катить релизы через GitOps-подобные процессы. Для многих команд, живущих на нескольких VDS, это даёт комфортный баланс между порядком и сложностью.

Нагрузка и ресурсы: Nomad легче дышит на маленьких VDS

Один из недооценённых аспектов — собственное потребление ресурсов оркестратором. На небольших VDS (1–2 vCPU, 2–4 ГБ RAM) Kubernetes control-plane и системные поды занимают заметную долю CPU и памяти. Особенно если всё это крутится на одной машине вместе с workload’ами.

Nomad, напротив, довольно лёгок. Один бинарь сервера и клиента потребляет ощутимо меньше ресурсов. Это важно, если вы:

• выжимаете максимум из недорогих VDS-планов;
• разворачиваете staging/QA окружения на отдельных небольших машинах;
• поднимаете отдельные single-node стенды под pet-проекты.

Чем проще и легче сам оркестратор, тем больше ресурсов остаётся приложению и тем проще масштабировать горизонтально: ещё один VDS, ещё один Nomad client — и всё.

Для single-node сценариев с высокой нагрузкой имеет смысл посмотреть и на подходы из статьи про высоконагруженный single-node стек мониторинга на VDS — там похожая логика экономии ресурсов оркестратора и вспомогательных сервисов.

Сетевые и сервисные паттерны: без магии, но предсказуемо

Nomad не навязывает сложную сетевую модель. По умолчанию вы работаете со стандартными IP-адресами и портами хостов. Для многих DevOps это плюс:

• легче отлаживать сетевые проблемы обычными инструментами (netstat, ss, tcpdump);
• простые схемы публикации портов, без оверхеда CNI;
• контроль на уровне привычных firewall-инструментов.

Сервис-дискавери и health-check’и часто реализуют через связку Nomad + Consul. Nomad регистрирует сервисы в Consul, а дальше уже поверх этого строится балансировка, трекинг состояний и роутинг. В сравнении с Kubernetes, где есть свои Service/Endpoints, здесь меньше магии, но чуть больше ручной сборки.

Где Nomad слабее Kubernetes

Nomad не является drop-in заменой Kubernetes. Есть области, где он объективно уступает:

• экосистема и количество готовых решений: чарты, операторы, Helm-репозитории, готовые манифесты от вендоров;
• богатство стандартных ресурсов: нет прямого аналога StatefulSet или DaemonSet в том же виде, меньше «кухонных приборов» из коробки;
• облачная интеграция: мир балансировщиков, managed volumes и всего, что в больших облаках делается через контроллеры Kubernetes;
• обучающие материалы и best practices: по Kubernetes написано гораздо больше гайдов, курсов и книг.

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

Роадмап и зрелость: насколько безопасно выбирать Nomad вместо Kubernetes

Nomad уже давно не экспериментальный проект, но его массовая популярность ниже. Это накладывает некоторые ограничения:

• меньше сторонних тулов и интеграций «из коробки»;
• сообщество скромнее, сложные вопросы чаще решаются через документацию и issue-трекеры;
• меньше людей на рынке, у которых прямо сейчас есть глубокий опыт прод-эксплуатации Nomad.

С другой стороны, сам продукт зрелый, активно развивается, используется крупными компаниями. В целом, для инфраструктуры на нескольких VDS риски сравнимы, а выигрыш в простоте может быть существенным.

Nomad или Kubernetes: практические критерии выбора для VDS

Сведём всё к нескольким практическим вопросам. Если вы отвечаете «да» большинству пунктов слева — Nomad выглядит логичнее, если справа — Kubernetes.

Nomad ближе, если:

• инфраструктура в основном на VDS, масштаб от одного до нескольких десятков серверов;
• хотите оркестрацию без полного vendor lock-in на k8s-экосистему;
• важна простота установки и обслуживания (single binary, минимум внешних зависимостей);
• есть микс контейнеров и не контейнеризованных процессов, удобно управлять всем единообразно;
• команда небольшая, нет выделенного SRE-отдела под Kubernetes;
• вы цените прозрачность и предсказуемость больше, чем магию и огромный набор фич.

Kubernetes логичнее, если:

• уже строите архитектуру вокруг k8s (операторы, CRD, сервис-меш, GitOps-платформы);
• у вас много нод, сложные требования к мультитенантности и сетевой политике;
• активно используете фичи облачного провайдера через контроллеры Kubernetes;
• команда разработчиков ожидает именно Kubernetes (инструменты, пайплайны, манифесты и т. д.).

Рекомендация для типичного DevOps с парком VDS

Если обобщить опыт небольших и средних команд, типичная эволюция выглядит так:

1. Docker / Docker Compose + systemd на одном-двух VDS.
2. Понимание, что ручной менеджмент контейнеров и сервисов не масштабируется, нужна оркестрация.
3. Попытка зайти в Kubernetes и осознание, что накладные расходы по времени и сложности слишком велики.
4. Поиск более лёгкого оркестратора — и здесь Nomad часто оказывается очень удачным компромиссом.

Nomad хорошо закрывает потребности инфраструктуры до того момента, когда Kubernetes действительно начинает «окупаться» своим богатством возможностей. А для многих проектов на VDS этот момент, по-честному, может и не наступить: сервисы растут, но не до масштаба собственного k8s-зоопарка.

Если вы сейчас как раз решаете, чем заменить зоопарк из systemd и Docker Compose, и не планируете в ближайшие годы строить многорегиональный кластер с сотнями нод, стоит серьёзно рассмотреть Nomad как основной инструмент оркестрации. А начать можно с небольшого single-node стенда на VDS, описав текущие сервисы в виде job-файлов и постепенно наращивая требования.

В следующих материалах имеет смысл разобрать конкретные практические шаги: базовый деплой Nomad на VDS, настройку single-node кластера для pet-проекта и миграцию с Docker Compose на job-файлы Nomad.