Oleksandr
кроде как классика и из коробки https://www.nginx.com/resources/admin-guide/http-health-check/
Pavel
задача работаь с Layer 4 (TCP/UDP), nginx точно не про это
Oleksandr
haproxy
Sergey
он как раз для балансировки l4
Pavel
чекнул, да, работает, но проксировать запросы между сервисами через nginx изврат же? разве нет? особенно когда есть kube-proxy
Sergey
это всего лишь один из методов
Pavel
согласен, у меня был вопрос насколько пригоден kube-proxy для продакшена, если нет, то искать что-то другое
Sergey
кубе-прокси - это все же про связь внутри кубернетс кластера
Sergey
длс сервисов
Sergey
https://kubernetes.io/docs/admin/kube-proxy/
Pavel
меня это и интересует
Sergey
есть вариант kube-router
Sergey
там ipvs
Sergey
из коробки
Sergey
да и его поддержка есть в альфа в 1,8 версии
Sergey
я бы ореинтировался на него
Pavel
видел, но это альфа :(
Sergey
есть отдельный проект kube-router
Sergey
он давно не альфа
Sergey
https://github.com/cloudnativelabs/kube-router
Sergey
kops его умеет дэплоить
Pavel
ок, чекну что за зверь, спасибо
Sergey
нет за что
G72K
Понятно что медленнее, но интересует возможность kube-proxy на-лету детектить недоступные поды и направлять запросы на доступные (если есть).
itsio вроде умеет такое, пофичастей будет
G72K
Привет, кто нибудь свои репы для хелм чартов поддерживает? Как это вообще выглядит?
Мы запилили плагин, который качает зависимости из гита напрямую. Че за фигня вообще тарболы публиковать
Denis
Мы запилили плагин, который качает зависимости из гита напрямую. Че за фигня вообще тарболы публиковать
С указанием бранча и коммита?
Denis
Если так звучит круто
Sergey
Понятно что медленнее, но интересует возможность kube-proxy на-лету детектить недоступные поды и направлять запросы на доступные (если есть).
так это один из кейсов, кубер отслеживает неработающие поды в сервисе и выкидывает их
Sergey
там даже есть ручки для хелчеков
Denis
Sergey
и таймауты
G72K
кто будет прописывать IP подов в nginx и обновлять этот список?
Nginx ingress controller , если все сервисы будут ходить через него. Но это неудобно и криво
Anonymous
Там кстати opentracing запилили, удобнл
G72K
Не опенсорсили случайно?
Да че там, читать ямл, git clone —branch <tag/branch/commitid> charts/<dependency name>. Повторять рекурсивно
Denis
Так то да )
Sergei
насколько быстрее? интересует чтоб вообще без потерь. proxy-mode: userspace не пробовали?
не надо ломать семантику
то что вы хотите - это энвой/истио
Pavel
так это один из кейсов, кубер отслеживает неработающие поды в сервисе и выкидывает их
это, да, но интересует чтоб вообще без потерь
Sergey
что значит без потерь?
Pavel
на то чтобы под убрать под нужно время, ну или ставить ливнес чеки с таймаутом 1с
Sergey
так у вас потери будут которые успеют попасть в промежуток 1с
bebebe
https://www.youtube.com/watch?v=yQvcHy_tPjI
Sergey
но тогда будет веселуха с флапанием кратковременным
G72K
на то чтобы под убрать под нужно время, ну или ставить ливнес чеки с таймаутом 1с
Вы от краха защититься хотите или что?
Sergey
вообще вы можете свое приложение научить дрегнуть куб апи и спросить кто там живой и ходить на живой под прям на прямую
Sergey
но это лэтенси
Sergey
ставишь кеширование - вопрос валидации кеша
Sergey
короче поебаться и девственницей остаться не получится
Pavel
Вы от краха защититься хотите или что?
чтобы при падении нода к кластере был минимальны простой в работе аппе при условии что реплики сервисов есть на других нодах
Anonymous
Ну в плане так тоже бывает
Sergey
чтобы при падении нода к кластере был минимальны простой в работе аппе при условии что реплики сервисов есть на других нодах
у вас будут не 100% потери, а только с теми, кто обслуживался на этой ноде
bebebe
Можно текстом что там?
haproxy из 10к запросов потеряла 86 когда бекенды падали
nginx при таких же вводных потерял 0 пакетов
Sergey
чтобы при падении нода к кластере был минимальны простой в работе аппе при условии что реплики сервисов есть на других нодах
и у вас же не лайв стриминг, так что падение еще сильнее будет сглаживаться тем фактом, что на момент падения не все слиенты запрашивают данные
Pavel
у вас будут не 100% потери, а только с теми, кто обслуживался на этой ноде
да, задача минимизировать эти потери
самое простое это, видимо, ливнес чек с минимальным таймаутом
Sergey
да, задача минимизировать эти потери
самое простое это, видимо, ливнес чек с минимальным таймаутом
сильно мелкий таймаут - это постоянные флапания
bebebe
да, задача минимизировать эти потери
самое простое это, видимо, ливнес чек с минимальным таймаутом
Павел при всем уважении к вам и вашей экспертизе, может уже посмотрите в сторону nginx/istio?
Sergey
только немного пришла нагрузка, чек не сразу ответил, кубер посчитал что все, убил этот под апнул новый
bebebe
вам тут не однократно это предлагают
Sergey
а то, что этот под кого-то обслуживал ему покую
Sergey
Павел при всем уважении к вам и вашей экспертизе, может уже посмотрите в сторону nginx/istio?
не решит проблему времени реакции системы на событие
Sergey
оно не может быть мнгновенным
Pavel
Sergey
помимо систем сервай-меш, еще нужно как можно больше подов в сервисе, что бы процент клиентов при падении снизить
bebebe
@p8sih ^^^^
bebebe
https://www.youtube.com/watch?v=yQvcHy_tPjI
Anonymous
А istio еще в альфе
Sergey
но горизонтальное маштабирование - дело тоже не бесконечное
Etki
чтобы при падении нода к кластере был минимальны простой в работе аппе при условии что реплики сервисов есть на других нодах
у вас приложение должно затачиваться под неустойчивое окружение (и быть готовым в случае чего повторять запросы, а также регулярно забирать из DNS полный пул бэкендов), а не имитировать стопроцентную устойчивость окружения
Sergey
я вообще за клиент-сайд сервис дискавери
Sergey
пошел в систему сервис дискавери спросил кто жив
Sergey
получил ответ - ушел за данными
Etki
если вы серьезно теряете в деньгах при таких простоях, то у вас здесь особого выбора нет, и нужно пилить устойчивое к такой штуке приложение, если же не теряете, то для вас разницы между секундой и пятью не будет