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