Очередная не такая как все SWE-снежинка надула щёчки!
Посмотрел в профиль, ещё раз ухмыльнулся. Почему-то постоянно попадаются выходцы из Я с синдромом "я очень особенный и классный", что в виде буковок в интернете, что в виде реальных коллег.
Вы хотя бы немножко думайте, когда переводите. Девушка бы очень удивилась, узнав, что она усилиями русских переводчиков оказывается стала мальчиком. И вообще, где пометка что это перевод?
Вот такое же впечатление о статье сложилось. Вроде и по делу и вообще "базу нужно знать и помнить всегда", но такие нюансы портят впечатление о прочитанном.
Аргументация негативного опыта уровня "Я не разобрался в командной строке, ваш 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 явно используется не всеми.
А когда Citus успел стать неподдерживаемым?
Очередная не такая как все SWE-снежинка надула щёчки!
Посмотрел в профиль, ещё раз ухмыльнулся. Почему-то постоянно попадаются выходцы из Я с синдромом "я очень особенный и классный", что в виде буковок в интернете, что в виде реальных коллег.
Не используйте ReplicaSet даже для "максимально тестовых окружений".
Вы хотя бы немножко думайте, когда переводите. Девушка бы очень удивилась, узнав, что она усилиями русских переводчиков оказывается стала мальчиком. И вообще, где пометка что это перевод?
Вот такое же впечатление о статье сложилось. Вроде и по делу и вообще "базу нужно знать и помнить всегда", но такие нюансы портят впечатление о прочитанном.
Спасибо за статью. Я же правильно понимаю, что у клиента в проде 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.