Share via

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

  • 發行項

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

有關 Istio 型服務網格附加元件之新次要修訂或修補程式版本的公告，會發佈在 AKS 版本資訊中。

次要修訂升級

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

如果叢集目前使用 Istio 支援的次要修訂，一次只能進行一次一個次要修訂。 如果叢集使用不支援的 Istio 修訂，您必須針對該 Kubernetes 版本升級至最低支援的 Istio 次要修訂。 之後，可以一次升級一次進行一次次要修訂。

下列範例說明如何從修訂 asm-1-18 升級至 asm-1-19。 所有次要升級的步驟都相同。

  1. 使用 az aks mesh get-upgrades (部分機器翻譯) 命令，來檢查可針對叢集使用哪些修訂作為升級目標：

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

    如果您預期會看到此命令未傳回的較新修訂，您可能需要先升級 AKS 叢集，使其與最新的修訂相容。

  2. 如果您已為叢集上現有的網格修訂設定網格設定，則必須在下一個步驟中aks-istio-system起始 Canary 升級之前，先建立對應至 命名空間中新修訂的個別 ConfigMap。 此設定在將新修訂的控制平面部署於叢集上那刻起便開始適用。 在 這裡可以找到更多詳細資訊。

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

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

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

  4. 確認對應至 asm-1-18 和 asm-1-19 的控制平面 Pod 是存在的：

    • 確認 istiod Pod：

      kubectl get pods -n aks-istio-system

      範例輸出︰

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

    • 如果已啟用輸入，請確認輸入 Pod：

      kubectl get pods -n aks-istio-ingress

      範例輸出︰

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

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

  5. 對命名空間進行重新標記，讓任何新的 Pod 都會取得與新修訂及其控制平面相關聯的 Istio Sidecar：

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

    在您的工作負載重新啟動之前，重新標記不會對其產生影響。

  6. 透過重新啟動每個應用程式工作負載來個別加以變換。 例如：

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

  7. 檢查您的監視工具和儀表板，以判斷您的工作負載在重新啟動之後是否都會以狀況良好的狀態執行。 根據結果，您有兩個選項：

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

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

    • 復原 Canary 升級：如果您觀察到工作負載健康情況有任何問題，則可復原至前一個 Istio 修訂：

      • 將命名空間重新標記至上一個修訂：

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

      • 再次重新啟動工作負載以復原這些工作負載，以使用對應至前一個 Istio 修訂的 Sidecar：

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

      • 將控制平面復原至前一個修訂：

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

  8. 如果 先前已針對修訂設定網格組態 ，您現在可以刪除在完成/回復期間從叢集移除之修訂的 ConfigMap。

注意

將命名空間移至新修訂時，手動對命名空間進行重新標記可能會很繁瑣且容易出錯。 修訂標籤 (英文) 可解決此問題。 修訂標籤是指向修訂的穩定識別碼，可用來避免重新標記命名空間。 網格操作員可以直接變更標籤以指向新修訂，而不需重新標記命名空間。 使用該標籤標記的所有命名空間都會同時更新。 不過，請注意，您仍然需要重新啟動工作負載，以確保會插入正確版本的 istio-proxy Sidecar。

使用輸入閘道進行次要修訂升級

如果您目前使用 Istio 輸入閘道 並執行次要修訂升級，請記住 Istio 輸入閘道 Pod/部署會部署每個修訂。 不過，我們會透過多個修訂在所有輸入閘道 Pod 之間提供單一 LoadBalancer 服務，因此在升級過程中，輸入閘道的外部/內部 IP 位址不會變更。

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

修補檔版本升級

  • 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.18.2-distroless",
"image": "mcr.microsoft.com/oss/istio/proxyv2:1.18.2-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.18.0, mcr.microsoft.com/oss/istio/proxyv2:1.18.1-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.18.0, mcr.microsoft.com/oss/istio/proxyv2:1.18.2-distroless