Cloud Service Mesh 和 Traffic Director 現已改名為 Cloud Service Mesh。詳情請參閱 Cloud Service Mesh 總覽。

本頁面由 Cloud Translation API 翻譯而成。

Cloud Service Mesh 控制層修訂版本

本頁內容適用於叢集內和受管理ISTIOD 控制層實作。本頁內容不適用於TRAFFIC_DIRECTOR控制層實作，因為這是多租戶的全域控制層，沒有個別修訂版本。

本頁說明控制層修訂版本的運作方式，以及使用這些版本進行安全服務網升級 (和回溯) 的價值。

服務網格安裝基本概念

整體來說，Cloud Service Mesh 安裝作業包含兩大階段：

首先，您可以使用 asmcli 工具安裝叢集內控制層，或設定受管理控制層。控制層由一組系統服務組成，負責管理網格設定。
接著，您會在整個環境中部署特殊的補充 Proxy，攔截每個工作負載的網路通訊。Proxy 會與控制層通訊以取得設定，讓您在網格中導向及控管流量 (資料層流量)，而不必變更工作負載。

如要部署 Proxy，請使用「自動 Sidecar 插入」 (自動插入) 程序，在每個工作負載 Pod 中，以額外的 Sidecar 容器形式執行 Proxy。您不需要修改用於部署工作負載的 Kubernetes 資訊清單，但必須為命名空間新增標籤，並重新啟動 Pod。

使用修訂版本安全升級網格

控管流量是使用服務網格的主要優點之一。舉例來說，您可以在首次將應用程式部署至正式環境時，逐步將流量轉移至新版本。如果在升級期間發現問題，您可以將流量移回原始版本，以簡單且低風險的方式還原。這個程序稱為「Canary 發布」，可大幅降低新部署作業的相關風險。

在 Canary 升級中使用控制層修訂版本時，您會一併安裝新的獨立控制層和設定，以及現有的控制層。安裝程式會指派名為修訂版本的字串，用來識別新的控制平面。一開始，Sidecar Proxy 會繼續接收舊版控制層的設定。您可以為工作負載的命名空間或 Pod 加上新控制平面的修訂版本標籤，逐步將工作負載與新控制平面建立關聯。為命名空間或 Pod 加上新修訂版本的標籤後，請重新啟動工作負載 Pod，系統就會自動注入新的 Sidecar，並從新的控制層接收設定。如果發生問題，只要將工作負載與原始控制層建立關聯，即可輕鬆復原。

自動插入功能如何運作？

自動插入功能會使用 Kubernetes 的准入控制功能。系統會註冊變異准入 Webhook，監控新建立的 Pod。Webhook 會透過命名空間選取器設定，因此只會比對部署至具有特定標籤命名空間的 Pod。如果 Pod 符合條件，Webhook 會諮詢控制層提供的插入服務，取得 Pod 的新變動設定，其中包含執行補充容器和磁碟區所需的容器和磁碟區。

補充資訊注入器

安裝期間會建立 Webhook 設定。向 Kubernetes API 伺服器註冊 Webhook。
Kubernetes API 伺服器會監控命名空間中與 Webhook namespaceSelector 相符的 Pod 部署作業。
命名空間會加上標籤，以便 namespaceSelector 比對。
部署至命名空間的 Pod 會觸發 Webhook。
控制層提供的 inject 服務會變更 Pod 規格，自動插入補充資訊容器。

什麼是修訂版本？

用於自動插入的標籤與其他使用者定義的 Kubernetes 標籤相同。標籤基本上是鍵/值組合，可用於支援標籤的概念。標籤廣泛用於標記和修訂。例如 Git 標記、Docker 標記和 Knative 修訂版本。

目前的 Cloud Service Mesh 安裝程序可讓您使用修訂版本字串，為已安裝的控制層加上標籤。安裝程式會為每個控制層物件加上修訂版本標籤。鍵值組中的鍵為 istio.io/rev，但受管理控制層和叢內控制層的修訂版本標籤值不同。

如果是叢內控制層，istiod 服務和部署作業通常會有類似 istio.io/rev=asm-1253-11 的修訂版本標籤，其中 asm-1253-11 會識別 Cloud Service Mesh 版本。修訂版本會成為服務名稱的一部分，例如：istiod-asm-1253-11.istio-system
如果是代管控制層，修訂版本標籤會對應至發布版本：

修訂版本標籤管道

istio.io/rev=asm-managed 一般

istio.io/rev=asm-managed-rapid 快速

istio.io/rev=asm-managed-stable 穩定

修訂版本標籤	管道
`istio.io/rev=asm-managed`	一般
`istio.io/rev=asm-managed-rapid`	快速
`istio.io/rev=asm-managed-stable`	穩定

此外，您也可以使用預設插入標籤 (例如 istio-injection=enabled)。

如要啟用自動插入功能，請在命名空間中新增與控制層修訂版本標籤相符的修訂版本標籤。舉例來說，修訂版本為 istio.io/rev=asm-1253-11 的控制平面會選取命名空間中具有 istio.io/rev=asm-1253-11 標籤的 Pod，並注入 Sidecar。

初期測試升級程序

修訂版本標籤可讓您執行初期測試升級，並輕鬆復原叢集內控制層。代管控制項的程序類似，但叢集會自動升級至該管道的最新版本。

初期測試升級

整個程序的運作流程如下：

首先，請安裝現有的 Cloud Service Mesh 或開放原始碼 Istio。無論命名空間是使用修訂版本標籤還是 istio-injection=enabled 標籤，都不會影響。
安裝新版控制平面時，請使用修訂版本字串。由於修訂版本字串的關係，新控制層會與現有版本一併安裝。新安裝項目包含新的 Webhook 設定，並已設定 namespaceSelector，可監控具有特定修訂版本標籤的命名空間。
如要將 Sidecar Proxy 遷移至新的控制層，請從命名空間中移除舊標籤、新增修訂版本標籤，然後重新啟動 Pod。如果您使用 Cloud Service Mesh 的修訂版本，就必須停止使用 istio-injection=enabled 標籤。即使有修訂版本標籤，具有修訂版本的控制層也不會選取命名空間中含有 istio-injection 標籤的 Pod。新控制平面的 Webhook 會將 Sidecar 插入 Pod。
請仔細測試與升級控制層相關聯的工作負載，然後繼續推出升級或還原至原始控制層。

將 Pod 與新的控制層建立關聯後，現有的控制層和 Webhook 仍會安裝在系統中。如果命名空間已遷移至新的控制層，舊版 Webhook 對其中的 Pod 就沒有影響。您可以移除新的修訂版本標籤、加回原始標籤，然後重新啟動 Pod，將命名空間中的 Pod 復原為原始控制平面。確認升級完成後，即可移除舊的控制平面。

如需使用修訂版本升級的詳細步驟，請參閱升級指南。

進一步瞭解變異 Webhook 設定

如要進一步瞭解自動 Sidecar 插入的變動 Webhook，請自行檢查設定。使用下列指令：

kubectl -n istio-system get mutatingwebhookconfiguration -l app=sidecar-injector -o yaml

您應該會看到已安裝的每個控制層都有各自的設定。以修訂版本為準的控制層命名空間選取器如下所示：

 namespaceSelector:
    matchExpressions:
    - key: istio-injection
      operator: DoesNotExist
    - key: istio.io/rev
      operator: In
      values:
      - asm-1253-11

選取器可能會因您執行的 Cloud Service Mesh 或 Istio 版本而異。只要命名空間沒有 istio-injection 標籤，這個選取器就會比對具有特定修訂版本標籤的命名空間。

當 Pod 部署至符合選取器的命名空間時，系統會將 Pod 規格提交至注入器服務進行突變。要呼叫的注入器服務指定方式如下：

     service:
        name: istiod-asm-1253-11
        namespace: istio-system
        path: /inject
        port: 443

控制層會在 inject URL 路徑的通訊埠 443 上公開服務。

rules 區段指定 Webhook 應套用至 Pod 建立作業：

   rules:
    - apiGroups:
      - ""
      apiVersions:
      - v1
      operations:
      - CREATE
      resources:
      - pods
      scope: '*'