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

Бред какой. Вот ща ты указала ДИНАМИЧЕСКИЕ порты, которые выделяет номад, ставишь Traefik, например или что-то подобное и все у тебя работает + еще и удобно прямо из бэкенда менеджить:

service {
  name = "my-app"
  port = "http"
  tags = [
    "traefik-enable=true",
    "traefik.http.routers.my-app.rule=Host(`my-app.example.com`)",
    "traefik.http.routers.my-app.entrypoints=http"
  ]
}

А сейчас, когда завезли hcl2, так вообще песня просто.

Если тебе нужны статичные порты, как ты привыкла в кубе, то делай port_map:

config {
  image = "artifacts.example.com/app/app:0.0.1"
  port_map {
    http  = 8080
    https = 8443
  }
}

resources {
  network {
    port "http" {
      static = 80
    }
    port "https" {
      static = 443
    }
  }
}

Ну, и ходить все же лучше не по ip, а по http://my-app.service.consul.

Признаю, об этом не подумал.

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

В конце 17 года это было не так.

Вдруг у человека ES as a service?

Именно так. Когда кластер желтеет и начинает шарды тащить на другую ноду, то нужно, чтобы эти 20 терабайт юзера перетащились быстрее.

В 2017-2018 калика давала до 15% оверхеда на сеть, что было у них даже на сайте написано. Ну, и я не понимаю к чему вы меня призываете :). На номаде построен конкретный проект, конкретное облако, там больше никто ничего стороннего не запускает. Сам номад по возможности спрятан от оператора.

Да Господь с вами, какие призывы. Простое любопытство отчего чужой опыт отличается от своего.

Соглашусь с угодаем - мне тоже просто интересно :)

На nomad реально удобно строить свои кастомные решения. Ну, и не линуксом единым и не только контейнерами мир живет.

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

Вот тут рассказывал про nomad, если интересно https://www.youtube.com/watch?v=ouloiciOlqc

по моему скромному мнению лучше тюнить JVM, чем париться насчёт десятых долей процента

У меня тогда тоже главный админ ныл что «джава в контейнерах просто не заработает, это вы хипстеры мне голову дурите». Поэтому собственно напирал на номад, чобы jar-ники гонять без изоляции.

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

И сразу хайлоад которым все так гордились как-то резко перестал им быть. Вдруг стало ясно что это был не хайлоад а бардак :)

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

Благодарю, буду иметь в виду.

Посмотрю, спасибо.

Правда сейчас у меня ES нигде рядом нет и не предвидится, но кто знает… :)

Если тебе нужны статичные порты, как ты привыкла в кубе, то делай port_map

На один IP-адрес порт 80 можно повесить только один раз.

Nomad вешает все приложения на айпишник ноды.

Когда у меня 20 экземпляров одного web-приложения на одной ноде и всем им нужен порт 80, то мне придется добавлять к номаду какую-то абстракцию и маршрутизатор, который будет это разруливать.

В k8s каждый pod имеет свой собственный адрес. Это кстати сказать кровью и потом инженеров гугла полученное требование. Поэтому оно там вшито в дизайн.

И да, поначалу кажется что это мелочь. Нужно «просто написать скрипт». Но она потом вылезает в таком количестве мест, начиная от того что надо научить приложения разговарить друг с другом, и желательно не ходить при этом дальней дорогой через внешнюю сеть, и не заканчивая тем, что надо будет 100500 раз объяснять разработчику приложения на какой именно порт он должен подключать свой жабный дебаггер.

не обязательно istio. ingress контроллеры и без service mesh могут уметь в canary.

Сейчас спустя три года я бы может и посмотрел в сторону куба для этого проекта.

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

Когда у меня 20 экземпляров одного web-приложения на одной ноде и всем им нужен порт 80, то мне придется добавлять к номаду какую-то абстракцию и маршрутизатор, который будет это разруливать.

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

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

Consul connect из коробки.

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

Расшаришаваешь порт тегом в сервисе на Traefik и отдаешь разрабу человекочитаемый адрес для подключения. Как и в кубе в общем.

В k8s каждый pod имеет свой собственный адрес. Это кстати сказать кровью и потом инженеров гугла полученное требование. Поэтому оно там вшито в дизайн.

Это кстати сказать кровью и потом инженеров гугла полученное требование.

Лол, оно так еще в Borg было.

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

Не встречал такого. Учитывая, что она по-максимуму использует родные линуксовые сетевые средства … А как конкретно „подглюкивала“?

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

Альфа говорила про разраба, которому нужно жабовский дебагер подключить - это внешний трафик.

А как конкретно „подглюкивала“

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

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

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

В общем этот спор идет как обычно не туда.

Разумеется всё решается. Я даже начала этот разговор что я эту проблему таки решила.

Но есть разница - решать своими средствами или следовать общему стандарту. Банально когда ты начинаешь заниматься тегами в consul и traefik тебе нужно сформировать свои схемы именования этих тегов, задокументировать их, и донести до всех участников проекта. Потом осознать что первый вариант получился не очень удачным, переделать подчеркивания на дефисы или наоборот и ещё раз всё это согласовать. И в процессе этого согласования придти к концепции namespaces например, и сервисов, и replica set, и deployment configs,..

Потом осознать что документацию-то по этому делу никто так и не написал, и новому инженеру только что пришедшему в команду всю эту накостыленную структуру должен обяснить ты.

Разумеется это тоже всё можно сделать. Но это всё тоже работа. И работа будет посложнее чем баш скрипты писать.

Наверное если у тебя уже есть бОльшая часть отлаженной инфраструктуры, которую ты хочешь оставить как есть, и тебе для счастья не хватает только добавить в неё оркестратор, то nomad как встраиваемый блок подойдет.

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

а напомните как называется альтернатива traefik но какая-то на букву L. которая позволяет разделять трафик и регулировать.

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

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

С этим никто не спорит. Дело в том, что там со стандартами и апи получше. Хочешь запускать jar на freebsd - вот тебе апи кубелета, делай virtual kubelet. Хочешь хранилку секретов - вот https://github.com/hashicorp/vault-k8s, а лучше https://github.com/Azure/secrets-store-csi-driver-provider-azure. Рестарт контейнера при смене конфигмапа - тут и операторы, и https://github.com/stakater/Reloader.

А в номаде ешьте hcl, никакого вам пулуми и прочей автоматизации там не предвидиться

Azure лучше

Ага конечно. Облачные люди уже забыли что бывает bare metal и собственные облака:).

А в номаде ешьте hcl, никакого вам пулуми и прочей автоматизации там не предвидиться

Можешь тераформ взять - он умеет в номад. О, ты тот самый единственный человек, что использует пулуми в проде? Как оно тебе?

со стандартами и апи получше

Ага, beta1, alpha2 и прочие апи :)

тераформ взять - он умеет в номад

Я пыталась кстати.

Но во-первых terraform - это издевательство, у него совершенно безумный подход к областям видимости переменных.

А во-вторых когда я этим занималась, hashicorp умудрились зарелизить новую версию nomad-а несовместимую с предыдущей. А поддержку в терраформе для неё выкатили только через полгода.

В итоге ansible оказался удобнее.

Облачные люди

Все же ридми до конца дочитайте, там и волт есть.

О, ты тот самый единственный человек, что использует пулуми в проде? Как оно тебе?

Не использую, но идея нравится.

Можешь тераформ взять

Отож, только отобранные Митчеллом продукты, я понял.

По основному пункту возражений нет?

Не использую, но идея нравится.

Вот и мне тоже нравитсяно не использую.

Отож, только отобранные Митчеллом продукты, я понял.

Ansible возьми. Или тоже не ок?

По основному пункту возражений нет?

А какой основной пункт?

Это во времена 0.4 что ли было? Это как взять куб 1.3 и страдать от того, что у тебя разваливается etcd раз в день.

И что?

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

Nomad умеет в quemu-kvm, умеет ли в него k8s

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

Частично решается через topologySpreadConstraints, но конкретным нодам веса назначать нельзя.

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

spec.metadata.annotations.checksum/config - вписать сумму конфигмапы и сам все следит.

Управление весами - nodeSelector или DaemonSet чтобы на каждом узле крутить.

Blue/Green - насколько помню, несколько предидущих ReplicaSet остается, они же содержат старые версии. Перекатывание происходит автоматически если все настроить.

Для канарейки нужно, например, Istio.

Соглашусь, не все так гладко, но все на нем куда не плюнь.

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

Боюсь, с таким анамнезом сложно сказать что-то определённое.

вообще k8s со всеми его запчастями и перделками из миллиона сторонних тюнинг-ателье

K8S прямой как палка и простой как полено. Не согласны? Поработайте с OpenStack’ом. :-)

Но в чём я с вами частично согласен, k8s — это js в мире админов. Каждый первый делает какой-то свой инструментарий и приходится бежать изо всех сил, чтобы просто остоваться на месте.

Вы заметили, как пони и прочее дивёрсити любит контейнеры?

Nomad vs. Kubernetes

Сравнение неверное учитывая что в бесплатном nomad-е нет даже неймспейсов что кубер дает прям из коробки. https://www.hashicorp.com/products/vault/pricing Цену они тоже не показывают

Nomad has not provided pricing information for this product or service. This is common practice for software sellers and service providers. Contact Nomad to obtain current pricing.

linkerd

Точно, спасибо.

spec.metadata.annotations.checksum/config - вписать сумму конфигмапы и сам все следит.

Значит, придется костыли городить, т.к. helm такое не умеет. У нас и так уже Ansible генерирует values для helm, так что можно впихнуть. Спасибо, не знал про такое.

Управление весами - nodeSelector или DaemonSet чтобы на каждом узле крутить.

DaemonSet это несколько другое. Так же как и nodeSelector. Федерации же нет, я не могу в yaml прописать запустить 20% пода в dc1, а остальное в dc2.

Blue/Green - насколько помню, несколько предидущих ReplicaSet остается, они же содержат старые версии. Перекатывание происходит автоматически если все настроить.

Там же роллинг простой по умолчанию. Для blue/green нужно навешивать что-то сбоку, типа istio.

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

Неймспейсы завезли в 1.0 в open source редакцию.

А что за проект, если не секрет?

А так же для построения какого-либо сервиса

Пожалуй да, это существенное отличие.

Ты строишь сервис, на облачной платформе, но эта облачная платформа скрыта от пользователя.

А мне нужен был не один конкретный сервис а наоборот, PaaS. Потому что мне надо было не скрыть от пользователя внутреннюю структуру облака, а позволить пользователю (разработчику приложения) в ней разобраться и использовать при планировании своих микросервисов.

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

С тем же консулом например - мне не надо было чтобы моему приложению кто-то проставил тег и настроил DNS. Мне надо было чтобы любой человек в команде разработчиков разворачивая любое новое приложение на этой платформе мог указать параметры и порты этого приложения не обращаясь к админам кластера. При этом я совершенно не хочу открывать разработчикам полный доступ к консулу чтобы они там насочиняли своих собственных конфигов. Мне нужен интерфейс и протокол в рамках которого они могут действовать. K8s даёт такой протокол.

Короче говоря Nomad - это оркестратор. А K8s - это PaaS.

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

(офигеть, кстати, девочка-девопс, еще и с кубернетесом и всем чем положено.)

офигеть, кстати, девочка-девопс, еще и с кубернетесом и всем чем положено.

А чего офигевать? Это нормальное положение вещей. Видишь макбук/тхинкпадик с наклеечками, обои с понями или моэ - понимаешь, что перед тобой любитель контейнеров и js, опционально из среды с identity politics.

Только вот всему этому так и не светит вылезти из js и yaml.

с помощью 15 контейнеров на трёх железных нодах держим тот же трафик что держат 25 железные серверов гоняющий «нативное» приложение без контейнерного оверхеда.

А можно поподробнее, просто даже интересно как это так. Это просто оптимизировали приложение почти в 10 раз что ли?

Жалко что spark-over-nomad бросили. В целом логично. Но жалко.

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

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

В итоге за несколько лет роста компании админы вырастили «ферму» серверов и гордо рапортовали о своих масштабах и нагрузках начальству.

А мы распилили этот сервис до такой степени что там можно было чуть не индивидуально по каждому запросу масштабировать, что куда отправляется в реальном режиме. И кроме этого мы обложили приложения real-time-метриками и, главное, на метрики эти стали смотреть не админы серверов, а сами разработчики.

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

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

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

Конечно не поверю. Ох и врать же ты! Все неудобные особенности опустила, все остальное раздула до неприличия. Свое участие выпятила до предела. Если бы не знал про что, как и где ты говоришь - может быть и купился бы.