Комментарии 9
Полезная статья, спасибо.
Но "490 проб, исполняющиеся каждые 3 секунды" меня сразу смущает, когда мониторинг выполняется чаще, чем раз в минуту, а обычно стараюсь делать максимально редко (например свободное место на дисках - раз в 10 минут или даже реже).
А каждые 3 секунды, чтобы это ни было, мне кажется это больше режим отладки, чем нормальный мониторинг.
Я даже подозреваю, что 490 http проб каждые 3 секунды, это тоже весьма немалая нагрузка, вполне даже сопоставимая с нагрузкой пользователей не самого маленького сервиса.
Можете детальнее пояснить, зачем нужно так много и так часто?
Странный вопрос
Дело тут не в мониторинге, а в readinessprobe, которая отвечает за наличие ip пода в списке эндпоинтов сервиса. Иначе говоря, под, у которого зафейлилась риднеспроба, должен быть оперативно выкинут из балансировщика.
Я знаю, что такое пробы.
Но вопрос - оперативность должна составлять 3 секунды?
Если у вас 490/3 = 163 запроса в секунду создает 10% нагрузки на ваши сервисы, то я бы и http пробы попробовал оптимизировать. Может быть ендпоинты у вас "тяжелые", может с них можно снять https, или проверить вдруг там авторизация включена, облегчить по максимуму. Либо поднимать мощность самих нод, снижать количество подов на одной ноде. Ибо мониторинг не должен столько есть...
Либо может быть просто не нужна такая оперативность, можно подождать 10 секунд, 20 секунд?
Что касается exec проб, я в продакшене их не использовал, и тоже подозревал что они конечно больше нагружают, и спасибо за статью, что прояснили сколько под капотом идет служебной нагрузки до собственно самой команды внутри exec. Но я подсознательно явно был бы против делать exec каждые 3 секунды. Я просто интуитивно понимаю, что я бы сперва померял производительность, а уже потом бы делал.
Выше написано совершенно верно. Речь идет в том числе про readiness пробы. Задача которых убрать нездоровый сервис из раутера траффика как можно быстрее. Поэтому readiness реже чем раз в 3 секунды делать не хотим.
Что касается нагрузки, 10% при HTTP создаются не именно пробами. Это общая нагрузка на systemd, которая включает в себя множество всего. А вот дельта 10% → почти 100% была от exec проб.
Что касается решения на продакшне - да, было смутное подозрение. Вот проверили. И спешим поделиться граблями. Про что и статья :D
Я так понимаю эта ситуация коррелирует и с размером инстанса. Если у вас большие ноды на которых крутятся сотни подов, то могут быть проблемы, но если на ноде крутится с десяток тяжеловесных подов, то проблем не будет?
По моему опыту для большинства нагрузок оптимальный размер нод, если в классификации Амазона, это xlarge и 2xlarge. И те же крупные дев кластера лучше скейлить горизонтально.
Да, стараемся делать относительно небольшие ноды. Это рассказ про внутренний кластер, там что-то похожее на 2xlarge.
Если крутится с десяток подов, то проблемы бы не было.
Однако архитектура биллингового решения такая, что на один сетап крутится около двух десятков сервисов, написанных достаточно оптимально на C++ и Go. Они рассчитаны на нагрузки в сколько-то тысяч запросов в секунду, поэтому вялые функциональные юнит-тесты они просто не замечают как нагрузку. И потребляют что-то типа скольки-то миликор ядра и 128мб памяти.
Поэтому на девелоперских кластерах мы можем размещать большое количество подов на одной ноде. Просто потому что им на дев-нагрузках много ресурсов и не надо.
Поэтому даже 2xlarge объем в нашем мире – это примерно 250 подов.
Не раскрыта тема: "Почему?". Что такое происходило (да и происходит) в systemd, что он есть столько CPU. 10% - это тоже сильно много, не говоря уже о полке в 100%. Надо было тыкать в него strace'ом и смотреть. Хотя, если он и сейчас ест больше 1%, то смело можно это делать.
Почему вообще в данном сетапе такие проблемы, я про связку kubernetes и systemd?
Я поддерживаю вопрос. Если по http пробам вот даже кусочек кода выложили, то каким образом связан runc (а я так понимаю любой exec из containerd спускается туда) и исполнение systemd я так и не понял. Может дадите пояснение?
Добрый день. Куски кода по этим частям - по ссылкам из статьи. Там в целом достаточно разветвленная структура как все устроено, проще выкачать их репо и разобрать в идее/голанде.
Хттп проба элементарна, поэтому с ней проще.
Вот эти штуки бегут в runc и далее в systemd - https://github.com/containerd/containerd/blob/36cc874494a56a253cd181a1a685b44b58a2e34a/pkg/cri/server/container_execsync.go#L109
Их там достаточно много вокруг.
Exec-пробы: история про эксперимент и свежие грабли