Скажем, у меня есть приложение с двумя развертываниями:
Кэш Redis предоставляется службой под названием «redis». Приложение подключается к службе Redis, используя имя хоста службы («redis»).
Скажем, приложение получает обновление с версии 1 до версии 2. Спецификация контейнера развертывания обновлена, поэтому теперь она основана на app:2 образ контейнера.
Проблема вот в чем: в процессе обновления две версии приложения используют одну и ту же службу Redis. Новое приложение, достигнув состояния готовности, нагревает кеш, в основном разрушая его для все еще работающей версии 1.
Облегчает ли Kubernetes создание, при котором новая версия развертывания получает собственную службу Redis, которую он может разогревать перед достижением состояния готовности и на которую не влияет текущая версия? Когда Kubernetes убивает текущую ревизию из-за того, что новая ревизия достигла состояния готовности, он должен вместе с ней отключить службу Redis, связанную с этой ревизией.
Облегчает ли Kubernetes создание, при котором новая версия развертывания получает собственный сервис Redis
Рассматривали ли вы возможность отправки приложения в Pod с двумя контейнерами, один из которых является вашим Redis?
в процессе обновления две версии приложения используют одну и ту же службу Redis
Возможно, стоит подумать об изменении стратегии развертывания на Recreate, если вы можете позволить себе временное отключение службы, это обеспечит отключение предыдущей копии вашего приложения перед запуском следующей.
Если мы хотим избежать прерывания обслуживания любой ценой, тогда, возможно, рассмотрим сине-зеленые развертывания: всегда имейте две копии вашего приложения (redis + app), повторно разверните только на одной стороне, затем перенастройте входящий трафик, отправляя клиентов на новый версия.