共用方式為

升級適用於 Azure Kubernetes Service 的 Istio 型服務網格附加元件

  • 發行項

本文將討論適用於 Azure Kubernetes Service (AKS) 的 Istio 型服務網格附加元件的升級體驗。

會在 AKS 發行備註中發佈公告，內容與 Istio 型服務網格附加元件之全新次要修訂或修補程式版本有關。 若要深入瞭解服務網格附加元件修訂的版本排程和支援，請閱讀 支持原則。

次要修訂升級

Istio 附加元件允許使用 Canary 升級流程，以升級次要修訂。 起始升級時，新的 （canary） 修訂的控制平面會與初始（穩定）修訂的控制平面一起部署。 然後，您可以手動變換資料平面工作負載，並在此流程期間使用監視工具來追蹤工作負載的健康情況。 如果您未觀察到工作負載健康情況的任何問題，您就能完成升級，使叢集上只保留新修訂。 否則，您可以復原至前一個 Istio 修訂。

如果叢集目前使用支援的 Istio 次要修訂，則一次僅允許升級一個次要修訂。 如果叢集使用不支援的 Istio 修訂，您必須針對該 Kubernetes 版本升級至支援的最低 Istio 次要修訂。 之後，就能再度一次升級一個次要修訂。

下列範例說明如何從修訂 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. 如果您在叢集上設定現有網格修訂的網格組態，您必須在下一個步驟中起始 Canary 升級之前，先建立與命名空間中aks-istio-system新修訂對應的個別 ConfigMap。 此設定在將新修訂的控制平面部署於叢集上那刻起便開始適用。 在 這裡可以找到更多詳細資訊。

  3. 使用 az aks mesh upgrade start (部分機器翻譯)，起始從修訂 asm-1-22 到 asm-1-23 的 Canary 升級：

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

    Canary 升級表示 1.23 控制平面會與 1.22 控制平面一起部署。 其會繼續共存，直到您完成或復原升級為止。

  4. 或者，修訂標籤可用來將數據平面變換至新的修訂，而不需要手動重新標記每個命名空間。 將命名空間移至新修訂時，手動對命名空間進行重新標記可能會很繁瑣且容易出錯。 修訂標籤 可藉由提供指向修訂的穩定標識碼來解決此問題。

    叢集運算符可以變更標籤指向新的修訂，而不是重新標記每個命名空間。 標記為該標籤的所有命名空間都會同時更新。 不過，您仍然需要重新啟動工作負載，以確保插入正確的側車版本 istio-proxy 。

    若要在升級期間使用修訂標籤：

    1. 安裝 istioctl CLI

    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 命名空間的標籤。 不過，這些命名空間中的工作負載在重新啟動之前不會更新為新的側車。

      如果在命名空間加上標籤之後，在命名空間中建立新的應用程式，則會插入與該命名空間上的修訂標籤對應的 Sidecar。

  5. 確認對應至 asm-1-22 和 asm-1-23 的控制平面 Pod 是存在的：

    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：

      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 Sidecar：

    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. 完成 Canary 升級：如果您對工作負載都如預期般以狀況良好的狀態執行感到滿意，則可完成 Canary 升級。 升級完成會移除前一個修訂的控制平面，並將新修訂的控制平面留在叢集上。 執行下列命令以完成 Canary 升級：

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

    2. 復原 Canary 升級：如果您觀察到工作負載健康情況有任何問題，則可復原至前一個 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 修訂的 Sidecar：

      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 輸入閘道並執行次要修訂升級，請記住，系統會按照每個修訂部署 Istio 輸入閘道 Pod/部署。 不過，我們會透過多個修訂在所有輸入閘道 Pod 之間提供單一 LoadBalancer 服務，因此在升級過程中，輸入閘道的外部/內部 IP 位址會保持不變。

因此，在 Canary 升級期間，當叢集上同時存在兩個修訂時，這兩個修訂的輸入網關 Pod 會提供連入流量。

使用水準 Pod 自動調整自定義進行次要修訂升級

如果您已針對 Istiod 或輸入閘道自定義水準 Pod 自動調整 （HPA） 設定，請注意下列行為，說明如何在這兩個修訂之間套用 HPA 設定，以在 Canary 升級期間維持一致性：

  • 如果您在起始升級之前更新 HPA 規格，則安裝新的控制平面時，現有 （stable） 修訂的設定會套用至 Canary 修訂的 HPA。
  • 如果您在進行 Canary 升級時更新 HPA 規格，穩定修訂的 HPA 規格將會優先，並套用至 Canary 修訂的 HPA。
    • 如果您在升級期間更新穩定修訂的 HPA，則會更新 Canary 修訂的 HPA 規格，以反映套用至穩定修訂的新設定。
    • 如果您在升級期間更新 Canary 修訂的 HPA，Canary 修訂的 HPA 規格將會還原為穩定修訂的 HPA 規格。

修補檔版本升級

  • Istio 附加元件修補檔版本可用性資訊會在 AKS 發行備註 (英文) 中發佈。
  • 在這些 AKS 版本中，會針對 istiod 和輸入 Pod 自動推出修補檔，其會遵守為叢集設定的default計劃性維護期間 (部分機器翻譯)。
  • 使用者必須重新啟動 Pod 以供重新插入，以在其工作負載中起始 Istio Proxy 的修補檔：

    • 檢查適用於新 Pod 或重新啟動 Pod 的 Istio Proxy 版本。 此版本與修補後的 istiod 和 Istio 輸入 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"

    • 檢查命名空間中所有 Pod 的 Istio Proxy 映像版本：

      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

    • 若要確認其目前使用較新版本，請再次檢查命名空間中所有 Pod 的 Istio Proxy 映像版本：

      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

注意

如果升級期間發生任何問題，請參閱針對網格修訂升級進行疑難排解一文