Как выполнить канареечное обновление существующей пользовательской установки istio.
Требование:
- У нас есть настроенная установка istio 1.7.3 (установленная с использованием метода istoctl и для этого не задана версия) для AKS 1.18.14.
- Теперь нам нужно обновиться до istio 1.8 без простоев или с минимальными затратами времени.
- Обновление должно быть более безопасным и никоим образом не нарушит нашу производственную среду.
Как мы установили текущую настроенную среду istio:
1) созданный манифест.
Генерировать манифест istioctl --set profile=default -f /manifests/overlay/overlay.yaml > $HOME/generated-manifest.yaml
2) установил истио.
istioctl установить --set profile=default -f /manifests/overlay/overlay.yaml
3) Проверка istio по развернутому манифесту.
istioctl verify-install -f $HOME/сгенерированный-манифест.yaml
Запланированный процесс обновления Справка
1) Предварительная проверка для обновления.
istioctl x предварительная проверка
2) экспортировать текущую используемую конфигурацию istio с помощью команды ниже в файл yaml.
kubectl -n istio-system получить iop установленное-состояние-установить -o yaml > /tmp/iop.yaml
3) Загрузите двоичный файл istio 1.8, извлеките каталог и перейдите в каталог, где у нас есть двоичный файл istioctl версии 1.8.
компакт-диск istio1.8\istioctl1.8
4) из каталога новой версии istio создайте новую плоскость управления для istio(1.8) с правильным набором ревизий и используйте ранее экспортированное состояние установки "iop.yaml".
./istioctl1.8 установить --set version=1-8 --set profile=default -f /tmp/iop.yaml
Ожидайте, что он создаст новую плоскость управления с существующей конфигурацией, и теперь у нас будет два развертывания плоскости управления и сервисы, работающие бок о бок:
$ kubectl get pods -n istio-system -l app=istiod
ИМЯ ГОТОВ СТАТУС ПЕРЕЗАПУСКА ВОЗРАСТ
istiod-786779888b-p9s5n 1/1 Бег 0 114м
istiod-1-7-6956db645c-vwhsk 1/1 Бег 0 1м
5) После этого нам нужно изменить существующую метку всех пространств имен нашего кластера, куда нам нужно внедрить прокси-контейнеры istio. Необходимо удалить старую метку «istio-injection» и добавить метку istio.io/rev, чтобы указать на канареечную версию 1-8.
$ kubectl label space namespace test-ns istio-injection-istio.io/rev=1-8
Надеюсь, на данный момент среда также стабильна со старыми конфигурациями istio, и мы можем принять решение о том, какие модули приложений можно перезапустить, чтобы внести изменения в новую плоскость управления в соответствии с нашим временем простоя, и разрешено запускать некоторые приложения со старой плоскостью управления и другой с новыми конфигурациями плоскости контроллера на данный момент.
например: развертывание kubectl, перезапуск, развертывание -n test-ns (сначала)
развертывание kubectl перезапустить развертывание -n test-ns2 (позже)
развертывание kubectl перезапустить развертывание -n test-ns3 (снова через некоторое время позже)
6) После того, как мы запланировали время простоя и перезапустили развертывание, как мы решили, подтвердите, что все модули теперь используют прокси-инжектор dataplane только версии 1.8.
kubectl получить pods -n test-ns -l istio.io/rev=1-8
7) Чтобы убедиться, что новые модули в пространстве имен test-ns используют сервис istiod-canary, соответствующий версии canary.
прокси-статус istioctl | grep ${имя_пода} | awk '{напечатать $7}'
8) После обновления плоскости управления и плоскости данных можно удалить старую плоскость управления.
istioctl x uninstall -f /tmp/iop.yaml.
Перед обновлением необходимо очистить следующие пункты.
- Все ли шаги, подготовленные для обновления, описанные выше, подходят для использования в среде Prod с высокой нагрузкой?
- Достаточно ли экспортировать установленное состояние IOP, чтобы получить все настроенные шаги для продолжения канареечного обновления? или есть вероятность тормозить апгрейд или пропускать какие-то настройки?
- Создаст ли вышеприведенный шаг 4 плоскость управления 1.8 istio со всеми настройками, которые у нас уже есть, без каких-либо поломок или упущений?
- после шага 4, нужна ли нам какая-либо дополнительная настройка, связанная с конфигурацией службы istiod> в следующем документе не ясно об этом,
- для шага 5 выше, как мы можем идентифицировать все пространства имен, где у нас включена istio-injection, и модифицировать только это пространство имен, а другие оставить такими, какими они были раньше?
- Итак, для шага 8 выше, как убедиться, что мы удаляем только старую плоскость управления? мы должны получить двоичный файл для старой плоскости управления, скажем (1.7 в моем случае), и использовать этот двоичный файл с тем же экспортированным файлом /tmp/iop.yaml?
- Нет идей о том, как откатить любые проблемы, возникшие между... до или после удаления старой плоскости управления
