13 - Liveness и Readiness Probes в Kubernetes

[@1984Nik1]

уроки по куберу это просто находка

[@MegaHacker342]

Очень крутые уроки. Спасибо!

[@igorgladkov8270]

Это просто круто!!!! Спасибо большое %)

[@imabouttobe]

Очень полезно Спасибо огромное)

[@_bzk]

Привет земляк, очень красиво объясняешь. Без ничего лишнего. Удачи в раскрутке канала. ps. Если можешь, сделай видео как развернуть какой нибудь проект с python/php, nginx/apache, mysql/postgre, redis, elasticsearch. Было бы интересно увидеть, на ютубе похожих видео нет на русском языке.

[@BAKAVETS]

Привет. Спасибо за идею!

[@lexxx1994]

у меня есть пара вопросов. 1. для чего нужны livenessProbe и readnessProbe c одинаковыми конфигами? по идее в таком случае должно хватить только livenessProbe. 2. если у нас deployment с одной репликой, и в нем только readnessProbe, то куда будет направлен траффик когда readnessProbe зафейлится? как если бы количество реплик было 0?

[@BAKAVETS]

1. livenessProbe - это “индикатор” для перезагрузки Pods, в случае если Probe не сработал. readinessProbe - необходим для того, чтобы предотвратить отправку трафика не неисправные Pods, если Probe не сработала. Если Вы настроите только livenessProbe, и Pod упадет с ошибкой, то неисправный Pod не сможет обрабатывать клиентские запросы, но трафик на него будет продолжать поступать, и часть клиентов получит, к примеру, 500 ошибку, а если Вы добавите и readinessProbe, то неисправный Pod будет временно исключен из Service, и трафик на него попадать не будет, до тех пор, пока Probe не пройдет успешно. 2. Трафик уйдет в никуда. Т.е. трафик дойдет до Service и остановится, так как нету Pods, на который можно отправить трафик. В таком случае клиенты будут получать ошибки, к примеру: failed: Connection refused.

[@lexxx1994]

@@BAKAVETS а разве при фейле livenessProbe pod будет считаться готовым принять запрос? Я думал это работает так: livenessProbe зафейлился, помечается как неспособный обработать запрос и убивается

[@BAKAVETS]

@lex livenessProbe для того, только чтобы перезагрузить Pod, в то время как readinessProbe для того, чтобы предотвратить отправку трафика на неисправный Pod. Если будет настроен только livenessProbe, без readinessProbe, то когда livenessProbe сработает, Service об этом знать не будет и будет продолжать отправлять на него трафик. И клиенты будут получать ошибки, так как необходимо время, чтобы перезагрузить неисправный Pod. Время перезагрузки Pod может быть разное, в зависимости от приложения внутри. И пока Pod перезагружается, Service отправляет трафик на неисправный Pod тоже, а этот Pod ещё не готов принимать трафик, следовательно часть клиентов получат ошибки.

[@lexxx1994]

@@BAKAVETS буду знать, спасибо.

[@pidumenk]

Здравствуйте. Не совсем понял, как вы используете один сервис к разным deployment на этапе readiness probe, ссылающимся на один и тот же label. Насколько я знаю, ReplicaSet не позволит создать большее количество контейнеров, чем указано в манифесте. Буду признателен за разъяснение этого момента.

[@BAKAVETS]

Приветствую! Service регистрирует pods на основании селектора, те labels, которые указаны в pods. Т.е. даже если Вы создадите просто Pod без Deployment или ReplicaSet и у этого Pod будет label, который указан в качестве селектора для Service, то Service его также к себе зарегестрирует и будет отправлять на него трафик.

[@neophron197]

Понятно что не понятно, ну ничего, раз 10 еще посмотреть и станет понятно

[@Tikhon_FaiR]

что за терминал такой?)

[@BAKAVETS]

Терминал: github.com/ohmyzsh/ohmyzsh Тема к терминалу: github.com/romkatv/powerlevel10k

[@БугорБугров-м1х]

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

[@dmitryshweikus]

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