#Базывкубеболь #mongodb Такой вопрос, вот есть statefulSet c mongodb в конфигурации

replicaSet (PRIMARY + SECONDARY + SECONDARY)
Допустим мы обновляем в нем request/лимиты или меняем еще что-то в спеке pod'а что-то.

допустим на данный момент
mongo-0 - PRIMARY
mongo-1 - SECONDARY
mongo-2 - SECONDARY

Ну и конечно есть headles сервис для этого дела

У клиентов указаны все поды в качестве uri подключения, то есть: mongodb://mongo-0.headles-service:27017,mongo-1.headles-service:27017,mongo-2.headles-service:27017/db-name

Что делают контроллер statefulset и всякие preStop хуки
1) грохает mongo-2
2) когда mongo-2 перезапустился, грохает mongo-1. (тут стоит lifecycle.preStop, который ожидает когда mongo-2 будет отставать от мастера не больше чем на 10 секунд)
3) когда mongo-1 перезапустился. (Мы точно уверены что mongo-2 нормауль поднялся и не сильно отстает от PRIMARY). Контроллер грохает mongo-0 с PRIMARY
И тут нюанс, когда pod грохается, он сразу помечается как terminating и следовательно выкидывается из endpoint сервиса, а следовательно DNS адрес вида mongo-0.headles-service перестает резолвится. Все эти вещи происходят НЕ дожидаясь выполнения lifecycle.preStop

Другими словами, если мы быстро не назначим перевыборы PRIMARY в момент когда mongo-0 начинает грохатся, то у клиентов новые коннекты с запросами на запись перестанут проходить, поскольку DNS mongo-0.headles-service (который до сих пор считается PRIMARY) перестает резолвится и к нему не подключитьтся.

То есть на 3 этапе, лучше не ждать когда mongo-1 догонит PRIMARY, а сразу делать rs.stepDown() для принудительных перевыборов PRIMARY.
А так как мы не дождались и не знаем что там с mongo-1, то у нас на момент убийства mongo-0 и команды rs.setDown(), скорее всего будет жить и нормально работать только mongo-2, что по идее довольно рисковання ситуация (жива только одна реплика из трех)

юзать readinessProbe для того чтобы ждать когда репликация догонит, тоже нерабочая идея, поскольку пока мы не прошли readinessProbe, мы не появимся в качестве endpoint'ов в headles сервиса, а значит остальной replicaSet монги просто не увидет перезапущенную реплику и она никогда не подключится в replicaSet.

как с таким живете?

Я в качестве решения, вижу только тут возможность разруливать это со стороны оператора. Причем чтобы нормально рулить перезапусками, надо свой контроллер реализовывать, а не statefulSet, ну либо создавать по одному sts на каждый pod для replicaSet mongodb.

да, нужен оператор

А вот тут я не уверен кстати. То, что адрес пода mongo-0 перестанет ресолвится. Мне помнится, там другой механизм и адреса не готовых подов выкидываются только из headles.ns.svc

это если флажок соответствующий стоит

Какой флажок? Где стоит ?

> То, что адрес пода mongo-0 перестанет ресолвится. инфа сотка, у меня в кластере перестает резолвится примерно через 7-10 секунд как только под переходит в terminating и запускается preStop хук

в сервисе блин

Попообуй флажок Гаала

пойду смотреть флаги. Поскольку в mongodb вообще этот функционал по выкидываю endpoint'ов из сервиса не нужен (ну то есть если конечно под на совсем удалился, то окей)