Comments 8
С одной стороны: Технические работы на кластере можно проводить в любое время.
С другой стороны: Дебаг показал, что в одном из кластеров версия Istio 1.13, в другом — 1.16. После обновления до 1.16 проблема ушла.
То есть сейчас ваша инфраструктура зависит от одного сервиса, который не умеет в обратную совместимость в рамках minor версии? Как обновлять такой сервис?
Хороший вопрос.
Благодаря тому, что Deckhouse предоставляет возможность использовать несколько версий Istio одновременно, нет проблем зафиксировать версию Istio для сайдкаров с помощью лейбла на namespace istio.io/rev=vXxYZ
, выкатить на тест новую версию и довести её до продакшена.
Подробнее про это можно почитать в документации к Deckhouse.
Критичных сервисов в кластере много, но процесс обновлений выстроен и отработан: есть тестовые стенды, препрод стенды, и IaC. Сначала обновление обкатывается на не прод средах, только потом катится на прод в установленный регламентный период.
Обратную 100% совместимость, к сожалению, никто не гарантирует.
Если у вас в одном дц произошел пожар как выбалансировку направите в другой? Считаю использование истио и прочих сервисов доя мультикластеризации фуфлом полным. Ставите перед кластерами балансир(хоть в облаке) и им уже рулите трафик. Кластера в этом случае хоть вырубай для мейнтенса. Деплоить вам по-прежнему надо в оба кластера, но не будет вот этого перепрыгивания трафика при помощи истио через дк или впн между кластерами туда-сюда.
Как сделать Kubernetes еще круче: секреты безупречной работы