代管 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。
一般 Rapid 已升級為 Regular* 在 Cloud Service Mesh 和 Istio 功能推出後,在相當短的時間內就存取這些功能,不過會以經過較長時間驗證的版本進行。這能讓您在功能可用性和版本穩定性之間取得平衡,也是我們推薦給大多數使用者的選項。
穩定 將 Regular 升級為 Stable* 優先選擇穩定性,其次才是新功能。這個發布版的變更和新版本先發行搶鮮版,然後花更多時間驗證功能後推出一般版,到最後才推出這些變更和新版本
*升級至下一個管道的時間表取決於多項因素,包括開放原始碼 Istio 版本、Anthos 版本和修補時間表,因此可能會有所變動。如要隨時掌握最新資訊,請將 Cloud Service Mesh 發布說明的網址加入動態消息閱讀器,或直接新增動態消息網址: https://cloud.google.com/feeds/servicemesh-release-notes.xml

當代管 Cloud Service Mesh 的次要版本在快速版中累積足夠的使用量並展現出穩定性時,就會升級至一般版。最終,次要版本會升級至「穩定版」,只接收高優先順序的更新和安全性修補程式。每次升級都會根據觀察到執行該版本的控制平面效能發出提升穩定性與生產準備就緒的訊號。

所有管道均以正式發行 (GA) 版本為基礎 (但個別功能不一定是 GA,如標示)。新的 Cloud Service Mesh 版本會先發布至搶鮮版,然後隨著時間推移至一般版和穩定版。這樣一來,您就能選擇符合業務、穩定性和功能需求的管道。

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

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

每個管道的 Cloud Service Mesh 版本

您的 Cloud Service Mesh 管道取決於佈建代管 Cloud Service Mesh 時的 GKE 叢集管道。如果您之後變更 GKE 叢集通道,則會保留原始的 Cloud Service Mesh 通道。

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

管道 Cloud Service Mesh 版本
快速 1.20
一般 1.19
穩定 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-stableasm-managedasm-managed-rapid,對應至頻道 stableregularrapid
  • 預設插入標籤 (例如 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 版本進行設定。

  1. 查看控制層和 Proxy 版本

  2. 如果控制層版本較 Proxy 版本新,請重新啟動服務和閘道的未管理 Proxy。

    kubectl rollout restart deployment -n NAMESPACE