McRouter на кластере Google Cloud. Как бороться с обновлением узла?

Question

Мы запускаем развертывание с 3 узлами mcrouter / memcached kubernetes (через helm) в кластере Google Cloud. Мы используем кластер вместо одной виртуальной машины, чтобы сделать наше веб-приложение (которое использует memcache для сеансов) устойчивым к сбоям узла.

При обновлении узлов kubernetes выселяет стручки один за другим и генерирует новые. Поскольку memcache - это хранилище в памяти, эти новые модули создаются без данных. Маршруты mcrouter, которые мы используем в настоящее время, не оптимальны для этой ситуации, о чем свидетельствуют периодические сбои сеансов во время обновления.

Насколько я понимаю, есть 2 способа справиться с этим:

1. Использование WarmUpRoute
2. Использование MissFailoverRoute

Если я хочу использовать WarmUpRoute, тогда мне нужно сделать следующее:

1. Перед обновлением узла переключите текущую конфигурацию на конфигурацию, которая определяет один из узлов как «теплый» сервер, а два других - как «холодный» сервер.
2. Выполните обновление узла на двух холодных серверах.
3. Разрешить клиентам запрашивать кэш в течение нескольких дней, что будет медленно приводить к тому, что холодные серверы будут зеркалировать теплый сервер, так как пропадание кэша вызывает синхронизацию.
4. Переключите эту конфигурацию WarmUpRoute с другой конфигурацией WarmUpRoute, в которой сервер, ранее обозначенный как «теплый», обозначен как «холодный», и наоборот.
5. Повторите шаг 3
6. Наконец, когда все серверы синхронизированы, вернитесь к моей исходной конфигурации.

Если я хочу использовать MissFailoverRoute, тогда мне нужно сделать это:

1. Используйте конфигурацию, которая определяет один из узлов memcache в качестве узла аварийного переключения.
2. Обновление двух не отказоустойчивых узлов
3. Обновление отказоустойчивого узла

Правильно ли я понимаю? Похоже, что второй вариант намного проще. Есть ли преимущества у метода WarmUpRoute? Есть ли третий вариант, который будет работать лучше, чем эти два?