Комментарии 6
Используете регистрацию сервисов в consul? Динамичекий балансер, типа Traefik? Интересно почитать, как реализован выход сервисов наружу.
Да, сервисы в Consul, на них healthcheck'и.
Балансировка — типа Traefik, но свой велосипед. Когда всё это делалось Traefik только появился и чем-то не устроил, чего-то не хватало.
Там ничего необычного. Обычный nginx, с конфигом, формируемым consul-template. Список сервисов берётся из Consul по тегам + дополнительная конфигурация по сервисам — из Consul KV. Конфиг формируется, там все локейшены/апстримы и при изменениях nginx перечитывает конфиг. Апстримы сервисов добавляются/удаляются из апстримов nginx, соответственно.
Сервисы nginx прибиты к конкретным серверам с ролью "балансер". В DNS у сайтов прописаны все эти адреса. Это "домашний" кластер.
В рабочем примерно так же, но там ещё AS поверх DNS.
Поделюсь релевантным опытом из Кубера.
> С другой стороны: в 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.
> С другой стороны: в 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.
Для крона проще всего использовать supercronic.
Traifik сейчас хорош, а настройка роутинга через теги сервиса бомба (аналог ingress в кубе)
Однозначно стоит использовать консул и хранить там конфиги. С таким шаблоном все переменные из папки консула попадают в ENV и при изменении конфига nomad пересоздает jobs.
Плюс относительно куба:
— меньше ресурсов на control plane (для куба это обязательно 3 мастера 2 ядра/4 gb памяти, многие проекты могут спокойно жить в таком)
— куб использует CNI, который часто лишний (имеет смысл только для network policy, но если у вас все разруливается на уровне приложения, то бесполезно ну и есть consul connect на крайний случай)
— не нужна плоская сетка
— можно крутить все без докера, если golang или java
— hard way у куба это прилично времени (установка всего руками), у nomad это один вечер (сюда же входит написание ansible ролей), админить проще в общем
— nomad agent -dev и дев окружение готово, никаких minikube и тп
Минусы относительно куба:
— нет «все делается в одном стиле», нужно использовать много разношостных тулов
— очень мало готовых рецептов
— безопасность целиком админе (хочешь делай, хочешь нет)
— ничего нет для stateful
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
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Nomad: проблемы и решения