Вот такое же впечатление о статье сложилось. Вроде и по делу и вообще "базу нужно знать и помнить всегда", но такие нюансы портят впечатление о прочитанном.
Аргументация негативного опыта уровня "Я не разобрался в командной строке, ваш Linux — УГ!". У меня средний production-образ весит ~20-50mb, это я ещё туда системную обвязку для траблшутинга втаскиваю (всякие nc, dig, netstat, tcpdump и т.д.). Как же так?
Не уверен, что, например, готовый универсальный Nginx может проиграть чему-то самописному, даже написанному профессионалами со знанием предметной области. Потому что профессионалы со знанием предметной области возьмут как раз его. «Велосипеды» действительно существуют и не нужно считать что это всегда хорошо. NIH как явление не на пустом месте появилось.
Императивным Ansible может быть только потому что вы его сами используете как Bash на стероидах. У меня на проекте используются ислючительно идемпотентные роли, никаких сайд-эффектов (то что вы называете "мусором") никогда не имелось. Ну и медленность давно уже лечится хоть тем же Mitogen.
Федерация — не самый оптимальный механизм агрегирования метрик. Лучше брать специализированное решение, я например в качестве "апстрима" для куберовских промов беру VictoriaMetrics, хотя там сейчас полно всякого, те же Thanos, Cortex и M3.
Кросс-мониторинг интересно, я обхожусь обычным watchdog (вечно файрящий алерт, отсутствие которого как раз и говорит что что-то не так). Есть ли у кросс-мониторинга какие-то скрытые плюсы? Watchdog кроме своей основной задачи ничего по сути и не умеет, но в целом здесь больше ничего и не надо.
Я правильно понимаю, что у вас Consul Enterprise с честным суппортом? Если нет, то поделитесь пожалуйста issue на GitHub, очень интересно посмотреть на кейс, у меня разваливался консенсус серверов пару раз, но чтобы Raft наедался, такого не было.
Очень рекомендую, я тоже изначально в некотором роде следовал принципу Парето — нужно было что-то для организации динамического автоконфигурируемого DNS для VPC, взял Consul. После того как начал знакомиться с ним ближе, просто был ошарашен насколько продуманно он сделан и какой пласт задач способен решать. Не зря всё-таки в нашей индустрии вокруг HashiCorp сложился в некотором роде культ, они делают нереально крутые вещи.
Не сочтите за невежество, но Consul нужно выкатывать по всей инфре с агентом на каждой ноде, всё остальное — негуманный анти-паттерн. Consul для такого не предназначен и даже небольшая часть его потенциала не может быть реализована (конечно, возможно его использование в качестве распределенного KV-хранилища или механизма для распределённых локов, но моё субъективное мнение — в таком случае лучше взять etcd). Имея Consul на всём флоте, не нужно будет писать свои решения, можно использовать стандартные и существующие из коробки service definitions с healthcheck'aми и прочими радостями. При таком подходе на Consul можно строить что угодно, хоть DNS для инфры (для кэша лучше взять что-нибудь отдельное спереди, дабы не нагружать Consul-сервера и не вешать их на 53-й порт), хоть RR-балансировку (я, например, так обеспечиваю HA для куберовских kube-apiserver). C queries вообще можно реализовывать ещё более интересные вещи, я делал возможность через DNS получить текущего PostgreSQL-мастера в кластере Patroni.
Плюс, учитывая что у Prometheus есть конвенция, что метрики обычно отдаются по пути /metrics, я в SD просто забираю все сервисы, у которых есть тэг scrapable, и ставлю в значение job-лейбла имя сервиса через обычный релэйблинг. Одним job_name сразу всех зайцев, эдакий DRY.
Баг очень частый, на Хабре уже было несколько постов об этом, на GitHub в релевантом issue сотни комментариев. По сути настоящее решение — это только п.1 (что по сути является вариантом "ходим к coredns по TCP") — в musl воркэраунда с single-request-reopen нет, Weave CNI явно используется не всеми.
Вот такое же впечатление о статье сложилось. Вроде и по делу и вообще "базу нужно знать и помнить всегда", но такие нюансы портят впечатление о прочитанном.
Спасибо за статью. Я же правильно понимаю, что у клиента в проде Community-версия? Как вы её бэкапите? Экспорт по расписанию?
Да, благо что большая часть CNI в Kubernetes сделана более грамотно, чем сеть Docker.
Аргументация негативного опыта уровня "Я не разобрался в командной строке, ваш Linux — УГ!". У меня средний production-образ весит ~20-50mb, это я ещё туда системную обвязку для траблшутинга втаскиваю (всякие
nc,dig,netstat,tcpdumpи т.д.). Как же так?Не уверен, что, например, готовый универсальный Nginx может проиграть чему-то самописному, даже написанному профессионалами со знанием предметной области. Потому что профессионалы со знанием предметной области возьмут как раз его. «Велосипеды» действительно существуют и не нужно считать что это всегда хорошо. NIH как явление не на пустом месте появилось.
А, видимо тянете с ELRepo, понял. Я с их конфигов собираю, но только
4.19.xxx.А чем красношапочное ядро не устроило? А если билдить и мэйнтэйнить ядра самим, то почему не longterm посвежее? Один eBPF чего стоит.
А что не так с
atomicв самом Helm 2? Данная опция в нём делает тоже самое, что и в Helm 3.Императивным Ansible может быть только потому что вы его сами используете как Bash на стероидах. У меня на проекте используются ислючительно идемпотентные роли, никаких сайд-эффектов (то что вы называете "мусором") никогда не имелось. Ну и медленность давно уже лечится хоть тем же Mitogen.
Федерация — не самый оптимальный механизм агрегирования метрик. Лучше брать специализированное решение, я например в качестве "апстрима" для куберовских промов беру VictoriaMetrics, хотя там сейчас полно всякого, те же Thanos, Cortex и M3.
Кросс-мониторинг интересно, я обхожусь обычным watchdog (вечно файрящий алерт, отсутствие которого как раз и говорит что что-то не так). Есть ли у кросс-мониторинга какие-то скрытые плюсы? Watchdog кроме своей основной задачи ничего по сути и не умеет, но в целом здесь больше ничего и не надо.
Я правильно понимаю, что у вас Consul Enterprise с честным суппортом? Если нет, то поделитесь пожалуйста issue на GitHub, очень интересно посмотреть на кейс, у меня разваливался консенсус серверов пару раз, но чтобы Raft наедался, такого не было.
Очень рекомендую, я тоже изначально в некотором роде следовал принципу Парето — нужно было что-то для организации динамического автоконфигурируемого DNS для VPC, взял Consul. После того как начал знакомиться с ним ближе, просто был ошарашен насколько продуманно он сделан и какой пласт задач способен решать. Не зря всё-таки в нашей индустрии вокруг HashiCorp сложился в некотором роде культ, они делают нереально крутые вещи.
Не сочтите за невежество, но Consul нужно выкатывать по всей инфре с агентом на каждой ноде, всё остальное — негуманный анти-паттерн. Consul для такого не предназначен и даже небольшая часть его потенциала не может быть реализована (конечно, возможно его использование в качестве распределенного KV-хранилища или механизма для распределённых локов, но моё субъективное мнение — в таком случае лучше взять etcd). Имея Consul на всём флоте, не нужно будет писать свои решения, можно использовать стандартные и существующие из коробки service definitions с healthcheck'aми и прочими радостями. При таком подходе на Consul можно строить что угодно, хоть DNS для инфры (для кэша лучше взять что-нибудь отдельное спереди, дабы не нагружать Consul-сервера и не вешать их на 53-й порт), хоть RR-балансировку (я, например, так обеспечиваю HA для куберовских
kube-apiserver). C queries вообще можно реализовывать ещё более интересные вещи, я делал возможность через DNS получить текущего PostgreSQL-мастера в кластере Patroni.Плюс, учитывая что у Prometheus есть конвенция, что метрики обычно отдаются по пути
/metrics, я в SD просто забираю все сервисы, у которых есть тэгscrapable, и ставлю в значение job-лейбла имя сервиса через обычный релэйблинг. Однимjob_nameсразу всех зайцев, эдакий DRY.Баг очень частый, на Хабре уже было несколько постов об этом, на GitHub в релевантом issue сотни комментариев. По сути настоящее решение — это только п.1 (что по сути является вариантом "ходим к
corednsпо TCP") — вmuslворкэраунда сsingle-request-reopenнет, Weave CNI явно используется не всеми.Я правильно понял, что имелось ввиду то, что в рамках одного проекта в разных кластерах был установлен одинаковый
pod-network-cidr/podSubnet?Автор, ничего личного, но в вашей статье больше вреда чем пользы. Абсолютное непонимание как работает Linux и systemd.
Тут скорее требуется честное системное понимание сути происходящего. Я уже об этом высказывался.
Главное в итоге забыли. Фикс в ванилле с
5.4, EL7/CentOS7 — с3.10.0-1062.8.1.el7.Без Active Directory и Zabbix куда уж, основополагающие и важные навыки каждого SRE.