Привет земляк, очень красиво объясняешь. Без ничего лишнего. Удачи в раскрутке канала. ps. Если можешь, сделай видео как развернуть какой нибудь проект с python/php, nginx/apache, mysql/postgre, redis, elasticsearch. Было бы интересно увидеть, на ютубе похожих видео нет на русском языке.
у меня есть пара вопросов. 1. для чего нужны livenessProbe и readnessProbe c одинаковыми конфигами? по идее в таком случае должно хватить только livenessProbe. 2. если у нас deployment с одной репликой, и в нем только readnessProbe, то куда будет направлен траффик когда readnessProbe зафейлится? как если бы количество реплик было 0?
1. livenessProbe - это “индикатор” для перезагрузки Pods, в случае если Probe не сработал. readinessProbe - необходим для того, чтобы предотвратить отправку трафика не неисправные Pods, если Probe не сработала. Если Вы настроите только livenessProbe, и Pod упадет с ошибкой, то неисправный Pod не сможет обрабатывать клиентские запросы, но трафик на него будет продолжать поступать, и часть клиентов получит, к примеру, 500 ошибку, а если Вы добавите и readinessProbe, то неисправный Pod будет временно исключен из Service, и трафик на него попадать не будет, до тех пор, пока Probe не пройдет успешно. 2. Трафик уйдет в никуда. Т.е. трафик дойдет до Service и остановится, так как нету Pods, на который можно отправить трафик. В таком случае клиенты будут получать ошибки, к примеру: failed: Connection refused.
@@BAKAVETS а разве при фейле livenessProbe pod будет считаться готовым принять запрос? Я думал это работает так: livenessProbe зафейлился, помечается как неспособный обработать запрос и убивается
@lex livenessProbe для того, только чтобы перезагрузить Pod, в то время как readinessProbe для того, чтобы предотвратить отправку трафика на неисправный Pod. Если будет настроен только livenessProbe, без readinessProbe, то когда livenessProbe сработает, Service об этом знать не будет и будет продолжать отправлять на него трафик. И клиенты будут получать ошибки, так как необходимо время, чтобы перезагрузить неисправный Pod. Время перезагрузки Pod может быть разное, в зависимости от приложения внутри. И пока Pod перезагружается, Service отправляет трафик на неисправный Pod тоже, а этот Pod ещё не готов принимать трафик, следовательно часть клиентов получат ошибки.
Здравствуйте. Не совсем понял, как вы используете один сервис к разным deployment на этапе readiness probe, ссылающимся на один и тот же label. Насколько я знаю, ReplicaSet не позволит создать большее количество контейнеров, чем указано в манифесте. Буду признателен за разъяснение этого момента.
Приветствую! Service регистрирует pods на основании селектора, те labels, которые указаны в pods. Т.е. даже если Вы создадите просто Pod без Deployment или ReplicaSet и у этого Pod будет label, который указан в качестве селектора для Service, то Service его также к себе зарегестрирует и будет отправлять на него трафик.
согласен. Когда более или менее разобрался и хочешь подтянуть знания эти уроки самое то. Не представляю как люди которые изучают кубернетес с нуля смотрят эти уроки.
уроки по куберу это просто находка
Очень крутые уроки. Спасибо!
Это просто круто!!!! Спасибо большое %)
Очень полезно
Спасибо огромное)
Привет земляк, очень красиво объясняешь. Без ничего лишнего. Удачи в раскрутке канала.
ps. Если можешь, сделай видео как развернуть какой нибудь проект с python/php, nginx/apache, mysql/postgre, redis, elasticsearch. Было бы интересно увидеть, на ютубе похожих видео нет на русском языке.
Привет. Спасибо за идею!
у меня есть пара вопросов.
1. для чего нужны livenessProbe и readnessProbe c одинаковыми конфигами? по идее в таком случае должно хватить только livenessProbe.
2. если у нас deployment с одной репликой, и в нем только readnessProbe, то куда будет направлен траффик когда readnessProbe зафейлится? как если бы количество реплик было 0?
1. livenessProbe - это “индикатор” для перезагрузки Pods, в случае если Probe не сработал. readinessProbe - необходим для того, чтобы предотвратить отправку трафика не неисправные Pods, если Probe не сработала. Если Вы настроите только livenessProbe, и Pod упадет с ошибкой, то неисправный Pod не сможет обрабатывать клиентские запросы, но трафик на него будет продолжать поступать, и часть клиентов получит, к примеру, 500 ошибку, а если Вы добавите и readinessProbe, то неисправный Pod будет временно исключен из Service, и трафик на него попадать не будет, до тех пор, пока Probe не пройдет успешно.
2. Трафик уйдет в никуда. Т.е. трафик дойдет до Service и остановится, так как нету Pods, на который можно отправить трафик. В таком случае клиенты будут получать ошибки, к примеру: failed: Connection refused.
@@BAKAVETS а разве при фейле livenessProbe pod будет считаться готовым принять запрос? Я думал это работает так: livenessProbe зафейлился, помечается как неспособный обработать запрос и убивается
@lex livenessProbe для того, только чтобы перезагрузить Pod, в то время как readinessProbe для того, чтобы предотвратить отправку трафика на неисправный Pod. Если будет настроен только livenessProbe, без readinessProbe, то когда livenessProbe сработает, Service об этом знать не будет и будет продолжать отправлять на него трафик. И клиенты будут получать ошибки, так как необходимо время, чтобы перезагрузить неисправный Pod. Время перезагрузки Pod может быть разное, в зависимости от приложения внутри. И пока Pod перезагружается, Service отправляет трафик на неисправный Pod тоже, а этот Pod ещё не готов принимать трафик, следовательно часть клиентов получат ошибки.
@@BAKAVETS буду знать, спасибо.
Здравствуйте. Не совсем понял, как вы используете один сервис к разным deployment на этапе readiness probe, ссылающимся на один и тот же label. Насколько я знаю, ReplicaSet не позволит создать большее количество контейнеров, чем указано в манифесте. Буду признателен за разъяснение этого момента.
Приветствую! Service регистрирует pods на основании селектора, те labels, которые указаны в pods. Т.е. даже если Вы создадите просто Pod без Deployment или ReplicaSet и у этого Pod будет label, который указан в качестве селектора для Service, то Service его также к себе зарегестрирует и будет отправлять на него трафик.
Понятно что не понятно, ну ничего, раз 10 еще посмотреть и станет понятно
Вот смотрю твои уроки и к концу видео мозг вырубаться начинает. Монтаж дикий! Уроки скорее для людей, уже шарящих в кубере. Уроки полезные бесспорно.
согласен. Когда более или менее разобрался и хочешь подтянуть знания эти уроки самое то. Не представляю как люди которые изучают кубернетес с нуля смотрят эти уроки.
что за терминал такой?)
Терминал: github.com/ohmyzsh/ohmyzsh
Тема к терминалу: github.com/romkatv/powerlevel10k