клево, завидую вам, металистам :)
в гугле когда ты хочешь обновить версию он последовательно дрейнит и уничтожает по одной ноде заменяя новой (по крайней мере раньше так было, может сейчас улучшили)
мало того что процесс этот небыстрый, дак еще возникают косяки

к примеру, ты маленький стартап с 3 нодами на продакшне, и ты используешь ha redis sentinel (никогда не используйте редис в облаках, а лучше вообще его не используйте) - для этого ты прописал антиаффинити и у тебя 3 инстанса размазались по 3м нодам, все красиво

однако скедулер использует правила антиаффинити только когда надо под куда-то запихнуть, и никак его не контролирует дальше

что происходит когда обновление убивает ноду A? скедулер перекидывает инстанс редиса на B или C с вероятностью 50%
что происходит когда обновление убивает ноду B? скедулер перекидывает оба инстанса редиса на A или C

понятно что я описал вырожденый случай (никто не держит только 3 ноды, никто не поднимает ha кластер с кворумом из 3, можно прописать hard antiaffinity вместо soft, выкинуть редис и использовать нормальную базу, и тп), но идея в целом в том что сложно предсказать как себя поведет кластер redis - соберется ли он снова, не потеряет ли данные, это как игра в рулетку, ибо ты не застрахован от того что все или необходимые для кворума поды скопятся в одном месте

поэтому я еще использовал сервис (не помню названия, куча их) который по расписанию запускался, проверял antiaffinity и контролируемо убивал поды заставляя скедулер периодически подскедуливать :)

клево, завидую вам, металистам :)
в гугле когда ты хочешь обновить версию он последовательно дрейнит и уничтожает по одной ноде заменяя новой (по крайней мере раньше так было, может сейчас улучшили)
мало того что процесс этот небыстрый, дак еще возникают косяки

к примеру, ты маленький стартап с 3 нодами на продакшне, и ты используешь ha redis sentinel (никогда не используйте редис в облаках, а лучше вообще его не используйте) - для этого ты прописал антиаффинити и у тебя 3 инстанса размазались по 3м нодам, все красиво

однако скедулер использует правила антиаффинити только когда надо под куда-то запихнуть, и никак его не контролирует дальше

что происходит когда обновление убивает ноду A? скедулер перекидывает инстанс редиса на B или C с вероятностью 50%
что происходит когда обновление убивает ноду B? скедулер перекидывает оба инстанса редиса на A или C

понятно что я описал вырожденый случай (никто не держит только 3 ноды, никто не поднимает ha кластер с кворумом из 3, можно прописать hard antiaffinity вместо soft, выкинуть редис и использовать нормальную базу, и тп), но идея в целом в том что сложно предсказать как себя поведет кластер redis - соберется ли он снова, не потеряет ли данные, это как игра в рулетку, ибо ты не застрахован от того что все или необходимые для кворума поды скопятся в одном месте

поэтому я еще использовал сервис (не помню названия, куча их) который по расписанию запускался, проверял antiaffinity и контролируемо убивал поды заставляя скедулер периодически подскедуливать :)

Чот не видать. В ЦС чтоли?