Kubernetes Headless Service: А если Pod исчез?

[Sovigod]

задержки/Delay/Sleep это все таки костыли. Неочевидные и не понятные. Я вот такие прокси (mongos/haproxy/envoy) добавляю как sidecar контейнер к поду. Заодно исчезает проблема дополнительной задержки, когда приложение и прокси находятся на разных нодах.

[Bozaro]

Использовать mongos как sidecar - рабочая конфигурация.

Но у неё есть свои недостатки:

• Pod должен иметь доступ к keyfile mongos-а, а эти реквизиты надо как-то предоставить mongos-у и они дают полный доступ к mongod;

• mongos далеко не бесплатный: он активно ест CPU на старте и RAM в процессе работы. Причем, что особо печально, количество ресурсов зависит от размера кластера. В нашем случае были прецеденты, когда более 2/3 ресурсов Pod-а выделялось сугубо под mongos-ы;

• приложение должно ждать, пока mongos запустится;

• время старта mongos-а может драматически увеличиваться, если какие-то ноды mongod недоступны;

• если селить mongos в отдельный контейнер, то тяжело выставить ресурсы всех контейнеров, чтобы нормально работал HPA. Особенно если кластеров MongoDB более одного.

Из плюсов такой конфигурации:

• более низкое latency при доступе к базе.

У нас сейчас используются оба варианта выкатки mongos-ов: и в пулах, и в sidecar-ах. И мы плавно мигрируем к варианту с пулами.

[Bozaro]

Я не упомянул основную проблему, которая пока держит нас от того, чтобы полностью отказаться от использования mongos в sidecar-ах в пользу отдельных сервисов: некоторые клиентские библиотеки для работы с MongoDB крайне плохо работают, когда список mongos-ов меняется в процессе работы.

Для примера:

• сейчас mongos при завершении работы просто закрывает все клиентские соединения. Исправиться это должно только с MongoDB версии 5.0: https://docs.mongodb.com/v5.0/release-notes/5.0/#quiesce-period

• некоторые клиенты долго держали соединения до mongos и при добавлении новых Pod-ов нагрузка на них перетекала очень медленно.