LINUX.ORG.RU

HashiCorp Nomad 1.0

 , , ,


1

2

Состоялся выпуск первой стабильной версии минималистичной (относительно Kubernetes и других проектов в этой сфере) системы оркестрации HashiCorp Nomad, поддерживающей оркестрацию контейнеров с помощью Docker и Podman, программ на Java, виртуальных машин QEMU, обычных бинарных файлов, и ряда других способов, поддерживаемых сообществом. Проект написан на языке Go и примечателен тесной интеграцией с другими проектами HashiCorp.

По заявлению самой HashiCorp, по сравнению с Kubernetes их проект является архитектурно более простым, модульным и производительным: если Kubernetes сочетает в себе одновременно планировщик, управление кластерами, обнаружение и мониторинг сервисов, и хранение секретов, представляя собой массивный и ресурсоёмкий сервис, то Nomad поставляется в виде небольшого бинарного файла и занимается только планированием и кластеризацией. Вся остальная функциональность отдана на откуп другим небольшим сервисам компании: например, Consul для обнаружения сервисов и Vault для хранения секретов.

Изменения в этой версии:

  • Dynamic Application Sizing (доступно только в enterprise-версии) — автоматическое определение требуемого количества ресурсов для оптимальной работы сервиса;
  • Consul Namespaces (доступно только в enterprise-версии Consul) — выделение зоны видимости сервисов для Consul внутри одного Nomad-кластера;
  • Namespaces (стало доступно в свободной версии) — выделение зоны видимости и разграничение сервисов между собой внутри кластера;
  • Event Stream — полезный для отладки линейный поток событий, произошедших внутри кластера;
  • HCL2 — новая версия языка конфигурации проектов HashiCorp, теперь с поддержкой выражений и входных переменных;
  • улучшение поддержки Container Networking Interface — теперь адреса, созданные с помощью CNI, могут быть зарегистрированы в Consul;
  • новый интерфейс для отображения информации о запущенных сервисах, их распределению по узлам и потреблению ресурсов внутри кластера.

>>> Подробности

★★★★★

Проверено: Shaman007 ()

По заявлению самой HashiCorp, сравнивая Nomad с Kubernetes, их проект является архитектурно более простым, модульным и производительным

По факту же он не более прост, он просто реализует 5% возможностей kubernetes перекладывая отвественность за создание остальных 95% процентов на пользователя платформы.

После того как пользователь тратит полгода изобретая собственные механизмы и абстракции поверх nomad, он наконец понимает зачем нужен kubernetes и мигрирует туда.

Так что полезный проект в целом.

alpha ★★★★★ ()
Ответ на: комментарий от alpha

По факту же он не более прост, он просто реализует 5% возможностей kubernetes перекладывая отвественность за создание остальных 95% процентов на пользователя платформы.

У вэйланда же прокатило внедрить в массы такое понимание простоты. Может и у Номада выйдет.

P.S. Не понимаю что сложного люди находят в K8S. Он же простой как три копейки и построен на весьма базовых абстракциях.

ugoday ★★★★★ ()
Ответ на: комментарий от snizovtsev

Разные инструменты же. systemd является системным менеджером, а не оркестратором.

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

commagray ★★★★★ ()
Последнее исправление: commagray (всего исправлений: 1)
Ответ на: комментарий от commagray

systemd является системным менеджером, а не оркестратором.

Это у Лёни руки просто ещё не дошли...

А если серьезно, то по примерам похоже на инструмент для собирания кластера на коленке из чего попало. Что для моих задач интересно, особенно учитывая что тулзы у них получаются удобные (имел дело с terraform и vagrant). Но смущает, что они написали совсем уж кривой драйвер qemu (я посмотрел код). Почему не проинтегрировать со своим же vagrant-ом? Последний хоть в libvirt умеет через плагин.

snizovtsev ★★★★ ()
Последнее исправление: snizovtsev (всего исправлений: 1)

Чем это лучше docker swarm? Я понимаю - один бинарный файл Nomad это отлично, но Swarm даже меньше этого, он сразу встроен в докер, который и так должен быть установлен

vertexua ★★★★☆ ()
Ответ на: комментарий от vertexua

Он умеет не только докер-контейнеры запускать, но и просто например процессы на сервере, и вроде вмки тоже.

Это такой достаточно тупой оркестратор процессов любого типа.

alpha ★★★★★ ()
Последнее исправление: alpha (всего исправлений: 1)

Это какая-то сука дичь. Эмуляторы в эмуляторах, слой на слое. Конца этому не видно.

anonymous ()
Ответ на: комментарий от GP

Враги клевещут, что во многих случаях k8s используют там, где хватило бы docker-start-my-app.sh. Так что с технической точки зрения номад полезный, своя ниша у него есть. Но у кубера, есть гугль и хайп и за счёт этого он размажет всех.

ugoday ★★★★★ ()
Ответ на: комментарий от anonymous

А попробуйте сделать замер производительности этого „эмуляторы в эмуляторах, слой на слое“ и от вашего возмущения не останется и следа.

ugoday ★★★★★ ()

планирированием

:(

После того как пользователь тратит полгода изобретая собственные механизмы и абстракции поверх nomad, он наконец понимает зачем нужен kubernetes и мигрирует туда.

Если кластер не будет расти вообще никогда то вполне сойдет, особенно если уже подсел на Consul/Vault и не воротит от HCL

vrutkovs ★★ ()

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

K3s тоже поставляется в виде небольшого бинарного файла, который включает в себя всю функциональность кубернетеса. В чём выгода сабжа? В том, что ничего не умеет?

anonymous ()
Ответ на: комментарий от vrutkovs

Да в целом оно так конечно.

У меня просто с этим номадом связана психологическая травма:

я делала микросервисный проект, состряпала прототип на базе k8s, пришла просить кластер, кучу времени потратила на уговоры за k8s, но мне таки всё равно выдали nomad, потому что «админам так проще».

Я решила ну ладно, будем работать с тем что есть.

Выучила все доки, написала на ansible то чего не хватало (а там чтобы debug-порт к контейнеру открыть надо немало так постараться) запустила проект в прод… и ушла. И через неделю после того как уволилась узнала что они приняли решение мигрировать мой проект на гуглооблако разумеется в k8s.

alpha ★★★★★ ()
Ответ на: комментарий от anonymous

В том, что ничего не умеет?

Именно. Например у него своего пространства адресов и днс-имен нет.

В k8s ты развернул приложение и ходишь к нему на http://my-app:80 У каждого приложения свой ip-адрес и своё имя. И если у приложения пять портов, то это будут пять стандартных портов на этом ip. Если это будет несколько копий, то будет http://my-app-1:80 и http://my-app-2:80

А в nomad ты запустил процесс, замапил порты и ходишь на ноду по http://35.48.123.20:45691 за http и по https://35.48.123.20:37124 на https

Хочешь что-то более осмысленное? - Пили сам.

alpha ★★★★★ ()
Последнее исправление: alpha (всего исправлений: 1)
Ответ на: комментарий от alpha

Мне кажется, это глубоко религизоный вопрос о грешностиушербности любого решения.

На прошлой работе все страдали с номадом, думая о переходе на k8s.

На текущей страдают с lxc, думая о переходе на k8s.

Думаю, когда (если) перейдут, будут страдать, мечтая о переходе куда угодно от k8s.

derlafff ★★★★★ ()
Ответ на: комментарий от alpha

А в nomad ты запустил процесс, замапил порты и ходишь на ноду по http://35.48.123.20:45691 за http и по https://35.48.123.20:37124 на https

Это прямо вообще ни на что по сути не влияет, потому что service discovery все равно полностью автоматический.

derlafff ★★★★★ ()
Ответ на: комментарий от derlafff

Это влияет на понимание что сравнивать надо не k8s vs nomad, а k8s против связки из как минимум 6 различных сервисов. Nomad там будет только малой частью, а днс, роутеры, механизмы выкатки, инструменты для логирования, дебага и мониторинга - это всё ты будешь добавлять сам.

Так что кластер из номада - это как каша из топора.

alpha ★★★★★ ()
Ответ на: комментарий от alpha

а k8s против связки из как минимум 6 различных сервисов

k8s это тоже по сути много сервисов. Я думаю, преимущество (и одновременно недостаток) в том, что в nomad они менее тесно интегрированны и, следовательно, их легче заменять на другие при надобности.

derlafff ★★★★★ ()
Ответ на: комментарий от derlafff

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

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

anonymous ()
Ответ на: комментарий от alpha

По факту же он не более прост, он просто реализует 5% возможностей kubernetes перекладывая отвественность за создание остальных 95% процентов на пользователя платформы.

Покажи пожалуйста в k8s возможность пускать бинарники в чруте или jar-ники, или jail на freebsd. Nomad не только про контейнеры. Еще у него все лучше с сетью, т.к. он вполне себе нормально работает на хостовой сети и умеет менеджить порты, в отличии от куба. Так же есть нормальное управление шаблонами в отличии от костылей, типа, configmaps в кубе. + куб не умеет следить за обновлением configmap, и если у тебя в деплойменете поменялся только конфиг - куб ничего не перезапустит. Представим ситуацию - есть у тебя приложение, которое настраивается через конфиг и у него в зависимостях есть другой сервис. Сервис переехал на другую ноду, чтобы обновить конфиг приложения, нужно в контейнер пихать что-то типа confd - костыли костылики. Nomad нужно рассматривать сразу, как весь стек hashicorp - consul, nomad, vault. Ну ка покажи нормальную интерграцию с Vault внутри куба. Например для сервиса, которому нужно ходить в базенку. В Nomad это делается так:

template {
  data =<<EOF

{{ with secret "database/creds/app" }}
DB_USER="{{ .Data.username }}"
DB_PASSWD="{{ .Data.password }}"
{{ end }}

EOF

  destination   = "secrets/.db_creds"
  env           = true
}

vault {
  policies = ["app_policy"]
}

И номад будет сам следить за актуальностью секрета. Когда истечет срок действия(обычно 72 часа) аккаунта - приложение будет само переконфигурированно.

Живете, блин, в мире, где только чужие облака, чужой куб и только контейнеры.

Облака иогда строят, а не только ими пользуются. Кстати, Nomad умеет в quemu-kvm, умеет ли в него k8s? Вопрос риторический.

Работаю со всеми тремя основными оркестраторами - с Mesos, Kubernetes и Nomad.

Difrex ★★★★ ()

8 числа был релиз. Очень круто, очень рад.

На личном кластере переехал еще на первую бету.

Difrex ★★★★ ()
Ответ на: комментарий от ugoday

Были какие-то адовые баги с утечкой памяти и свопом. Вроде оказалось ядерным багом, но все равно было весело. Ну и кривые UI: один неофициальный умер, официальный не успел родиться. По делу ничего конкретного сказать не могу: стандартные превознемогания, борьба с нежеланием читать документацию, напарывание на интересные особенности.

derlafff ★★★★★ ()
Последнее исправление: derlafff (всего исправлений: 2)
Ответ на: комментарий от anonymous

что гораздо удобнее для всех.

Классическое одноцветное ЛОР-зрение.

derlafff ★★★★★ ()
Ответ на: комментарий от Difrex

уб не умеет следить за обновлением configmap, и если у тебя в деплойменете поменялся только конфиг - куб ничего не перезапустит.

Для этого есть операторы. И для вашего примера с секретом они тоже помогут.

ugoday ★★★★★ ()
Ответ на: комментарий от Difrex

А, ну и да, когда в куб федерацию завезут? Когда я смогу в кубе, как в Nomad, управлять весами, чтобы 33% пода запустилось в dc1, 33% в dc2 и 33% в dc3? А blue/green деплой из коробки в кубе когда будет, а канареечный? Куб не для всего хорош и многое не умеет. Но популярен, че уж там. А еще etcd до сих пор любит развалиться, или затупить так, что API мастера отваливается по тайм-ауту.

Difrex ★★★★ ()
Ответ на: комментарий от ugoday

О, вспомнил из странного неисправленного: очень часто процесс номада начинал жрать 100% cpu до перезапуска. С чем это было связано, так и не поняли. Насколько помню, (к счастью?) случалось только на тестовых серверах.

derlafff ★★★★★ ()
Последнее исправление: derlafff (всего исправлений: 1)
Ответ на: комментарий от ugoday

Т.е. нужно писать свое сбоку. Я знаю про операторы, но это же не из коробки. А как blue/green деплой вызвать после изменения конфига? Я к тому, что не нужно говорить, что куб прям конфетка и все умеет. Даже с точки зрения кода в Hashicorp все намного лучше - ради интереса попробуй почитать код Nomad и K8S и сравнить читаемость и понятность.

Difrex ★★★★ ()
Ответ на: комментарий от ugoday

Во, поехали всякие нашлепки :). Может и федерацию скажешь, как нормально сделать?

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

Difrex ★★★★ ()
Ответ на: комментарий от Difrex

Во, поехали всякие нашлепки

А что, было бы лучше, если бы ISTIO было встроено в k8s?

выбирать исходя из задачи

Я в целом согласен, но рассматриваю проблему и в социальном измерении. Нанять специалиста с опытом в более популярной технологии проще и быстрее, мне нужно меньше тратить времени и сил на погружение его в проект и он скорее сам начнёт мне помогать. Так что если у популярной технологии К. нет фатального недостатка, то и к чему лезть во всякую маргинальщину?

Конечно в личных проектах для души можно использовать всё, что угодно.

ugoday ★★★★★ ()
Ответ на: комментарий от ugoday

Так что если у популярной технологии К. нет фатального недостатка, то и к чему лезть во всякую маргинальщину?

Куб не умеет работать на хостовой сети - калики и прочие дают оверхед. Ну, и я бы не называл Nomad и Mesos маргинальщиной, просто гугл очень распиарил куб. Работал с Mesos еще в 2016 году - тогда кубом вообще нельзя было нормально пользоваться.

Про дешивизну людей - поддерживать куб сложнее.

Difrex ★★★★ ()
Последнее исправление: Difrex (всего исправлений: 1)
Ответ на: комментарий от Difrex

простите, но что такого вы держите в кубе, что вам важен оверхед на хостовую сеть? И если у вас такой лютый хайлоад, то почему вы не используете CNI-плагины, которые будут за вас делать те же VXLAN-туннели на сетевом оборудовании, например?

т.е. да, есть нюансы, но они либо а) не очень важны, либо б) решаются, когда становятся важны.

gr_buza ★★★★ ()
Ответ на: комментарий от Difrex

калики и прочие дают оверхед.

В интернете каждый гоняет хайлоады, занимается высокачастотным трэйдингом на бигдате или как-минимум админит какую-нибудь нью-йоркскую биржу. Так что рост сетевой отзывчивости на пол процента — серьёзная проблема. А в реале …

Оверхед от калики минимален и в 99% случаев точно не является бутылочным горлышком. А для 1% пускай будет специальные решения. Я не возражаю.

поддерживать куб сложнее.

Почему вы так думаете?

ugoday ★★★★★ ()
Ответ на: комментарий от gr_buza

простите, но что такого вы держите в кубе, что вам важен оверхед на хостовую сеть?

Не в кубе, в номаде же. У нас облако Elasticsearch, свое.

И если у вас такой лютый хайлоад, то почему вы не используете CNI-плагины, которые будут за вас делать те же VXLAN-туннели на сетевом оборудовании, например?

Это сложнее номада. Т.е. имеет смысл если реально загореться идеей строить облако на кубе. Но зачем?

Куб у нас тоже есть, как и мезос.

Difrex ★★★★ ()
Последнее исправление: Difrex (всего исправлений: 1)
Ответ на: комментарий от ugoday

поддерживать куб сложнее.

Почему вы так думаете?

Потому что у меня тут есть и куб тоже. Под сложнее я имею в виду, что возникает больше инцидентов связанных с инфрой куба, чем с инфрой номада. В кубе очень много компонентов. Да таже etcd до сих пор не очень стабильна.

Я же не против куба. Просто тут первый же коммент от Альфы был, что номад ничего не умеет, а куб панацея - это не так.

Difrex ★★★★ ()

поддерживающей оркестрацию

оркастрацию? кастрацию через горло?

anonymous ()
Ответ на: комментарий от Difrex

ничто не панацея.

и вообще всё современное Open-Source ПО делится на 2 категории: альфа и депрекейтед :)

по моему скромному мнению лучше тюнить JVM, чем париться насчёт десятых долей процента (а при должном тюнинге именно так оно и будет). Ну и если у вас bare metal (или своё облако виртуалок поверх гипервизора), то можно посмотреть в сторону SR-IOV - есть CNI-плагины, позволяющие утащить оверхед в сторону offload’а на сетевую карту. В общем, всё давно изобретено и сделано.

хотя, конечно, с аргументом «но зачем?» трудно спорить. Но зачем? :)

gr_buza ★★★★ ()
Ответ на: комментарий от Difrex

А вы:

  1. подсчитали (к слову как?), что calico Elasticsearch не вытянет;

  2. подняли Elastic в k8s, огребли проблем, перевели в номад и горя не знаете;

  3. заранее попой почуяли и не проверяли?

Я не то чтоб спорю, просто ваши слова противоречат картинкам в интернете.

возникает больше инцидентов связанных с инфрой куба

У нас основную нагрузку на k8s ещё не перевели, может в этом дело, но кубернетес — наименее проблемная часть всего. Т.е. с самим кубом вообще проблем не было, только с сервисами, которые вокруг него работают.

ugoday ★★★★★ ()
Ответ на: комментарий от Difrex

алсо, куб дешевле, потому что больше людей его знают. Нужно оценивать не по хайповым зарплатам, а по тому, как долго свеженанятый будет въезжать в стек (и как долго придётся искать того, кто уже со стеком дело имел).

gr_buza ★★★★ ()
Ответ на: комментарий от gr_buza

лучше тюнить JVM

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

Тут та же логика, что вместо подбора опций компилятора, можно включить мозг и переделать алгоритм.

ugoday ★★★★★ ()
Ответ на: комментарий от ugoday

Вдруг у человека ES as a service? Там ведь не обязательно логи, ещё и поиск :)

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

gr_buza ★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.