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

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

  • Статья

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

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

Обновление дополнительных версий

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    4. Метка пространств имен приложения для сопоставления с тегами редакции:

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

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

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

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

    1. Проверьте istiod модули pod:

      kubectl get pods -n aks-istio-system

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

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

    2. Если входящий трафик включен, убедитесь, что модули pod ingress:

      kubectl get pods -n aks-istio-ingress

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

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

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

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

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

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

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

      istioctl tag list

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

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

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

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

      kubectl label namespace default istio.io/rev=asm-1-23 --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-22 --istioNamespace aks-istio-system --overwrite

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

      kubectl label namespace default istio.io/rev=asm-1-22 --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. Если конфигурация сетки ранее была настроена для редакций, теперь можно удалить ConfigMap для редакции, которая была удалена из кластера во время завершения или отката.

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

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

Таким образом, во время обновления канарной версии, когда две редакции существуют одновременно в кластере, модули pod шлюза входящего трафика обоих редакций служат для входящего трафика.

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

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

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

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

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

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

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

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

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

    • Проверьте версию образа прокси-сервера Istio для всех модулей pod в пространстве имен:

      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.22.0, mcr.microsoft.com/oss/istio/proxyv2:1.22.0-distroless

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

      kubectl rollout restart deployments/productpage-v1 -n default

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

      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.22.0-distroless

Примечание.

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