Что придётся собрать руками, если выбрать Nomad, а не Kubernetes

MAATRIX

HashiCorp Nomad почти всегда всплывает в разговоре как «Kubernetes, только без боли»: один бинарник, HCL вместо трёхэтажного YAML, control plane не требует отдельного etcd-кластера. Всё так — но за упрощённой установкой стоит не менее упрощённая экосистема, и часть того, что в Kubernetes работает из коробки, в Nomad придётся либо собрать руками из отдельных инструментов, либо просто не иметь. Разберём по пунктам, что именно вы теряете и чем это компенсировать.

Разная природа: планировщик против платформы

Kubernetes — это не только оркестратор контейнеров, а платформа с встроенными подсистемами: kube-apiserver — единая точка входа и хранилище состояния поверх etcd, kube-scheduler раскладывает поды по узлам, kube-controller-manager следит, что желаемое состояние совпадает с реальным, kube-proxy и CNI-плагин поднимают сеть между подами, kubelet на каждом узле общается с control plane. Это минимум шесть разных компонентов, даже в лёгких дистрибутивах вроде k3s они просто упакованы в один бинарник, а не исчезли.

Nomad устроен иначе — это в первую очередь планировщик задач, причём не только контейнеров: тем же job-файлом можно запустить raw_exec-процесс, Java-приложение через exec, виртуалку через qemu. Server-процессы Nomad сами хранят состояние через встроенный Raft (внешний etcd не нужен), но всё, что в Kubernetes считается частью платформы — service discovery, sidecar-инъекция, секреты, autoscaling — вынесено в отдельные продукты HashiCorp (Consul, Vault, Nomad Autoscaler) или не поставляется вовсе. Это осознанное архитектурное решение — модульность вместо монолита — и оно же источник почти всех пунктов ниже.

Установка и ресурсы: где Nomad реально легче

Здесь Nomad выигрывает без оговорок. Развернуть dev-сервер — одна команда:

wget -O nomad.zip https://releases.hashicorp.com/nomad/1.8.4/nomad_1.8.4_linux_amd64.zip
unzip nomad.zip && sudo mv nomad /usr/local/bin/
nomad agent -dev -bind=0.0.0.0 -log-level=INFO

(версию сверьте на releases.hashicorp.com — конкретный номер меняется чаще, чем эта статья). В продакшене та же команда nomad в режиме -server и -client — это два независимых процесса, но оба запускаются одним бинарником, без отдельной установки control plane и без CNI-плагина, если вам не нужна сеть между контейнерами сложнее host/bridge:

nomad server members
nomad node status

У Kubernetes даже в лёгких сборках такого нет: kubeadm поднимает связку из API-сервера, etcd, планировщика и controller-manager, и, хотя k3s упаковывает всё в один бинарник ~70 МБ, внутри всё равно работают отдельные процессы с собственным потреблением памяти. Точные цифры по вашей нагрузке лучше снять на своём стенде, а не верить чужим бенчмаркам — ориентир такой:

systemctl show nomad -p MemoryCurrent
systemctl show k3s -p MemoryCurrent

Разница будет заметной на пустом кластере — Nomad ощутимо экономнее по памяти на управляющей ноде, что критично, если под control plane выделен минимальный VPS. Но экономия на входе — это ровно то, что вы отдаёте на следующих пунктах.

Service mesh: Consul Connect вместо готового манифеста

В экосистеме Kubernetes service mesh — это helm install istio или linkerd install, после чего sidecar-инъекция включается аннотацией на namespace, а mTLS между сервисами настраивается через CRD того же mesh-провайдера. Инструмент отдельный, но интеграция стандартизирована: admission webhook сам добавляет sidecar в под, никакого ручного связывания с планировщиком не требуется.

В Nomad эквивалента нет — есть Consul Connect, но чтобы им воспользоваться, вам нужен отдельный, самостоятельно управляемый Consul-кластер: свой Raft, свои сертификаты, свой апгрейд-цикл, отдельный от Nomad мониторинг здоровья. Только после этого в job-файле можно объявить sidecar:

group "web" {
  network {
    mode = "bridge"
  }
  service {
    name = "web"
    port = "8080"
    connect {
      sidecar_service {
        proxy {
          upstreams {
            destination_name = "api"
            local_bind_port  = 9090
          }
        }
      }
    }
  }
}

Это рабочий вариант, но каждый upstream прописывается руками в каждом job-файле — никакого центрального CRD, который применяется ко всему namespace разом. Плюс сам Nomad должен быть сконфигурирован на работу с Consul (consul { address = "127.0.0.1:8500" } в конфиге агента), то есть вы администрируете два кластера вместо одного. Если service mesh вам не нужен — например, у вас три-пять сервисов и трафик внутри одного bridge-network — это не потеря, а лишняя сложность, от которой Nomad вас как раз избавляет. Но если mesh нужен по-настоящему (mTLS между командами, детальные политики трафика), закладывайте отдельный проект на Consul, а не полчаса на аннотацию.

Секреты: Vault нужен в обоих мирах, но в Nomad вы его администрируете сами

Тут разница тоньше, чем кажется. В Kubernetes есть встроенный объект Secret, но по умолчанию это просто base64 (не шифрование) в etcd, и для реальной безопасности всё равно нужно либо включать шифрование etcd at rest, либо ставить внешний секрет-менеджер — то есть «из коробки» здесь скорее иллюзия, чем факт.

Nomad в этом смысле честнее: у него есть лёгкие Nomad Variables для несекретных или не самых чувствительных значений, но для нормального управления секретами всё равно нужен Vault — и, начиная с относительно новых версий Nomad, интеграция через workload identity (JWT-аутентификация задачи в Vault) сделана даже удобнее, чем в среднем Kubernetes-кластере без отдельных операторов:

vault {
  policies = ["myapp-read"]
}

template {
  data = <<EOT
{{ with secret "secret/data/myapp/db" }}
DB_PASSWORD={{ .Data.data.password }}
{{ end }}
EOT
  destination = "secrets/db.env"
  env         = true
}

Разница не в качестве интеграции — она хорошая с обеих сторон, — а в том, что Vault-кластер вы поднимаете, разблокируете после рестарта и обновляете сами, отдельно от Nomad. В Kubernetes-мире то же самое верно для внешних секрет-менеджеров, но там чаще можно ограничиться встроенными Secret + RBAC для не самых критичных данных. Если решите ставить Vault — у нас есть отдельный разбор установки и эксплуатации HashiCorp Vault на VPS, включая unseal и базовые политики.

Автоскейлинг: Nomad Autoscaler — ещё один процесс, который нужно поднять и настроить

В Kubernetes горизонтальный автоскейлинг — это kubectl autoscale или манифест HPA, который работает сразу после установки metrics-server (а в managed-кластерах он обычно уже есть):

kubectl autoscale deployment myapp --cpu-percent=50 --min=2 --max=10

Вертикальный автоскейлинг (VPA) и autoscaling самих узлов (Cluster Autoscaler) — отдельные компоненты, но у большинства облачных Kubernetes они включаются флагом в консоли провайдера.

В Nomad автоскейлинга нет вообще, пока вы не поставите отдельный демон Nomad Autoscaler — это не часть основного бинарника:

nomad-autoscaler agent -config=autoscaler.hcl -policy-dir=policies/

Ему дополнительно нужен APM-плагин для метрик (в подавляющем большинстве конфигураций — Prometheus, который тоже разворачиваете и поддерживаете сами) и strategy-плагин, решающий, на сколько скейлить. Политика описывается отдельным HCL-файлом:

scaling "web-scaling" {
  min     = 1
  max     = 10
  policy {
    cooldown            = "1m"
    evaluation_interval  = "30s"
    check "cpu_usage" {
      source = "prometheus"
      query  = "avg(nomad_client_allocs_cpu_total_percent)"
      strategy "target-value" {
        target = 50
      }
    }
  }
}

Рабочий механизм, но три отдельных куска инфраструктуры — Prometheus, Nomad Autoscaler, сама политика — которые в managed Kubernetes чаще всего идут уже предустановленными или ставятся одним чартом. Автоскейлинг узлов (не только задач) в Nomad тем более не встроен — под облако-специфичное масштабирование нод пишется собственная интеграция или берётся terraform-скрипт, готового решения на все случаи нет.

Экосистема: Helm-чарты против job-файлов, написанных вами

Это, вероятно, самая недооценённая разница на старте и самая заметная через полгода эксплуатации. В Kubernetes у вас есть Artifact Hub и тысячи готовых Helm-чартов: PostgreSQL с репликацией, Redis-кластер, полный стек мониторинга — всё разворачивается одной командой и параметризуется values-файлом:

helm repo add bitnami https://charts.bitnami.com/bitnami
helm install my-postgres bitnami/postgresql -f values.yaml

Для сложных систем есть операторы — Postgres Operator, Zalando, Strimzi для Kafka — которые берут на себя failover, ресайзинг, бэкапы как декларативную логику поверх Kubernetes API.

У Nomad централизованного каталога такого масштаба нет. HashiCorp пробовала аналог Helm — nomad-pack, — но проект сейчас практически не развивается, и рассчитывать на него как на полноценную замену не стоит. На практике это означает, что job-файлы для стандартных сервисов вы пишете сами (или адаптируете чужие с GitHub без гарантии поддержки), а логику отказоустойчивости баз данных — репликацию, автопереключение мастера — берёте либо из встроенных механизмов самой СУБД, либо реализуете отдельным скриптом, который в Kubernetes был бы частью оператора. Для типового стека из 5-15 сервисов это на старте медленнее, чем helm install, но и работает точно так, как вы это описали, без магии оператора внутри.

Когда ручная сборка Nomad всё равно окупается

Несмотря на всё перечисленное, Nomad — не «Kubernetes подешевле» для тех, кто не осилил кубер, а осознанный выбор в конкретных ситуациях. Он оправдан, если у вас смешанная нагрузка — часть в контейнерах, часть batch-джобами или legacy-процессами без Docker, — потому что один и тот же планировщик управляет и тем, и другим через разные драйверы (docker, exec, raw_exec, qemu). Он оправдан, если команда небольшая, а требование к service mesh и автоскейлингу по факту не выше «перезапустить упавший контейнер и разложить реплики по нодам» — тогда Consul и Nomad Autoscaler можно вообще не ставить, а разница в требованиях к control plane между Nomad и полноценным Kubernetes ощутима на 1-2 vCPU управляющей ноде. И он оправдан, если вы уже используете Consul и Vault для чего-то другого в инфраструктуре — тогда «отдельный кластер для секретов» перестаёт быть минусом, потому что он у вас и так есть.

Если же вам нужны mesh, продвинутый автоскейлинг и десятки готовых чартов сразу, а команды на их ручную сборку и поддержку нет — честнее сразу смотреть в сторону k3s против Docker Swarm или прикинуть managed Kubernetes против своего кластера по деньгам — там часть перечисленных здесь проблем закрыта провайдером за отдельную плату, а не вашим временем.

Частые вопросы