代管 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 版本新,請重新啟動服務和閘道的非受管理 Proxy。
kubectl rollout restart deployment -n NAMESPACE