HashiCorp Nomad 1.0

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

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

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

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

Видел тред без шуток про корованы

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

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

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

Тонко, не сразу понял xD

простая же шутка (и тупенькая). что там было не понять

Состоялся

Зачем? К чему всё это томление духа?

настоялся

Так и не понял, чем оно лучше systemd?

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

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

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

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

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

Хороший убийца кубера. Да.

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

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

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

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

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

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

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

:(

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

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

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

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

Только вот Номад к корованам никакого отношения не имеет.

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

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

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

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

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

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

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

В 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

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

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

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

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

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

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

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

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

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

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

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

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

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

А расскажите страшные истории про страдания. Интересно же.

По факту же он не более прост, он просто реализует 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.

Я к тому, что и куб тоже допиливать нужно.

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

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

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

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

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

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

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

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

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

А blue/green деплой из коробки в кубе когда будет, а канареечный?

Это задача ISTIO.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А вы:

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

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

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

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

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

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

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

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

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

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

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

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