nomad программа что это
NOMAD BoT
NOMAD — Визуальная среда для разработки ботов, которая включает в себя набор инструментов позволяющий создавать программы, автоматизирующие рутинные операции, выполняемые на компьютере. В частности, данный продукт может быть использован для написания программ-ботов к онлайн играм.
о программе коротко:
Подробнее:
Функции поиска объекта на изображении включают:
a) Цветонезависимый поиск объекта. (даже если цвет объекта меняется, он все равно находится без необходимости что либо менять в коде программы)
b) Поиск объектов в диапазоне цветов.
c) Поиск группы пикселей определенного цвета или диапазона цветов (с настройкой чувствительности).
d) Любой поиск может осуществляться по неполному соответствию.
e) Поиск объектов относительно других объектов (сверху, справа, слева, снизу, между двумя объектами)
i) Поиск определенного объекта среди одинаковых (найти первый, третий и т.п.)
j) Поиск изображений по четырем фрагментам позволяет искать изменяющиеся в размерах четырех угольные объекты (окна, таблицы и т.п.)
Функции эмуляции работы мыши, в том числе, и на низком уровне позволяют работать с приложениями, которые используют защиту от программ кликеров. (Работает с Frost,GameGuard) При этом клик выполняется в случайном месте заданной области, а движение может выполняться по случайной нелинейной траектории. Также между кликами выполняются паузы на случайные промежутки времени. Весь этот комплекс мер направлен на осложнение задачи по обнаружению вашего бота программными средствами призванными защитить приложение от кликеров.
Встроенный язык программирования позволяет импортировать функции из внешних dll. Таким образом, при программировании вы можете использовать, например, любые WinAPI функции. Данные функции позволяют эмулировать работу мыши или клавиатуры, а также с помощью этих функций можно работать с окнами сторонних приложений (любые программы для работы с окнами используют именно эти функции).
Функция распознавания текста позволяет распознавать и преобразовывать в текст надписи на изображении, при этом неизвестные шаблоны букв автоматически заносятся в базу данных, и разработчику остается только присвоить им соответствующие идентификаторы. Таким образом, у Вас нет необходимости создавать эти шаблоны вручную. Также необходимо отметить, что данный метод распознавания образов может применяться не только к текстовой информации.
Встроенный графический редактор позволяет делать скриншоты экрана и подготавливать графическую информацию, непосредственно в программе, без необходимости использовать для этого графические редакторы сторонних производителей.
Для программирования используется скриптовый язык программирования максимально приближенный по синтаксису к языку Pascal. Сам процесс программирования происходит во встроенном текстовом редакторе с подсветкой синтаксиса.
GUI программы создается с помощью визуальных средств. В программе используются те же элементы управления, что и в IDE Delphi, а значит, при необходимости, вы легко можете отыскать большое количество информации по особенностям их использования в интернете.
Возможность подключаться из создаваемого приложения к сторонним программам посредством технологии COM соединения. (например, можно создать таблицу Excel).
NOMAD: Оптимизация «черных ящиков» в домашних условиях
Оптимизируемый (минимизируемый) функционал рассматривается как «черный ящик», за его вычисление отвечает отдельно имплементированный скрипт или программа (при работе в batch-mode) или специально реализованный С++-класс (при работе в library-mode). Оптимизация ведется при помощи алгоритма MADS
Исходники поставляются под лицензией LGPL, доступны версии для Unix, Linux, Mac OS X и Windows, для скачивания не требуется регистрация, но нужно заполнить небольшую форму (имя, организация, город, страна).
Зачем это нужно
Базовый сценарий таков. Вы разрабатываете вундервафлю, которая делает свой посильный вклад во имя всеобщего блага. В процессе работы используются крутые супер-современные методы и алгоритмы, настраиваемые через числовые параметры, которые вынесены у вас в конфиги (если просто не светятся в коде в виде магических цифр). У системы есть некоторый показатель качества, вычисляемый неизвестно как, и сейчас он находится на отметке 98 %, а вам неймется достигнуть 99.5 %. Хочется инструмент, которому можно было бы выдать «крутилки», и пойти попить чайку, в то время, как он поднимет качество системы чуть-чуть повыше. Неплохим инструментом для решения такого класса задач является NOMAD.
Частный случай. Для решения одной и той же задачи вы используете два разных алгоритма. Задача подразумевает некоторую классификацию или оценку входного объекта (пример — распознавание), на выходе вы получаете вектор значений оценок (пример — выходной вектор альтернатив у нейронной сети). На одном типе исходных данных лучше работает первый алгоритм, на другом — второй алгоритм, а четко разграничить типы входных данных вы по каким-то причинам не можете. Возможным выходом из положения является использование обоих алгоритмов, и «усреднение» результатов а-постериори. Вопрос только в том, с какими коэффициентами (весами) проводить усреднение результатов. Для определения оптимальных коэффициентов усреднения можно использовать NOMAD, если назначить функционалом, скажем, суммарное количество ошибок или некоторый суммарный штраф на заданной выборке входных данных.
Как этим пользоваться
Рассмотрим несложный пример использования NOMAD в режиме batch mode. Задача такая: вы хотить построить простую функцию, разбивающую объекты из множества X на два класса: A и B. Проведя небольшое статистическое исследование, вы обнаружили, что существуют признаки f1, f2 и f3, свидетельствующие о принадлежности объекта x какому-то классу. f1, f2 и f3 — функции от объекта, значением которых является действительное число. Классифицирующую функцию будем искать в виде C(x) = a1*f1(x) + a2*f2(x) + a3*f3(x) + b, где a1, a2, a3 — действительные числа, а b — целое от -1 до 1. Если C(x) >= 0, то будем говорить, что x принадлежит A, иначе x принадлежит B. Загвоздка в том, что если мы ошиблись и определили объект x к множеству B, хотя он на самом деле из A, то это конечно неприятно, но не смертельно, а вот если мы определили x в A, а должны были в B, то это в 100 раз хуже.
Есть несколько остроумных способов решить эту задачу, мы же, для примера, построим оценочный функционал и найдем коэффициенты при помощи NOMAD.
Пусть есть обучающая база, содержащая такие данные: истинный класс (куда мы должны определить
x) и значения признаков f1(x), f2(x), f3(x). База представляет собой такой текстовый файл: (скажем, base.data)
Функционал определяем таким образом: просматриваем базу, если произошла ошибка — то приибавляем к значению функционала стоимость этой ошибки. Стоимость ошибки «надо А, а мы сказали В» равна единице, стоимость ошибки «надо В, а мы сказали А» равна 100.
Пишем простую программку, принимающую в качестве единственного аргумента среды файл с коэффициентами a1, a2, a3, b и выводящую в стандартный поток вывода значение функционала.
Следующий шаг — конфигурационный файл NOMAD: (скажем, params.nomad)
В последней строчке — искомые коэффициенты.
Дополнительные возможности
В конфигурационном файле есть возможность указать огромное количество дополнительных параметров алгоритма оптимизации, в данном обзоре описаны лишь основные.
Есть также возможность использовать NOMAD как статическую С++-библиотеку (режим library mode). В этом случае нужно написать класс, вычисляющий функционал, что то вроде:
Послесловие
Пример получился слегка натянутым, для более эффективного поиска нужно было конечно использовать режим library mode. Кроме того, функционал в данном случае представляет собой сумму масштабированных сигнальных функций, можно было существенно облегчить работу алгоритму, если аппроксимировать эти сигнальные функции какими-нибудь сигмоидами. Функционал, по крайней мере, получился бы непрерывным. Но цель — проиллюстрировать — достигнута.
Буду рад услышать про другие инструменты, позволяющие выполнять что-то подобное, если кому-то таковые известны и есть опыт успешного применения.
Nomad программа что это
Nomad.NET это наследник Nomad, мощного файлового менеджера написанного мною несколько лет назад. Программа была полностью переписана (ни одной строчки кода не было использовано из предыдущего Nomad) используя лучшие идеи и алгоритмы и реализована совершенно по новому.
Обзор Возможностей
Чтобы узнать о возможностях оригинального Nomad, вы можете посетить соответсвующую страничку. Здесь же я поишу те функции которых не было в старой программе или которые очень сильно изменились:
Как вы видите главная идея нового Nomad.NET это реализовать то же самое более простым и элегантным способом.
Скриншот
Одна картинка может сказать больше чем тысячи слов.
Лицензия
Nomad.NET это бесплатный програмный продукт (freeware), вы можете бесплатно использовать и распространять Nomad.NET, за исключением тех случаев когда вы извлекаете из этого прибыль. Вам не предоставляется никаких гарантий, используйте данное приложение на свой страх и риск. Полный текст лицензии вы можете прочесть здесь.
Также в поставку Nomad входит других библиотек которые написаны не мной, и соответсвенно они распостраняются под другими лицензиями. Текст лицензии для библиотеки 7z.dll находится здесь. Полный текст Стандартной общественной лицензии ограниченного применения GNU (GNU lesser general public license) может быть найден здесь (используется для 7z.dll и TagLib#).
Отдельное Спасибо
Спасибо
Тажке я хочу сказать спасибо следующим людям и организациям, без их явной или неявной помощи данная программа могла бы и не появится:
Русские Блоги
Начало работы с Nomad
Введение в Nomad
Установка Nomad
В обычной среде сначала установите Vagrant и используйте Vagrant для подключения к локальному Virtualbox, чтобы создать локальную тестовую среду. Однако из-за отсутствия некоторых компонентов в локальной среде win7 в процессе обучения, Vagrant не может быть установлен и использован.
Так что используйте виртуальную машину Linux для обучения. В этой среде используется Ubuntu 16.04, Docker версии 17.09.0-ce.
Введите nomad в терминале, вы увидите подсказку nomad, то есть установка прошла успешно.
Запустить Nomad
Для простоты работы мы запускаем Nomad agent в режиме разработки. В режиме разработки можно быстро запустить серверную и клиентскую части, протестировать и изучить Nomad.
В выходных данных терминала вы можете видеть, что и сервер, и клиент верны, что означает, что и сервер, и клиент включены.
Узел кластера Nomad
В выходных данных отображается идентификатор нашего узла, который представляет собой случайно сгенерированный UUID, его дата-центр, имя узла, категорию узла, режим воронки и текущий статус. Мы видим, что наш узел находится в состоянии готовности.
Вывод показывает наш собственный сервер, рабочий адрес, рабочий статус, некоторую информацию о версии, а также центр обработки данных и регион.
Остановить агента Nomad
Вы можете использовать Ctrl-C, чтобы прервать работу агента. По умолчанию все сигналы приводят к принудительному закрытию агента.
Nomad Job
Пример работы
Чтобы запустить это задание, мы используем команду nomad run.
Для просмотра статуса работы мы используем команду nomad status
Чтобы проверить распределение заданий, мы используем команду nomad alloc-status.
Используйте данную команду обновления, чтобы обновить задание.
Чтобы остановить работу, мы используем команду остановки кочевников. Используйте команду nomad status, чтобы убедиться, что статус этого задания мертв (остановлен).
Настройте простой кластер Nomad
Запустить сервер
Мы видим, что клиентский режим отключен, и мы просто работаем как сервер. Это означает, что сервер будет управлять состоянием и принимать решения по расписанию, но не будет выполнять никаких задач. Теперь нам нужны агенты для выполнения задач!
Запустить клиента
Как и в случае с сервером, мы должны сначала настроить клиента. Пожалуйста, начните сgithubЗагрузите конфигурацию client1 и client2 или вставьте следующее в client1.hcl:
Скопируйте файл client2.hcl, измените data_dir на «/ tmp / client2» и измените порт на 5657. После создания этих двух файлов client1.hcl и client2.hcl открывают каждую вкладку и запускают агент:
В выходных данных мы видим, что агент работает только в клиентском режиме. Агент будет доступен для выполнения задач, но не будет участвовать в управлении кластером или принятии решений по расписанию.
использоватьnode-statusКоманда Мы должны увидеть два узла в состоянии готовности:
Теперь у нас работает простой трехузловой кластер. Единственная разница между демонстрационным и полным производственным кластером состоит в том, что мы запускаем один сервер вместо трех или пяти.
Отправить работу
Теперь у нас есть простой кластер, мы можем использовать его для планирования работы. У нас также должен быть файл задания перед example.nomad, но убедитесь, что count по-прежнему установлен на 3.
Затем используйтеrunКоманда для отправки задания:
На выходе мы видим, что планировщик назначил две задачи одному из клиентских узлов, а остальные задачи были назначены второму клиенту.
Мы можем снова использоватьstatusПроверка команды:
Мы видим, что все наши задачи назначены и выполняются. Как только мы будем удовлетворены своей работой, мы можем удалить ее nomad stop 。
Nomad: проблемы и решения
Первый сервис в Nomad я запустил в сентябре 2016 года. На данный момент пользуюсь как программист и занимаюсь поддержкой как администратор двух Nomad кластеров — один «домашний» для своих личных проектов (6 микро-виртуалок в Hetzner Cloud и ArubaCloud в 5 разных датацентрах Европы) и второй рабочий (порядка 40 приватных виртуальных и физических серверов в двух датацентрах).
За прошедшее время накопился довольно большой опыт работы с Nomad окружением, в статье опишу встреченные проблемы Nomad и как с ними можно справиться.
Ямальский кочевник делает Continous Delivery инстанса вашего ПО © National Geographic Россия
1. Количество серверных нод на один датацентр
Решение: на один датацентр достаточно одной серверной ноды.
В документации явно не указано, какое число серверных нод требуется в одном датацентре. Указано только, что на регион нужно 3-5 нод, что логично для консенсуса raft протокола.
В начале я запланировал 2-3 серверных ноды в каждом датацентре для обеспечения резервирования.
По факту использования оказалось:
2. Ресурсы сервера для серверной ноды
Решение: для серверной ноды достаточно небольшой виртуальной машины. На этом же сервере допускается запускать другие служебные нересурсоёмкие сервисы.
Потребление памяти демоном Nomad зависит от количества запущенных задач. Потребление CPU — от количества задач и от количества серверов/агентов в регионе (не линейно).
В нашем случае: для 300 запущенных задач потребление памяти — около 500 МБ для текущей мастер-ноды.
В рабочем кластере виртуальная машина для серверной ноды: 4 CPU, 6 GB RAM.
Дополнительно запущены: Consul, Etcd, Vault.
3. Консенсус при нехватке датацентров
Решение: делаем три виртуальных датацентра и три серверных ноды на два физических датацентра.
Работа Nomad в рамках региона основана на протоколе raft. Для корректной работы нужно не менее 3 серверных нод, расположенных в разных датацентрах. Это даст возможность корректной работы при полной потере сетевой связности с одним из датацентров.
Но у нас только два датацентра. Идём на компромисс: выбираем датацентр, которому мы доверяем больше, и делаем в нём дополнительную серверную ноду. Делаем это путём введения дополнительного виртуального датацентра, которой физически будет находится в том же датацентре (см. подпункт 2 проблемы 1).
Альтернативное решение: разбиваем датацентры на отдельные регионы.
В итоге датацентры функционируют независимо и консенсус нужен только внутри одного датацентра. Внутри датацентра в таком случае лучше сделать 3 серверных ноды путём реализации трёх виртуальных датацентров в одном физическом.
Этот вариант менее удобен для распределения задач, но даёт 100% гарантии независимости работы сервисов в случае сетевых проблем между датацентрами.
4. «Сервер» и «агент» на одном сервере
Решение: допустимо, если у вас ограничено число серверов.
В документации Nomad написано, что так делать нежелательно. Но если у вас нет возможности выделить под серверные ноды отдельные виртуальные машины — можно разместить серверную и агентскую ноду на одном сервере.
Под одновременным запуском подразумевается запуск демона Nomad одновременно в режиме клиента и в режиме сервера.
Чем это грозит? При большой нагрузке на CPU данного сервера серверная нода Nomad будет работать нестабильно, возможны потери консенсуса и хартбитов, перезагрузки сервисов.
Чтобы этого избежать — увеличиваем лимиты из описания проблемы №8.
5. Реализация пространств имён (namespaces)
Решение: возможно, через организацию виртуального датацентра.
Иногда требуется запустить часть сервисов на отдельных серверах.
Решение первое, простое, но более требовательное к ресурсам. Разделяем все сервисы на группы по назначению: frontend, backend,… Добавляем meta атрибуты серверам, прописываем атрибуты для запуска всем сервисам.
Решение второе, простое. Добавляем новые сервера, прописываем им meta атрибуты, прописываем эти атрибуты запуска нужным сервисам, всем остальным сервисам прописываем запрет запуска на серверах с этим атрибутом.
Решение третье, сложное. Создаём виртуальный датацентр: запускаем Consul для нового датацентра, запускаем серверную ноду Nomad для данного датацентра, не забывая о количестве серверных нод для данного региона. Теперь можно запускать отдельные сервисы в данном выделенном виртуальном датацентре.
6. Интеграция с Vault
Решение: избегать циклических зависимостей Nomad Vault.
Запускаемый Vault не должен иметь никаких зависимостей от Nomad. Прописываемый в Nomad адрес Vault желательно должен указывать напрямую на Vault, без прослоек балансеров (но допустимо). Резервирование Vault в таком случае можно делать через DNS — Consul DNS или внешний.
Если в конфигурационных файлах Nomad прописаны данные Vault, то Nomad при запуске пытается получить доступ к Vault. Если доступ неуспешен, то Nomad отказывается запускаться.
Ошибку с циклической зависимостью я сделал давно, этим однажды кратковременно почти полностью разрушив кластер Nomad. Vault был запущен корректно, независимо от Nomad, но Nomad смотрел на адрес Vault через балансеры, которые были запущены в самом Nomad. Переконфигурация и перезагрузка серверных нод Nomad вызвала перезагрузку сервисов балансера, что привело к отказу запуска самих серверных нод.
7. Запуск важных statefull сервисов
Решение: допустимо, но я так не делаю.
Можно ли запускать PostgreSQL, ClickHouse, Redis Cluster, RabbitMQ, MongoDB через Nomad?
Представьте, что у вас есть набор важных сервисов, на работу которых завязана большая часть остальных сервисов. Например, БД в PostgreSQL/ClickHouse. Или общее кратковременное хранилище в Redis Cluster/MongoDB. Или шина данных в Redis Cluster/RabbitMQ.
Все эти сервисы в каком-то виде реализуют отказоустойчивую схему: Stolon/Patroni для PostgreSQL, своя реализация raft в Redis Cluster, своя реализация кластера в RabbitMQ, MongoDB, ClickHouse.
Да, все эти сервисы вполне можно запустить через Nomad с привязкой к конкретным серверам, но зачем?
Плюс — удобство запуска, единый формат сценариев, как и у остальных сервисов. Не нужно мучаться со сценариями ansible/чем-то ещё.
Минус — дополнительная точка отказа, которая не даёт никаких преимуществ. Лично я полностью ронял кластер Nomad два раза по разным причинам: один раз «домашний», один раз рабочий. Это было на первых этапах внедрения Nomad и из-за неаккуратности.
Так же, Nomad начинает себя плохо вести и перезапускать сервисы из-за проблемы №8. Но даже если та проблема у вас решена, опасность остаётся.
8. Стабилизация работы и рестартов сервисов в нестабильной сети
Решение: использование опций тюнинга хартбитов.
По умолчанию Nomad сконфигурирован так, что любая кратковременная проблема сети или нагрузка на CPU, вызывает потерю консенсуса и перевыборы мастера или пометку агентской ноды недоступной. И это приводит к самопроизвольным перезагрузкам сервисов и перенос их на другие ноды.
Статистика «домашнего» кластера до исправления проблемы: максимальное время жизни контейнера до рестарта — около 10 дней. Тут всё ещё отягощается запуском агента и сервера на одном сервере и размещением в 5 разных датацентрах Европы, что предполагает большую нагрузку на CPU и менее стабильную сеть.
Статистика рабочего кластера до исправления проблемы: максимальное время жизни контейнера до рестарта — больше 2 месяцев. Тут всё относительно хорошо из-за отдельных серверов для серверных нод Nomad и отличной сети между датацентрами.
Значения по умолчанию
Судя по коду: в такой конфигурации хартбиты делаются каждые 10 секунд. При потере двух хартбитов начинаются перевыборы мастера или перенос сервисов с агентской ноды. Спорные настройки, на мой взгляд. Отредактируем их в зависимости от применения.
Если у вас все сервисы запущены в нескольких экземплярах и разнесены по датацентрам, то скорее всего, для вас не имеет значения долгий период определения недоступности сервера (примерно 5 минут, в примере ниже) — делаем реже интервал хартбитов и больший период определения недоступности. Это пример настройки моего «домашнего» кластера:
Если же у вас хорошая сетевая связность, отдельные сервера для серверных нод и важен период определения недоступности сервера (есть какой-то сервис, запущенный в одном экземпляре и важно его быстро перенести), то увеличиваем период определения недоступности (heartbeat_grace). Опционально можно сделать чаще хартбиты (уменьшив min_heartbeat_ttl) — от этого незначительно вырастет нагрузка на CPU. Пример конфигурации рабочего кластера:
Данные настройки полностью устраняют проблему.
9. Запуск периодических задач
Решение: периодические сервисы Nomad использовать можно, но «cron» удобнее для поддержки.
В Nomad есть возможность периодического запуска сервиса.
Единственный плюс — простота такой конфигурации.
Первый минус — если сервис будет запускаться часто, то он будет захламлять список задач. Например, при запуске каждые 5 минут — в список будет добавляться 12 лишних задач каждый час, до срабатывания GC Nomad, который удалит старые задачи.
Второй минус — непонятно, как нормально настраивать мониторинг такого сервиса. Как понять, что сервис запускается, отрабатывает и выполняет свою работу до конца?
В итоге, для себя я пришёл к «cron» реализации периодических задач:
На данный момент я большую часть времени пишу на Go, соответственно, предпочитаю второй вариант с http healthcheck’ами — на Go и периодический запуск, и http healthcheck’и добавляются несколькими строчками кода.
10. Обеспечение резервирования сервисов
Решение: простого решения нет. Есть два варианта посложнее.
Схема обеспечения резерва, предусмотренная разработчиками Nomad, состоит в поддержке количества запущенных сервисов. Говоришь номаду «запусти мне 5 инстансов сервиса» и он их где-то там запускает. Контроля над распределением нет. Инстансы могут запуститься на одном сервере.
Если сервер упал — инстансы переносятся на другие сервера. Пока инстансы переносятся — сервис не работает. Это плохой вариант обеспечения резерва.
В Nomad 0.9 появится функционал, который устранит эту проблему: возможно будет распределять сервисы в процентном соотношении между серверами и датацентрами.
11. Web UI Nomad
Решение: встроенный UI — ужасен, hashi-ui — прекрасен.
Консольный клиент выполняет большую часть требуемого функционала, но иногда хочется посмотреть графики, понажимать кнопочки.
В Nomad встроен UI. Он не очень удобен (даже хуже консольного).
Единственная, известная мне альтернатива — hashi-ui.
По факту, сейчас консольный клиент лично мне нужен только для «nomad run». И даже это в планах перенести в CI.
12. Поддержка oversubscription по памяти
Решение: нет.
В текущих версия Nomad обязательно указывать строгий лимит памяти для сервиса. При превышении лимита — сервис будет убит OOM Killer.
Oversubscription — это когда лимиты сервису могут быть указаны «от и до». Некоторым сервисам при запуске требуется больше памяти, чем при обычной работе. Некоторые сервисы могут кратковременно потреблять больше памяти, чем обычно.
Выбор строго ограничения или мягкого — тема для дискуссий, но, например, Kubernetes даёт программисту сделать выбор. К сожалению, в текущих версиях Nomad такой возможности нет. Допускаю, что появится в будущих версиях.
13. Очистка сервера от сервисов Nomad
Решение:
Иногда «что-то идёт не так». На сервере убивает агентскую ноду и она отказывается запускаться. Или агентская нода перестаёт отвечать на запросы. Или агентская нода «теряет» сервисы на данном сервере.
Такое иногда случалось со старыми версиями Nomad, сейчас такое или не происходит, или очень редко.
Что в таком случае сделать проще всего, учитывая, что drain сервера не даст нужного результата? Очищаем сервер вручную:
14. Как лучше разворачивать Nomad?
Решение: конечно, через Consul.
Consul в данном случае — отнюдь не лишняя прослойка, а органично вписывающийся в инфраструктуру сервис, который даёт больше плюсов, чем минусов: DNS, KV хранилище, поиск сервисов, мониторинг доступности сервиса, возможность безопасного обмена информацией.
Кроме того, он разворачивается так же просто, как и сам Nomad.
15. Что лучше — Nomad или Kubernetes?
Решение: зависит от.
Раньше у меня иногда появлялась мысль начать миграцию в Kubernetes — так сильно меня раздражал периодическая самопроизвольная перезагрузка сервисов (см. проблему №8). Но после полного решения проблемы могу сказать: Nomad меня устраивает на данный момент.
С другой стороны: в Kubernetes так же существует полу-самопроизвольная перезагрузка сервисов — когда планировщик Kubernetes перераспределяет инстансы в зависимости от нагрузки. Это не очень здорово, но там это настраивается скорее всего.
Плюсы Nomad: очень легко разворачивается инфраструктура, простые сценарии, хорошая документация, встроенная поддержка Consul/Vault, что в свою очередь даёт: простое решение проблемы хранения паролей, встроенный DNS, простые в настройке хелсчеки.
Плюсы Kubernetes: сейчас это «стандарт де факто». Хорошая документация, множество готовых решений, с хорошим описанием и стандартизацией запуска.
К сожалению, у меня нет такого же большого экспертного опыта в Kubernetes, чтобы однозначно ответить на вопрос — что использовать для нового кластера. Зависит от планируемых потребностей.
Если у вас планируется множество неймспейсов (проблема №5) или ваши специфические сервисы потребляют много памяти на старте, далее освобождая её (проблема №12) — однозначно Kubernetes, т.к. эти две проблемы в Nomad решены не до конца или неудобно.