да, на уровне аппа понятно как решать, но аппом мы не управляем :(

https://www.youtube.com/watch?v=yQvcHy_tPjI

проксирование, при падении ноды, прокси держит клиента и перенаправляет запрос на другую ноду, соответственно растет время ответа

а допустим у меня директ респонс

)

а допустим у меня директ респонс

я не до конца улавливаю вашу мысль, впрочем может и к лучшему

методы балансировки

один из них директ-респонс

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

возможно по этому и не улавливаю

да в любом случае балансировщиком не все решается, если условный SQL пркосировать, то от падения посередине транзакции ничего не спасет, все равно придется повторять запрос с самого начала

да в любом случае балансировщиком не все решается, если условный SQL пркосировать, то от падения посередине транзакции ничего не спасет, все равно придется повторять запрос с самого начала

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

https://www.youtube.com/watch?v=yQvcHy_tPjI

вот честно, всегда было странно видеть -c 200, ну похорошему его ест смысл выставлять равным хотя бы по количество ядер у тебя на машине

видимо в ваших и их тестах преследовались разные задачи

впрочем, задайте вопрос автору

ну то так мысли в слух были, я уже ко всему этому философски отношусь

вот честно, всегда было странно видеть -c 200, ну похорошему его ест смысл выставлять равным хотя бы по количество ядер у тебя на машине

Почему?

есть ойти-архитекты, ойти-девелоперы, ойти-qa, ойти-деплоймент-инженеры, ойти-девопсы и прочее пора уже вводить ойти-философы

Почему?

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

плюс я в том видео не увидел на каких конфигах работает нгинкс и хапрокси, нгринкс по дефолту чекает порт бэкенда, жив он или нет, а вот хапрокси я тупо не помню, чекаит ли он что-то по дефолту)

Ну так это же не параллельная обработка

Там нет треда, который что-то считает до того момента, пока запрос не вернулся назад

плюс я в том видео не увидел на каких конфигах работает нгинкс и хапрокси, нгринкс по дефолту чекает порт бэкенда, жив он или нет, а вот хапрокси я тупо не помню, чекаит ли он что-то по дефолту)

думаю чек в хапрокси точно присутствует

Там нет треда, который что-то считает до того момента, пока запрос не вернулся назад

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

там в описании конфиги

там в видосике

frontend http bind *:80 mode http default_backend web-backend backend web-backend balance roundrobin mode http server web1 22.22.22.2:3000 check server web2 22.22.22.3:3000 check server web3 22.22.22.5:3000 check

да вижу в описании

спасибо

яндекс танк иожет 100к в секунду )

заявлено

да слышал, опять же на какой машине

)

обычный десктоп

вот у меня в инфре есть машины под сотню ядер и пол тера памяти

на ней 100к - это вообще неочем

)

у меня, я бомбитл, раскручивал до 10к

сетевка норм у тебя была?

обычный гигабит

https://github.com/yandex/yandex-tank

ну я апачом не пользовалься, а танк порекомендую

у нас ребята свои модули нгинкса им тестили

как раз на той тачке что я написал выше)

да и опять же к тому видео, таймауты, на сколько я помню в хапрокси их дофига, и какие там по дефолту есть с каким временем

у нгинкса вроде по дефолту чекается каждые 5 секунд порт бэкенда

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

Как балансировщик должен знать, это упало или запрос долгий? Что делать с запросамии в процессе обратки? Не поучится защититься в общем случае

у нгинкса вроде по дефолту чекается каждые 5 секунд порт бэкенда

у нджинкса по дефолту НИЧЕГО не чекается

wrk еще крутой тул. ab это детский сад.

wrk по перфомансу на уровне нжинкс

привет! никто не натыкался на best practices по http health checks?

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

возвращать большое тело ответа нет смысла разве что. плюс использовать коды 20х/503. но это вроде и так само по себе понятно.

возвращать большое тело ответа нет смысла разве что. плюс использовать коды 20х/503. но это вроде и так само по себе понятно.

у меня тела ответов вообще ппустые..все данные тупо в заголовке.200 код все ок 503- контейнер умер, надо перезапускать

Всё равно Куебр тело не читает как я понял

возвращать большое тело ответа нет смысла разве что. плюс использовать коды 20х/503. но это вроде и так само по себе понятно.

ну так и делаю. а проверяете все зависимости контейнера? базы/шмазы? зависящие контейнеры?

нет, это всё не имеет отношения к здоровью сервиса

точнее, это все не имеет отношения к здоровью конкретного процесса и к необходимости его перезапускать

ну так и делаю. а проверяете все зависимости контейнера? базы/шмазы? зависящие контейнеры?

За это отвчается вторая проверка readness chk

У кубера две проверки

1. Проверка жизни самого контейнера,

2. Проверка, а может ли он обрабатывать траффик

при фейле на первой, конейтер перезапускается

при фейле на второй под выводится из сервиса.

если заморочиться, можно в своём приложении хэндлер написать, который проверяет нужные вещи: например что кэши некие прогреты для readinessProbe

этого не следует делать

хозяин барин:)

у нас например в readiness проверяется, что приложение подключилось ко всем нужным бд и встало в кластер своих товарищей

+

этого не следует делать

Почему?

Почему?

у меня есть глубокая уверенность в том, что если приложение запущенное в поде каким-либо образом контактирует с k8s api и проверяет стейты - это означает что где-то на этапе проектирования была допущена ошибка

почему же?

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

это должен разруливать сам k8s

и тем более туда не лазить

я не против такой практики - но на мой взгляд это явный признак того, что-то где-то в начале не доглядели, или где-то сам k8s не очень

k8s может разрулить то лько то что ниходит в нём

и досточно кластеризрованно

а если у тебя есть коннект к внешней БД?

как k8s это разрлуит?

вариант. у тебя приложение допусти 8 подов