Наверное. Ну куб поднимает поды... ну, как умеет. На это как-то можно влиять?

Вначале поднимаешь новый, потом убиваешь старый

Так сверху писали же про политику

А зачем учить ретраям все мои приложения, если можно научить какое-то приложение-балансировщик и пускать все через него?

Тут просто вопрос философский. POST запрос может снимать деньги например и автоматичеки его повторив можно снять два раза

Может быть. А как красиво и без велосипедов сделать, чтобы вот есть у меня 3 приложения-api, ну и там сайт, еще мобильные всякие клиенты у этих апи. И надо вполне типичные вещи: если умер инстанс приложения (авария или деплой новой версии не суть) - чтоб балансер сам переотправил запрос, дабы клиенты не видели никаких 500ых вообще, чтобы балансировать при необходимости с весами можно было... сущность сервиса сама по себе так круто не умеет. А использовать ингресс для взаимодействия приложений внутри кластера выглядит странным, имхо тоже велосипедный костыль. Но может я неправ?

т.е. ты хочешь написать свой ингресс-контроллер, существующие ты использовать не хочешь. ну окай. а при чем тут извращения с сервисами kubernetes и coredns ?

где-то можно посмотреть предыдущий generation объекта?

Т.к гонять весь трафик кластера через 1 общий ингресс ну еще более дурацкая схема

а мужики то не знают... и все так делают

А каждому приложению свой LB разве нормальная cхема?

Т.е это реально нормальная практика и многие так делают? Однако...

Мы пока с ретраями не заморачивались, у нас на каждой ноде по ингрессу, перед кластером стоит внешний LB который перенаправляет трафик на эти ингрессы

излишне ))) достаточно двух подов на разных нодах. зачем на всех то ,

иметь один ингресс контроллер на кластер - это нормально. сервисы работают на уровне NAT TCP UDP - им до твоих http ошибок нет никакого дела. ингресс-контроллеры как раз на уровне протокола http работают - там ты свои хотелки по ретраю и прочему и можешь реализовать. но опять же - ингресс-контроллеры обычно трафик отправляют или сразу в сервис, или берут у сервиса текущий список endpoint и ингресс-контроллеры не занимаются ерундой типа livnes-ready проб пода

Ну т.е ты хочешь сказать, что те правила iptables, которые создает service - это хорошая балансировка и большего не нужно? А я считаю что мне - нужно, и ищу это самое "большее". Но нафиг гонять вообще весь трафик через 1 под ингресса я абсолютно не понимаю, мне туда 100гбит порты что ли ставить?

излишне ))) достаточно двух подов на разных нодах. зачем на всех то ,

а если трафик большой купи услугу балансировки у кого-нить

Почему до куба я мог спокойно поставить nginx, за ним несколько копий приложения, и все было прекрасно, а в кубе оказывается надо в 1 гигантский nginx или что-то аналогичное загнать весь трафик. Да у меня в проде тогда одних открытых коннектов к нему будет десятки тысяч!

Ну т.е ты хочешь сказать, что те правила iptables, которые создает service - это хорошая балансировка и большего не нужно? А я считаю что мне - нужно, и ищу это самое "большее". Но нафиг гонять вообще весь трафик через 1 под ингресса я абсолютно не понимаю, мне туда 100гбит порты что ли ставить?

поставь свой любимый nginx перед кластером

Почему до куба я мог спокойно поставить nginx, за ним несколько копий приложения, и все было прекрасно, а в кубе оказывается надо в 1 гигантский nginx или что-то аналогичное загнать весь трафик. Да у меня в проде тогда одних открытых коннектов к нему будет десятки тысяч!

Почему до куба я мог спокойно поставить nginx, за ним несколько копий приложения, и все было прекрасно, а в кубе оказывается надо в 1 гигантский nginx или что-то аналогичное загнать весь трафик. Да у меня в проде тогда одних открытых коннектов к нему будет десятки тысяч!

Запусти несколько ингресс-контроллеров, в чем проблема то?

Господи, да зачем мне еще и перед кластером городить что-то, ребят, вы вообще о чем?! Речь началась с нормальной балансировки трафика к приложениям, внутри куба, а вы мне предлагаете какие-то внешние черте-что

Трафик от приложения к приложению или от внешних клиентов? Если первое, то нужен сервис меш. Если второе, то нужен ингресс.

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

когда запущено N подов одного ингресс-контроллера

Трафик от приложения к приложению или от внешних клиентов? Если первое, то нужен сервис меш. Если второе, то нужен ингресс.

Трафик от приложения к приложению или от внешних клиентов? Если первое, то нужен сервис меш. Если второе, то нужен ингресс.

Я деплою приложение в куб. Я даю туда трафик. Я обновляю приложение и вижу несколько обломанных коннектов во время деплоя. Я понимаю, что это потому, что правила iptables запаздывают. Я пробую вместо iptables использовать приложение-балансировщик, специально созданное для этого. Что тут не так?

ну, несколько обломанных коннектов - во-первых, это несущественная проблема

Я деплою приложение в куб. Я даю туда трафик. Я обновляю приложение и вижу несколько обломанных коннектов во время деплоя. Я понимаю, что это потому, что правила iptables запаздывают. Я пробую вместо iptables использовать приложение-балансировщик, специально созданное для этого. Что тут не так?

могут быть разные кейсы. Я могу представить себе кейс мультитенантного кластера, в котором физически несколько ингрессов

Для меня существенная. Отсюда и все телодвижения

>вместо iptables использовать приложение-балансировщик вот эта часть, например

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

retry семантику твои приложения не умеют? если нет, то у тебя большие проблемы вне зависимости от файрволла и балансировки

Ну эти приложения есть, есть давно и они много чего умеют. Почему вдруг iptables стал лучше них?

Нет, не умеют. И переписывать это очевидно бизнес не хочет, иначе б переписали и все

Ну эти приложения есть, есть давно и они много чего умеют. Почему вдруг iptables стал лучше них?

т.е. ты говеное легаси засунул в кубер?

Добрый день, коллеги. Имеется k8s deployment у которого настроен horizontal pod autoscaler, необходимо реализовать graceful shutdown. Для общего понимания скажу, что данный deployment представляет из себя приложение которое из очереди задачу и обрабатывает (таск раннер/воркер). Вся проблема в том, что задачи могут выполняться достаточно долго, например, час (импорт большего объема данный со сторонних ресурсов, наример). ПРЕДПОЛАГАЕМОЕ РЕШЕНИЕ: установить terminationGracePeriodSeconds в 10800 (3 часа), в приложение по сигналу SIGTERM остановить подписку на сообщения, доделать работу и выйти. ВОПРОС: Есть ли какие-либо подводные камни в указании большого значения terminationGracePeriodSeconds?

Добрый день, коллеги. Имеется k8s deployment у которого настроен horizontal pod autoscaler, необходимо реализовать graceful shutdown. Для общего понимания скажу, что данный deployment представляет из себя приложение которое из очереди задачу и обрабатывает (таск раннер/воркер). Вся проблема в том, что задачи могут выполняться достаточно долго, например, час (импорт большего объема данный со сторонних ресурсов, наример). ПРЕДПОЛАГАЕМОЕ РЕШЕНИЕ: установить terminationGracePeriodSeconds в 10800 (3 часа), в приложение по сигналу SIGTERM остановить подписку на сообщения, доделать работу и выйти. ВОПРОС: Есть ли какие-либо подводные камни в указании большого значения terminationGracePeriodSeconds?

iptables не стал лучше. тебе говорят что то что ты хочешь сделать называется ingress controller и iptables в данном случае никак не сможет тебе помочь

Окей, значит буду прикручивать ингресс. У меня до сих было четкое понимание, что ингресс для выхода трафика, а не чтоб внутри куба на него заворачивать взаимодействие между приложениями

Окей, значит буду прикручивать ингресс. У меня до сих было четкое понимание, что ингресс для выхода трафика, а не чтоб внутри куба на него заворачивать взаимодействие между приложениями

https://kubernetes.io/docs/concepts/workloads/pods/pod/#termination-of-pods https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#hook-details тебе нужен PreStop hook

ингресс для балансировки http. если твои сервисы не соблюдают принципы микросервисности, когда общение идет через одну точку входа в API и общаются между собой напрямую, и при этом не умеют ретрай и прочее. то можешь для только для них поднять отдельный дополнительный ингресс-контроллер, который в интернет трочать не будет

и что так грубо? вот реально задача ынтерпрайза - отдельные ингрессы для разных тенантов. Как будешь решать?

А еще днс вдогонку, кубовый встроенный не поможет