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

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

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

注意

服務網狀附加元件不支援自動升級。 在自動升級的叢集中，過時的網格版本最終可能不相容，阻擋叢集的自動升級。 升級外掛，讓它能與叢集的 Kubernetes 版本相容。

小幅修訂升級

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

可用的升級取決於目前的 Istio 修訂和 AKS 叢集版本是否受到支援：

  • 您可以升級至 下一個支援的修訂 （n+1） 或略過 ，並升級至 n+2，只要兩者都受到支援且與叢集版本相容。
  • 如果您的目前修訂 （n） 和下一個修訂 （n+1） 都不受支援，則您只能升級至 最接近支持的修訂 （n+2 或更新版本），但不能升級至該修訂以外的版本。
  • 如果不支援叢集版本和 Istio 修訂，就必須先升級叢集版本，才能起始 Istio 升級。

注意

一旦 AKS 版本或網格修訂落在支援視窗外，升級任一版本就會變得容易出錯。 雖然允許這類升級復原至支援的版本，但Microsoft不支持升級程式和不支援的版本本身。 強烈建議您將 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. 如果您已為叢集上現有的網格修訂設定網格設定 (部分內容可能是機器或 AI 翻譯)，則必須於在下一個步驟中aks-istio-system，先建立對應至 命名空間中新修訂的個別 ConfigMap。 此設定在將新修訂的控制平面部署於叢集上那刻起便開始適用。 在 這裡可以找到更多詳細資訊。

  3. 使用 asm-1-23 (部分內容可能是機器或 AI 翻譯)，起始從修訂 asm-1-24 到 的 Canary 升級：

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

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

    在 Canary 升級進行中時，較高的修訂版本會被認為是用於驗證 Istio 資源的預設修訂版本。

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

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

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

    1. 安裝 istioctl CLI

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

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

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

    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. 如果已啟用輸入，請確認輸入 Pod：

      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

      觀察這兩個修訂的輸入閘道 Pod 會並存部署。 不過，服務及其 IP 會維持不可變。

  6. 重新標記命名空間，以便任何新的 Pod 都會對應到與新修訂版本及其控制平面相關聯的 Istio Sidecar：

    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. 完成 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-23 --istioNamespace aks-istio-system --overwrite

      或者，如果未使用修訂標籤：

      kubectl label namespace default istio.io/rev=asm-1-23 --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 都會處理傳入的流量。

同樣地，在 Canary 升級期間，跨兩個修訂的所有輸出閘道 Pod，都會由單一 ClusterIP 服務提供服務。

具有水平 Pod 自動調整自訂的次要修訂版本升級

如果您已針對 Istiod 或輸入閘道自訂了水平 Pod 自動調整 (HPA) 設定，請注意在 Canary 升級期間，HPA 設定如何在兩個修訂版本之間套用以保持一致性的以下行為：

  • 如果您在起始升級之前更新 HPA 規格，則在安裝新的控制平面時，現有 (穩定) 修訂版本中的設定會套用至 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.23.0-distroless",
"image": "mcr.microsoft.com/oss/istio/proxyv2:1.23.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.23.0, mcr.microsoft.com/oss/istio/proxyv2:1.23.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.24.0-distroless

注意

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

  • 上次更新時間：