代管 Cloud Service Mesh 發布管道

Cloud Service Mesh 會定期發布更新，提供安全性更新、修正已知問題，並推出新功能。發布版本會在穩定性與 Cloud Service Mesh 版本的功能組合之間取得平衡。Cloud Service Mesh 發布管道與 Google Kubernetes Engine (GKE) 發布管道相關聯。 Google 會自動管理每個發布版本的版本和升級頻率。

本文將比較各個發布管道，並說明如何更新非受管理 Proxy。

可用的發布管道

您可以使用下列發布版本。每個管道都會在功能可用性和更新流失率之間做出取捨。每個管道中的功能成熟度不同。重要安全性修補程式會發布至所有發布管道，以保護叢集和 Google 基礎架構。

頻道 代管 Cloud Service Mesh 新增可用性 屬性
快速 每次 Cloud Service Mesh 發布新版本後 盡早取得最新版 Cloud Service Mesh，並在版本中加入新功能時立即使用。控制層會經常更新，確保採用最新的修補程式版本，並提供新功能。搶鮮版最適合用於在試產環境中測試較新的 Cloud Service Mesh 版本和 API。
一般 「快速」升級為「一般」* 在 Cloud Service Mesh 和 Istio 功能推出後不久，即可存取這些功能，但使用的版本經過較長時間的驗證。兼顧功能可用性與版本穩定性，建議多數使用者採用這個版本。
穩定 「Regular」升級為「Stable」* 優先選擇穩定性，其次才是新功能。這個管道的變更和新版本會先在搶鮮版和一般版驗證，最後再推出，因此驗證時間更長。
*升級至下一個管道的時間表取決於多項因素，包括開放原始碼 Istio 版本、Anthos 版本和修補程式時間表，因此可能會有所變動。如要掌握最新資訊，請將 Cloud Service Mesh 版本資訊的網址新增至動態消息閱讀器，或直接新增以下動態消息網址：https://cloud.google.com/feeds/servicemesh-release-notes.xml

當代管 Cloud Service Mesh 的子版本在搶鮮版管道中達到足夠的使用量，且穩定性良好，就會升級至一般版管道。子版本最終會升級至穩定版，穩定版只會接收高優先順序的更新和安全性修補程式。每次升級都代表穩定性和正式環境適用性有所提升，這是根據執行該版本的控制層效能而定。

所有管道都以正式發布版 (GA) 為基礎 (但個別功能可能不一定為正式發布版，如標示所示)。新版 Cloud Service Mesh 會先發布至搶鮮版，然後再逐步升級至一般版和穩定版。您可以選擇符合業務、穩定性和功能需求的管道。

叢集的 Cloud Service Mesh 管道取決於 GKE 叢集管道。

GKE 管道 Cloud Service Mesh 頻道
快速 快速
一般 一般
穩定 穩定
(沒有管道) 一般

各管道的 Cloud Service Mesh 版本

佈建代管 Cloud Service Mesh 時，系統會根據 GKE 叢集管道決定 Cloud Service Mesh 管道。如果您之後變更 GKE 叢集管道，系統會保留原始的 Cloud Service Mesh 管道。

下表顯示目前管道與 Cloud Service Mesh 版本的對應關係：

管道 Cloud Service Mesh 版本
快速 1.21
一般 1.20
穩定 1.19

預設頻道

在全新安裝的 Cloud Service Mesh 中，如果叢集只安裝一個代管管道，該管道就會成為叢集的預設管道。

如果叢集已安裝 Istio 或 Cloud Service Mesh，且已設定預設標記，則必須指向受管理修訂版本。如果不是，則無須採取任何行動。

您可以將 istio-injection=enabled 標籤做為別名，指向您用於管道的其他標籤，例如預設修訂版本。在說明文件中，凡是顯示要使用 istio.io/rev 命名空間標籤進行注入的地方，都可以改用 istio-injection=enabled 標籤。

插入標籤

如要允許 Cloud Service Mesh 管理特定命名空間中的工作負載，命名空間必須標示與已安裝管道相應的標籤。代管 Cloud Service Mesh 支援兩種標籤：

  • 標準修訂標籤，即 asm-managed-stable、asm-managed、asm-managed-rapid，分別對應至 stable、regular 和 rapid 頻道。
  • 預設插入標籤 (例如 istio-injection=enabled)，對應於該叢集的預設管道。使用預設插入標籤可簡化修訂版本之間的遷移作業。舉例來說，從 Istio OSS 遷移，或是從非受管理 Cloud Service Mesh 遷移至受管理 Cloud Service Mesh 時，就不必個別重新標記每個命名空間。在 Cloud Service Mesh 文件中，凡是顯示要使用 istio.io/rev 命名空間標籤進行注入，都可以改用 istio-injection=enabled 標籤。

其他注入標籤範例包括使用 sidecar.istio.io/inject (通常用於閘道) 和 istio.io/rev 標記工作負載，這兩種標籤適用於命名空間和工作負載。

預設插入標籤

如要將預設插入標籤套用至命名空間，請按照下列步驟操作：

kubectl label namespace NAMESPACE istio-injection=enabled istio.io/rev- --overwrite

修訂版本標籤

與其他 Kubernetes 標籤一樣，修訂版本標籤是鍵/值組合。 修訂版本標籤中的鍵一律為 istio.io/rev，但值會有所不同。 如要選取發布管道，請將下列其中一個修訂版本名稱套用至命名空間：

修訂版本名稱 管道
asm-managed 一般
asm-managed-rapid 快速
asm-managed-stable 穩定

舉例來說，如要將「一般」發布管道套用至命名空間，請執行下列操作：

kubectl label namespace NAMESPACE istio.io/rev=asm-managed --overwrite

建議您使用叢集所用的發布管道。

如要查看命名空間使用的發布管道，請按照下列步驟操作：

kubectl get namespace NAMESPACE -o jsonpath='{.metadata.labels.istio\.io/rev}{"\n"}'

更新未受管理的 Proxy

每次發布 Cloud Service Mesh 後，請為服務和閘道重新啟動非受管理 Proxy。雖然控制層和 Proxy 採用不同版本時，服務網格仍可正常運作，但我們建議您更新 Proxy，以便使用新版 Cloud Service Mesh 設定 Proxy。

  1. 檢查控制層和 Proxy 版本。

  2. 如果控制層版本比 Proxy 版本新，請為服務和閘道重新啟動非受管理 Proxy。

    kubectl rollout restart deployment -n NAMESPACE