Не так давно, развернув в Kubernetes уже привычный инфраструктурный компонент в виде кластера Redis Sentinel + redis-sentinel-proxy, мы столкнулись с интересными проблемами. При тестировании времени переключения мастера выяснилось, что оно составляет полторы минуты. Это очень долго. 

Расскажу, как получилось ускорить процесс.

В прошлой части были рассмотрены рекомендации по множеству механизмов Kubernetes для оптимального деплоя высокодоступных приложений включая особенности работы планировщика, стратегии обновления, приоритеты, пробы и т.п. Во втором и заключительном материале поговорим о трёх важных оставшихся темах: PodDisruptionBudget, HorizontalPodAutoscaler, VerticalPodAutoscaler, — продолжив нумерацию из первой части.

Во многих инструкциях с просторов интернета описывают некий минимум действий, и как следствие минимум команд и возможностей.

Я решил сделать некую подборку мало освещенных возможностей, особенностей. Статья не претендует на уникальность, это и мне, как памятка, и возможно некоторым падаванам поможет, начинающим свой путь с docker-compose.