Ребят, накиньте идей. Проблема следующая: В яндекс облаке есть ограничение на одну

вмку - 50 000 коннектов
Поэтому я реализовал следующую схему, для nginx ingress controller использую отдельные группы нод(с автоскейлингом) на них теинт, а на подах nginx ingress controller толерейшон и required anti affinity. Если по простому, то на каждую ноду шедулится по одному ingress controller.

HPA натравлен на метрику network_connections_quota_utilization. А точнее на максимальное ее значение из всех нод, на которых зашедулены поды ingress controller. Делаю именно максимальное, а не среднее, поскольку nlb неравномерно распределяет соединения, и легко может случится такое, что один контроллер почти забит коннектами, а другой свободен.

В целом это работает, HPA увеличивает реплику, автоскейлер поднимает новые ноды, туда шелулятся ingress-controller'ы. Они принимают новые коннекты, и утилизация коннектов падает по всем нодам.

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

И вот я думаю, как с таким справится. По идее хотелось бы убить/перезапустить такой pod (ну или сделать релоад конфигурации, nginx же внутри). Придется писать какую-то автоматизацию, которая смотрит метрики, и если конкретный под контроллера продолжает наращивать коннекты, убивать его или создавать фейковый ingress для перегрузки конфигурации. Это бредовая затея, как думаете? Кто как с таким справляется?

Не совсем в тему/немного в тему. А ты ведь node-local-dns на всех нодах используешь?

ага, правда там iptables мод. Так как calico в яндексе. То есть у меня не в kubelet прописан адрес DNS node-local-dns, а через iptables он там магически подменяется. Ну коннекты все вроде с nginx там # nsenter -n -t 20821 # ss -apnt | grep '10.240.150.4:443' | awk '{ print $5 }' | cut -d: -f1 | sort | uniq | wc -l 31696 # ss -apnt | grep '10.240.150.4:443' -v | awk '{ print $5 }' | cut -d: -f1 | sort | uniq | wc -l 9 # ss -aupn | wc -l 1 То есть почти все коннекты с 443 портом. Да и nginx вряд-ли обильно в DNS ходит (ну это и не видно)

И вот я не вижу путей, кроме как думать как боротся с такими вещами, убивая такие поды автоматически или делая релоад конфигурации

только не на одну вмку ограничение - а на один интерфейс, вот здесь https://t.me/linkmeup_podcast/5490 мне ясно дали понять, что это вообще редкий случай, и это норма я решил пойти следующим спопсобом - убрал нахер их нлб говняный, ставлю алб л4 режиме (правада сюприз, там нет прокси протокола, но для меня это не проблема, так как выше стоит ваф и второй сюприз -между алб и ваф все равно стоит нлб, такая архитектура), и поднял несколько небольших нод ингрессами (в моем случае пока 4х хвататет 2 цпу 4 рам) и таким образом стало более-менее равномерно распределяться количесвто сессий, потому что теперь трафик балансится не только по tuple5 (nlb) но и по RR

Danya
Господи один график красивее другого

ну до кацусика хокусай этим графикам очень далеко =)

а у них алб умеет брать tls сертификаты из куба? Или ты деплоешь какой-то их контроллер, который по type: Service alb создает?

алб в режиме л4 - там нет сертов

а, проглядел

у тебя секьюрити групп есть в кубе?

Сори за тупой вопрос Но я не понял если у тебя waf => nlb L4=> alb L4 => pod'ы контроллера L7 => поды приложений То по идее у тебя до подов контроллера, все равно будет tuple5, не?

waf => nlb L4 (tuple5)=> alb L4 (RR) =>ingress controller (RR)=> pod'ы

а понял. Потому что alb более умный, поэтому там RR. Но при этом все равно L4

А как ты alb в режим L4 переключил? Там вроде нет такого - https://registry.terraform.io/providers/yandex-cloud/yandex/latest/docs/resources/alb_load_balancer сори за тупые вопросы =)

У них оно сейчас только через кли

ааа, понял. Пасибо =)