Поделиться через

Обновление надстройки сетевой оболочки службы на основе Istio для Службы Kubernetes в Azure

В этой статье рассматриваются возможности обновления для надстройки сетевого mesh на основе Istio для Службы Kubernetes в Azure (AKS).

Объявления о выходе новых минорных ревизий или патчей для дополнения сетевой структуры на основе Istio публикуются в заметках о выпуске AKS. Чтобы узнать больше о расписании выпуска и поддержке исправлений надстроек для сетки служб, прочтите раздел политики поддержки.

Незначительное обновление версии

Надстройка Istio позволяет обновить минорную ревизию с помощью процесса обновления в режиме канареечного релиза. При запуске обновления плоскость управления новой (пилотной) редакции развертывается наряду с плоскостью управления начальной (стабильной) редакции. Затем можно вручную выполнить перенос рабочих нагрузок на уровне данных, используя средства мониторинга для отслеживания состояния рабочих нагрузок во время этого процесса. Если вы не видите никаких проблем со работоспособностью рабочих нагрузок, вы можете завершить обновление, чтобы только новая редакция осталась в кластере. В противном случае вы можете вернуться к предыдущей версии Istio.

Доступные обновления зависят от того, поддерживается ли текущая версия версии кластера Istio и AKS:

  • Вы можете выполнить обновление до следующей поддерживаемой версии (n+1) или пропустить ее до n+2версии кластера, если оба варианта поддерживаются и совместимы с версией кластера.
  • Если текущая редакция (n) и следующая редакция (n+1) не поддерживаются, можно обновить только до ближайшей поддерживаемой редакции (n+2 или более поздней версии), но не за ее пределами.
  • Если версия кластера и версия Istio не поддерживаются, перед началом обновления Istio необходимо обновить версию кластера.

Примечание.

После того как версия AKS или редакция сетки выходит за пределы окна поддержки, обновление любой версии становится подверженной ошибкам. Хотя такие обновления разрешены для восстановления до поддерживаемой версии, процесс обновления и сами версии вне поддержки не поддерживаются корпорацией Майкрософт. Настоятельно рекомендуется обновлять версию AKS и редакцию сетки, чтобы избежать возникновения неподдерживаемых сценариев. См. календарь поддержки дополнений Istio для оценки дат выпуска и окончания жизненного цикла, а также заметки о выпуске исходного кода Istio для новой ревизии, чтобы узнать о значительных изменениях.

Следующий пример показывает, как обновить с ревизии asm-1-23 до asm-1-24 все рабочие нагрузки в пространстве имен default. Шаги одинаковы для всех небольших обновлений и могут использоваться для любого количества пространств имён.

  1. Используйте команду az aks mesh get-upgrades, чтобы проверить, какие редакции доступны для кластера в качестве целевых объектов обновления:

    az aks mesh get-upgrades --resource-group $RESOURCE_GROUP --name $CLUSTER

    Если вы ожидаете, что новая редакция не возвращается этой командой, может потребоваться сначала обновить кластер AKS, чтобы он был совместим с новой редакцией.

  2. Если вы настраиваете mesh configuration для существующей mesh revision в вашем кластере, вам нужно создать отдельный ConfigMap для новой ревизии в aks-istio-system namespace перед началом выполнения canary upgrade на следующем этапе. Эта конфигурация применима к моменту развертывания уровня управления новой редакции в кластере. Дополнительные сведения можно найти здесь.

  3. Инициируйте канарное обновление с ревизии asm-1-23 на asm-1-24 с использованием az aks mesh upgrade start:

    az aks mesh upgrade start --resource-group $RESOURCE_GROUP --name $CLUSTER --revision asm-1-24

    Обновление по канарному методу означает, что плоскость управления версии 1.24 развертывается вместе с плоскостью управления версии 1.23. Они продолжают сосуществовать, пока вы не завершите либо не откатите обновление.

    Пока выполняется обновление канарной версии, более высокая редакция считается версией по умолчанию , используемой для проверки ресурсов Istio.

  4. При необходимости теги версии могут использоваться для перехода плоскости данных на новую версию без необходимости вручную переопределять метки в каждом пространстве имен. Вручную переназначать пространства имен при их переносе на новую ревизию может быть утомительно и подвержено ошибкам. Теги ревизии решают эту проблему, служа стабильными идентификаторами, которые указывают на ревизии.

    Вместо повторной маркировки каждого пространства имен оператор кластера может изменить тег, чтобы он указывал на новую редакцию. Все пространства имен, помеченные этим тегом, обновляются одновременно. Тем не менее, необходимо перезапустить рабочие нагрузки, чтобы убедиться, что правильная версия istio-proxy сайдкары внедрена.

    Чтобы использовать теги редакции во время обновления, выполните указанные действия.

    1. Установка интерфейса командной строки istioctl

    2. Создайте тег редакции для первоначальной редакции. В этом примере мы назовем его prod-stable:

      istioctl tag set prod-stable --revision asm-1-23 --istioNamespace aks-istio-system

    3. Создайте тег редакции для редакции, установленной во время обновления. В этом примере мы назовем его prod-canary:

      istioctl tag set prod-canary --revision asm-1-24 --istioNamespace aks-istio-system

    4. Пометьте пространства имен приложения для сопоставления с тегами версий.

      # label default namespace to map to asm-1-23
kubectl label ns default istio.io/rev=prod-stable --overwrite

      Вы также можете маркировать пространства имен с помощью istio.io/rev=prod-canary, чтобы отметить более новую ревизию. Однако рабочие нагрузки в этих пространствах имен не обновляются на новый сайдкар, пока они не будут перезапущены.

      Если новое приложение создается в пространстве имен после того, как оно было помечено, будет внедрен побочный процесс, соответствующий тегу ревизии в этом пространстве имен.

  5. Убедитесь, что pod'ы плоскости управления существуют и соответствуют обоим asm-1-23 и asm-1-24.

    1. Проверьте istiod podы:

      kubectl get pods -n aks-istio-system

      Пример результата:

      NAME                                        READY   STATUS    RESTARTS   AGE
istiod-asm-1-23-55fccf84c8-dbzlt            1/1     Running   0          58m
istiod-asm-1-23-55fccf84c8-fg8zh            1/1     Running   0          58m
istiod-asm-1-24-f85f46bf5-7rwg4             1/1     Running   0          51m
istiod-asm-1-24-f85f46bf5-8p9qx             1/1     Running   0          51m

    2. Если доступ включен, проверьте поды доступа.

      kubectl get pods -n aks-istio-ingress

      Пример результата:

      NAME                                                          READY   STATUS    RESTARTS   AGE
aks-istio-ingressgateway-external-asm-1-23-58f889f99d-qkvq2   1/1     Running   0          59m
aks-istio-ingressgateway-external-asm-1-23-58f889f99d-vhtd5   1/1     Running   0          58m
aks-istio-ingressgateway-external-asm-1-24-7466f77bb9-ft9c8   1/1     Running   0          51m
aks-istio-ingressgateway-external-asm-1-24-7466f77bb9-wcb6s   1/1     Running   0          51m
aks-istio-ingressgateway-internal-asm-1-23-579c5d8d4b-4cc2l   1/1     Running   0          58m
aks-istio-ingressgateway-internal-asm-1-23-579c5d8d4b-jjc7m   1/1     Running   0          59m
aks-istio-ingressgateway-internal-asm-1-24-757d9b5545-g89s4   1/1     Running   0          51m
aks-istio-ingressgateway-internal-asm-1-24-757d9b5545-krq9w   1/1     Running   0          51m

      Обратите внимание, что поды шлюза ингресса обеих ревизий развертываются параллельно. Однако служба и его IP-адрес остаются неизменяемыми.

  6. Переименуйте пространство имен так, чтобы все новые pods сопоставлялись с контейнером sidecar Istio, связанным с новой версией и ее плоскостью управления.

    1. При использовании тегов редакции перезапишите сам тег prod-stable, чтобы изменить его назначение.

      istioctl tag set prod-stable --revision asm-1-24 --istioNamespace aks-istio-system --overwrite

      Проверьте сопоставления тегов с редакциями.

      istioctl tag list

      Оба тега должны указывать на только что установленную редакцию:

      TAG           REVISION   NAMESPACES
prod-canary   asm-1-24   default
prod-stable   asm-1-24   ...

      В этом случае вам не нужно переназначать каждое пространство имен по отдельности.

    2. Если теги редакции не используются, пространства имен плоскости данных должны быть переобозначены, чтобы указать на новую редакцию.

      kubectl label namespace default istio.io/rev=asm-1-24 --overwrite

    Переименовка не влияет на ваши рабочие нагрузки до тех пор, пока они не будут перезапущены.

  7. Поштучно перезапустите каждую рабочую нагрузку вашего приложения для их обновления. Например:

    kubectl rollout restart deployment <deployment name> -n <deployment namespace>

  8. Проверьте ваши инструменты и панели мониторинга, чтобы определить, находятся ли ваши рабочие нагрузки в исправном состоянии после перезагрузки. В зависимости от результата у вас есть два варианта:

    1. Завершите канарное обновление: если вы удовлетворены тем, что рабочие нагрузки работают в исправном состоянии, как ожидалось, можно завершить канарное обновление. Завершение обновления удаляет плоскость управления предыдущей редакции и оставляет за ней плоскость управления новой редакции в кластере. Выполните следующую команду, чтобы завершить обновление канареечной версии:

      az aks mesh upgrade complete --resource-group $RESOURCE_GROUP --name $CLUSTER

    2. Откат канареечного обновления: если вы наблюдаете какие-либо проблемы с работоспособностью ваших рабочих нагрузок, можно выполнить откат к предыдущей версии Istio.

    • Переименуйте пространство имен к предыдущей версии: если используются теги редакции:

      istioctl tag set prod-stable --revision asm-1-23 --istioNamespace aks-istio-system --overwrite

      Или, если не используются теги редакции:

      kubectl label namespace default istio.io/rev=asm-1-23 --overwrite

    • Восстановление предыдущей версии рабочих нагрузок для использования сайдкара, соответствующего предыдущей редакции Istio, путем повторной перезагрузки этих рабочих нагрузок:

      kubectl rollout restart deployment <deployment name> -n <deployment namespace>

    • Откатите контрольную плоскость к предыдущей ревизии:

      az aks mesh upgrade rollback --resource-group $RESOURCE_GROUP --name $CLUSTER

    Тег prod-canary ревизии можно удалить:

    istioctl tag remove prod-canary --istioNamespace aks-istio-system

  9. Если ранее для ревизий была настроена конфигурация mesh-сети, теперь можно удалить ConfigMap для ревизии, которая была удалена из кластера во время завершения или отката.

Незначительные обновления версий с шлюзами входа и выхода

Если вы используете шлюзы Istio ingress или шлюзы Istio egress и выполняете небольшое обновление версии, имейте в виду, что Istio ingress и egress pod / развертывания устанавливаются для каждой версии, но служба используется совместно для обеих версий.

Мы предоставляем одну LoadBalancer службу для всех подов шлюза входящего трафика по нескольким ревизиям, поэтому внешний и внутренний IP-адреса шлюзов входящего трафика остаются неизменными на протяжении всего периода обновления. Таким образом, во время канареечного обновления, когда две версии существуют одновременно в кластере, модули pod шлюза входящего трафика обеих версий обслуживают входящий трафик.

Аналогичным образом, во время канареечного обновления все pod'ы для шлюза исходящего трафика в обеих ревизиях будут обслуживаться одним ClusterIP сервисом.

Незначительные обновления ревизий с настройками горизонтального автоматического масштабирования pod

Если вы настроили параметры горизонтального подового автомасштабирования (HPA) для Istiod или шлюзов входящего трафика, обратите внимание на следующее поведение при применении параметров HPA для обеих ревизий для обеспечения согласованности во время канарного обновления.

  • При обновлении спецификации HPA перед запуском обновления, параметры существующей (стабильной) версии будут применены к HPA канареечной версии при установке новой управляющей плоскости.
  • Если вы обновите спецификацию HPA, пока идет канарейное обновление, спецификация HPA стабильной версии будет иметь приоритет и будет применена к HPA канарейной версии.
    • При обновлении HPA стабильной версии во время обновления настройки HPA канареечной версии будут изменены, чтобы отразить изменения, примененные к стабильной версии.
    • При обновлении HPA канареечной ревизии в процессе модернизации, спецификация HPA канареечной ревизии будет возвращена к спецификации HPA стабильной ревизии.

Обновление версии пакета

  • Сведения о доступности патча для дополнения Istio публикуются в замечаниях о выпуске AKS.
  • Исправления автоматически разворачиваются для pods istiod и ingress в рамках этих выпусков AKS, которые соблюдают defaultзапланированное окно технического обслуживания, установленное для кластера.
  • Пользователю необходимо инициировать установку патчей для прокси Istio в своих рабочих нагрузках, перезапустив поды для повторной инъекции.

    • Проверьте версию прокси-сервера Istio, предназначенную для новых или перезапущенных pod. Эта версия совпадает с версией istiod и pods Istio ingress после их обновления.

      kubectl get cm -n aks-istio-system -o yaml | grep "mcr.microsoft.com\/oss\/istio\/proxyv2"

      Пример результата:

      "image": "mcr.microsoft.com/oss/istio/proxyv2:1.23.0-distroless",
"image": "mcr.microsoft.com/oss/istio/proxyv2:1.23.0-distroless"

    • Проверьте версию образа прокси Istio для всех подов в пространстве имен.

      kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\
sort |\
grep "mcr.microsoft.com\/oss\/istio\/proxyv2"

      Пример результата:

      productpage-v1-979d4d9fc-p4764:	docker.io/istio/examples-bookinfo-productpage-v1:1.23.0, mcr.microsoft.com/oss/istio/proxyv2:1.23.0-distroless

    • Чтобы активировать повторную инъекцию, перезапустите нагрузки. Например:

      kubectl rollout restart deployments/productpage-v1 -n default

    • Чтобы убедиться, что они теперь на более новых версиях, проверьте версию образа прокси-сервера Istio для всех подов в пространстве имен еще раз.

      kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\
sort |\
grep "mcr.microsoft.com\/oss\/istio\/proxyv2"

      Пример результата:

      productpage-v1-979d4d9fc-p4764:	docker.io/istio/examples-bookinfo-productpage-v1:1.2.0, mcr.microsoft.com/oss/istio/proxyv2:1.24.0-distroless

Примечание.

В случае возникновения проблем при обновлении обратитесь к статье об устранении неполадок обновлений сетки

  • Last updated on