Как стать автором
Обновить

Лучшие практики для контейнеров Kubernetes: проверки работоспособности

Время на прочтение 7 мин
Количество просмотров 8.5K
Всего голосов 26: ↑24 и ↓2 +22
Комментарии 8

Комментарии 8

readinesProbe? Даже мне это проверка правописания подчеркивает. Не торопитесь, пожалуйста, выкладывать перевод, а лучше дайте корректуру на прочтение.

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

Да, обидно, спасибо — статья-то полезная. Покажу своим младшим коллегам, как руководство к действию )))

Вот есть, допустим, образ с апп-сервером со сложной логикой, которому нужна РСУБД. Какие лучше практики использовать для проб? Должны ли этих ендпоинтах происходить конннкты к базе, запросы исполняться?


И что будет делать кластер, если все контейнеры репликсета фейлят readyness?

А сейчас, без кубернетеса — как проверяете работоспособность сервера?
Наверняка, сделаны отдельные проверки на рсубд и на сервер приложений?
Насчёт делать сложные проверки — вряд ли они нужны. У вас все равно должен быть балансировщик и circuit breaker перед апп-сервером. И если база уйдет, то АПП сервер начнет сыпать ошибками и будет выключен из балансировки. Вопрос в том — как определить, что все нормализовалось.
Выглядит так, будто очень легко при неверной настройке получить каскадный отказ всех компонентов по цепочке прохождения запроса. Да даже и при верной настройке все равно можно получить такой эффект. Как бы чудес нет ( и кубернетес не сделает хорошо сам по себе.
Мы с этим уже столкнулись и появилось понимание, что нужно именно дорабатывать приложения. Причем иногда — значительно

Должны ли этих ендпоинтах происходить конннкты к базе, запросы исполняться?

В базу ломиться не нужно, этот механизм о том, что под работает как надо. Маловероятно, что перезапуск пода решит проблему коннекта к базе, надо разбираться или с базой, или с сетью. Это можно проверять в readinessProbe, тогда избежим битого конфига или чего-то подобного.

И что будет делать кластер, если все контейнеры репликсета фейлят readyness?

Зависит от того, что вы делали. Если это ReplicaSet, то поды просто будут фелйиться, сервис будет недоступен. Не нужно пользоваться ReplicaSet в сыром виде, надо использовать Deployment-ы. Деплойменту настраиваете, как он обновляется в rollingUpdate и при обновлении у вас не будет недоступности вашего сервиса. Если новый образ фейлится при запуске, то старые поды будут работать, а новые будут фейлиться. Если хотите, чтобы оно откатывалось автоматом, то нужно использовать, например, helm, а в нём прописать условия того, что релиз прошёл успешно и запускать с флагом --atomic. Ну и естественно надо следить за обратной совместимостью (либо забить на неё). Самое сложное — мигрировать базу так, чтобы хотя бы 2-3 последовательных версии работали с ней нормально (ну, на это, конечно, тоже можно забить, но тогда надо знать, что между вот этими 2 релизами откатываться нельзя)

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

Спасибо, понял: если есть смысл контейнер перезапустить, то фэйлим. В случае апп-сервера скорее всего надо просто ОК отдавать, показывая что штуки типа фронт-контроллера и роутинга работают.


Самое сложное — мигрировать базу так, чтобы хотя бы 2-3 последовательных версии работали с ней нормально (ну, на это, конечно, тоже можно забить, но тогда надо знать, что между вот этими 2 релизами откатываться нельзя)

Ну это и без кластеров с докерами надо делать, если стремиться к zero time deployment или возможность отката.

В случае апп-сервера скорее всего надо просто ОК отдавать, показывая что штуки типа фронт-контроллера и роутинга работают.

Зависит от того сколько инстансов апп-сервера будет. Если он в HA конфе, то, конечно, НАДО отдавать код ошибки, чтобы входящий ЛБ перенаправил трафик на следующий инстанс АПП-сервера, который, ВОЗМОЖНО, еще жив.

Зарегистрируйтесь на Хабре , чтобы оставить комментарий