Nomad: проблемы и решения

[negasus]

Используете регистрацию сервисов в consul? Динамичекий балансер, типа Traefik? Интересно почитать, как реализован выход сервисов наружу.

[neenik]

Да, сервисы в Consul, на них healthcheck'и.

Балансировка — типа Traefik, но свой велосипед. Когда всё это делалось Traefik только появился и чем-то не устроил, чего-то не хватало.
Там ничего необычного. Обычный nginx, с конфигом, формируемым consul-template. Список сервисов берётся из Consul по тегам + дополнительная конфигурация по сервисам — из Consul KV. Конфиг формируется, там все локейшены/апстримы и при изменениях nginx перечитывает конфиг. Апстримы сервисов добавляются/удаляются из апстримов nginx, соответственно.

Сервисы nginx прибиты к конкретным серверам с ролью "балансер". В DNS у сайтов прописаны все эти адреса. Это "домашний" кластер.

В рабочем примерно так же, но там ещё AS поверх DNS.

[angapov]

Поделюсь релевантным опытом из Кубера.

> С другой стороны: в Kubernetes так же существует полу-самопроизвольная перезагрузка сервисов — когда планировщик Kubernetes перераспределяет инстансы в зависимости от нагрузки. Это не очень здорово, но там это настраивается скорее всего.

Да, настраивается. В случае нехватки памяти Кубер будет растаскивать только Best Effort и Burstable поды, а Guaranteed останутся на месте. Фактически, если нет оверкоммита по памяти, то и растаскивать незачем.

По части проблемы 10: в Кубере можно указывать Pod AntiAffinity (preffered или required) и указывать метадату хостов, по которой необходимо раскидывать поды. Например в публичных облаках это failure-domain.beta.kubernetes.io/zone и failure-domain.beta.kubernetes.io/region. Соответственно, в своих датацентрах можно указать свою метадату и в соответствие с ней раскидывать поды между датацентрами.

> Второй минус — непонятно, как нормально настраивать мониторинг такого сервиса. Как понять, что сервис запускается, отрабатывает и выполняет свою работу до конца?

В Кубере все зависит от кода выхода джобы. Если код выхода ненулевой, то прилетит алерт, что такая-то джоба фейлится.

По части проблемы 8: такая проблема есть в любых распределенных системах. В Кубере все обстоит точно так же и тоже надо тюнить таймауты kubelet'ов. Другое дело, что если запущен StatefulSet и нода вдруг зависла, т.е. на пинги отвечает, а по факту ничего не работает (например, в Амазоне неожиданно закончились EBS credits у рутового диска), то Кубер не будет перезапускать под на другой ноде, т.к. видимо предполагает, что это может привести к повреждению данных. В этом случае единственный выход, который я нашел — выкидывание ноды на свалку (т.к. рутовый диск будет долго и нудно регенерировать иопсы, легче удалить тачку, а Амазон поднимет новую). По сути, это тот же fencing для кластерных систем. Кстати, проблема с заканчивающимися EBS credits была связана с Docker storage driver, по дефолту ставился overlay, а надо было поставить overlay2.

[alexesDev]

Для крона проще всего использовать supercronic.
Traifik сейчас хорош, а настройка роутинга через теги сервиса бомба (аналог ingress в кубе)

        tags = [
          "traefik.enable=true",
          "traefik.frontends.A.rule=Host:site1.ru;PathPrefix:/api",
          "traefik.frontends.B.rule=Host:site2.ru;PathPrefix:/api",
        ]

Однозначно стоит использовать консул и хранить там конфиги. С таким шаблоном все переменные из папки консула попадают в ENV и при изменении конфига nomad пересоздает jobs.

     template {
        data = <<EOH
{{ range ls "backend" }}
{{ .Key }}={{ .Value }}{{ end }}
EOH

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

Плюс относительно куба:
— меньше ресурсов на control plane (для куба это обязательно 3 мастера 2 ядра/4 gb памяти, многие проекты могут спокойно жить в таком)
— куб использует CNI, который часто лишний (имеет смысл только для network policy, но если у вас все разруливается на уровне приложения, то бесполезно ну и есть consul connect на крайний случай)
— не нужна плоская сетка
— можно крутить все без докера, если golang или java
— hard way у куба это прилично времени (установка всего руками), у nomad это один вечер (сюда же входит написание ansible ролей), админить проще в общем
— nomad agent -dev и дев окружение готово, никаких minikube и тп

Минусы относительно куба:
— нет «все делается в одном стиле», нужно использовать много разношостных тулов
— очень мало готовых рецептов
— безопасность целиком админе (хочешь делай, хочешь нет)
— ничего нет для stateful

[negasus]

— можно крутить все без докера, если golang или java

Это имеется ввиду, использовать драйвер Fork/Exec?
(я в контексте Golang)

[alexesDev]

Да. Там драйвер умеет скачивать бинари или архив бинаря и запускать в chroot. В каком-то ci создается артифакт и выполняется nomad run с ссылкой на этот артифакт — все хорошо работает.