Всем привет, юзаю eks с NLB(ip target), вижу проблему что

когда поды котнроллера пересоздаются, то ощутимо долго переходят со статуса initial в статус healthy в target group, в какой-то момент попадаю в ситуацию что тупо живых таргетов нет и получаю дайнтайм, на просторах интернета нашел такое решение(https://aws.github.io/aws-eks-best-practices/networking/loadbalancing/loadbalancing/#utilize-pod-readiness-gates), но оно имеет сайдефект - длительность обновления подов, что также приведет к даунтайму если например спот будет отъезжять
как это можно побороть? как я понимаю такой проблемы нет на типе таргетов instance, но не хотелось бы его юзать

используй RollingUpdateStrategy где максимальне количество недоступных подов = 1 Также можно добавить postStart чтобы он не переходил к следующему поду пока postStart не завершится Можно даже упорототься и в postStart добавить скрипт который проверяет доступен ли таргет в балансировщике

preStop не имеет такого sideffect'а, если pod помеяается на удаление, то он удаляется из endpoints асинхронно, независимо от ого что там происходит в preStop

а не проблема-ли в самом механизме хелсчека target group? а то поды по факту у меня быстро ролятся, но traget group видит их спустя минуты 2-3, дичь

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

>спустя две минуты хелсчеки проходят по этим таргетам

в самих таргетах они еще быстро появляются, новые реплики

Ты про таргеты лоадюалансера?

ну скорее таргет группы, на которые смотрит NLB

более умно это как?😄

https://t.me/ru_devops/232823

а как это поможет на стороне балансера то ?

> [...] the AWS Load Balancer controller can set the readiness condition on the pods that constitute your ingress or service backend. The condition status on a pod will be set to True only when the corresponding target in the ALB/NLB target group shows a health state of »Healthy«. This prevents the rolling update of a deployment from terminating old pods until the newly created pods are »Healthy« in the ALB/NLB target group and ready to take traffic. Так там же уже умно он умеет про сайд эффект непонятно, но ваще крутить L7 балансировщик на спотах как по мне ССЗБ

https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.5/deploy/pod_readiness_gate/ та я вот читаю статью, это из разряда по умному, но переживаю как оно себя будет вести при отъездах спотов

ну допустим на спотах, не очень понмаю как это влияет, spot отезжает, соотвественно из endpoins выкидываются все адреса которые были на этом споте, соотвественно оно выкидывается из nlb

ну оно ж всё равно будет пытаться дожидаться новые реплики, пока они не станут healthy то есть условно 3 минуты раздупляется, 2 минуты чтоб таргеты стали хелси перед тем как спот уедет, спот отъезжяет опять пересоздание таргетов и опять ждать и при этом может быть ситуация что вообще не останется здоровых таргетов в моменте

не совсем понимаю, у тебя все споты одновременно отъезжают что-ли? Или у тебя одна реплика ingress контроллера на одном споте?

ну смотри, 3 тачки сейчас, хоба и амазон внезапно захотел 2 тачки отнять понятно что можно 3 реплики сделать вместо двух, но тем не менее)))

Это уже твои проблемы и риски же

ну если у тебя две тачки забираются одновременно и на этих двух тачках все реплики ingress controller'а, то логично что ты получаешь даунтайм независимо от настроек

ну вот я хотел узнать решает-ли такой кейс эта фича kubectl label namespace readiness elbv2.k8s.aws/pod-readiness-gate-inject=enabled

так blue/green же, не должно, если не момент с nlb target group

aws забирает споты по blue/green?

высиление подов идет, и реплики в кубе по очереди создаются

ну у тебя идет выселение подов на двух нодах одноврменно в кейсе

да но ведь параллельно старая реплика работает до тех пор пока новая не будет готова тут вся боль больше из-за target group, так бы даже не парился

при drain, deployment разве не начинает создавать новые реплики? шото я может упустил

ну начнинает, но у тебя же одновременно уничтожаются все поды

так если не проблема traget group с NLB, я ж по идее не заметил бы даже даунтайма то есть при обычном сценарии при drain создаются параллеьно новые екземпляры подов контроллера, параллельно старые работают до тех пор пока новые не станут Running но в случае когда появляется traget group я получаю даунтайм так или иначе, да

при обычном сценарии удаления всех подов: у тебя нет никакой гарантии того что новые экземпляры создадутся раньше удаления подов и их endpoints. Обычный сценарий это роллинг апдейт, вот в нем есть определенные гарантии

а, теперь понял