Доброго времени суток, подскажите пожалуйста, какой механизм отвечает за drain

& delete nodes in notready state(если такой есть), cas?(aws eks)

есть несколько параллельных механизмов которые не связаны друг с другом, ну точнее связь довольно тонкая. есть контроллеры со стороны облака, к которым ты не имеешь никакого доступа, например котноллер который managed группами управляет а есть например cluster-autoscaler, к которому ты имеешь доступ оба эти механизма могут дрейнить ноды и удалять их

Спасибо, у меня ситуация следующая: cas+bottlerocket, настроен memory eviction через userdata, но под memory node pressure kubelet не евиктит никого, в след зачем нода понятное дело notready, но в таком статусе она может висеть минут 30, ясное дело что в это время все поды на ней «зависли», куда копать что бы ускорить процесс удаления именно notready нод? Или костылять условным кроном?

насколько я помню cluster autoscaler не будет удалять зависшую ноду скорее всего. Он удаляет при процессе даунскейла или когда апскейл произошел неудачно, ожидается таймаут и нода удаляется

в любой ситуации если кублет отьехал то каюк, на кублет резервацию настройте

Есть, но все равно вылазит. Кажется что кубелет просто не евиктит когда нужно, но логи кубелета не собираем, и посмотреть как результат тоже, спасибо

в теории 30 минут могут взяться отсюда: 1) первые минут 5-6 (такой дефолт) куб понимает что нода всё, и перевозит от туда поды 2) затем поды по сути будут в статусе terminating на этой ноде 3) cluster-autoscaler возможно осознает что поды помечены на удаление и теперь не учитывает их при подсчетах заполнености ноды, когда считает unneded ноды. Теперь включается таймер --scale-down-unneeded-time (равный 10 минутам по дефолту)) 4) таймер прошел, теперь эта нода считается unneded. Но так как она notready, включается таймер --scale-down-unready-time (20 минут по дефолту) 5) теперь все таймеры отработали и ноду можно уадяять что и происходит получается 5-6 + 10 + 20 = 35-36 минут, плюс погрешность, так и выходит примерно

Проблема в том, что он никто никуда из не везет, и такое чувство, что из хелси ендпоинтов эти роды не убирает (это теория требующая подтверждения) и как следствие если на этой ноле был core-dns, то всемреквесты к нему фейлятся)

ну если нода notReady и если это не statefulset и если там поды какого-нибудь deployment'а то новые реплики будут созданы на других рабочих нодах. Я под перевозом это и имел в виду

Так в том то и дело, что этого не происходит пока года в кластере, новые полы создаются исключительно после удаления нот реди ноды

ну это требует доказательств. Потому что поведение там другое задокументировано + я давно эксплуатирую k8s и да, он делает как я описал (я про первый этап) разумеется у вас могут происходить какие-то проблемы, из-за которых например pod не смог создастя на другой ноде, или другие вещи. Но тем не менее на общую логику это не влияет, то. есть можно говорить что он как минимум стремиться так сделать, но естественно что-то может пойти не так в вашем окружении Замечу что речь не идёт о подах statefulset'а и daemonset'а, их реплики нигде не будут запускаться

Да, я понимаю и сам этого ожидал, в целом есть несколько непонятных проблем которые требуется воспроизвести и покопать в спокойных условиях. Спасибо. Если есть под рукой линк на флоу контроллер менеджера по поводу нотреди нод, то поделись, пожалуйста.

под рукой нет. Но это легко протестить и посмотреть на практике достаточно остановить сервис kubelet, и наблюдать за службой и увидеть что от туда исчезнет endpoint, после того когда нода перешла в статус notReady

Да, займусь)

А точно разные таймеры включаются друг за другом (unneeded и notready)? Я не знаю сам, не смотрел настолько подробно, но у меня время убийства ноды было порядка получаса. Меня устраивало более-менее. Осталось только стсы убрать.

Это просто хаус какой-то!

это просто предположения, детально не проверял

Да, пропустил слово "в теории"