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

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

Cloud Service Mesh 控制層修訂版本

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

服務網格安裝基礎知識

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

首先，您必須使用 asmcli 工具安裝叢集內控制平面。控制層包含一組系統服務，負責管理網格設定。
接著，您會在整個環境中部署特殊的補充 Proxy，攔截進出各項工作負載的網路通訊。代理會與控制層通訊，取得相關設定，讓您能引導及控管網格中的流量 (資料層流量)，而無須變更工作負載。

如要部署 Proxy，您可以使用稱為自動側邊車注入 (自動注入)的程序，在每個工作負載 Pod 中，將 Proxy 當作額外的側邊車容器執行。您不需要修改用於部署工作負載的 Kubernetes 資訊清單，但必須在命名空間中新增標籤，並重新啟動 Pod。

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

控管流量是使用服務網格的主要優點之一。舉例來說，您可以在首次將應用程式部署至正式環境時，逐步將流量轉移至新版本。如果在升級期間偵測到問題，您可以將流量轉移回原始版本，這麼做可降低回溯的風險。這項程序稱為測試版發布，可大幅降低新部署作業的風險。

在測試群升級中使用控制層修訂版本時，您會在現有控制層旁邊安裝新的獨立控制層和設定。安裝程式會指派名為修訂版本的字串，用於識別新的控制平面。一開始，附加元件 Proxy 會繼續接收先前版本控制層的設定。您可以為命名空間或 Pod 加上新控制層修訂版本的標籤，逐步將工作負載與新控制層建立關聯。使用新修訂版本標記命名空間或 Pod 後，請重新啟動工作負載 Pod，以便自動插入新的附屬程式，並從新的控制層接收設定。如果發生問題，您可以將工作負載與原始控制平面建立關聯，藉此回復原狀。

自動插入功能的運作方式為何？

自動插入功能會使用名為「許可控制」的 Kubernetes 功能。系統會註冊變更的許可 webhook，以便監控新建的 Pod。webhook 會使用命名空間選取器進行設定，因此只會比對已部署至具有特定標籤的命名空間的 Pod。當 Pod 符合條件時，webhook 會諮詢控制層提供的注入服務，為 Pod 取得新的變異設定，其中包含執行 sidecar 所需的容器和磁碟區。

邊車注入器

系統會在安裝期間建立 webhook 設定。Webhook 會向 Kubernetes API 伺服器註冊。
Kubernetes API 伺服器會監控命名空間中是否有與 webhook namespaceSelector 相符的 Pod 部署作業。
命名空間已標示，因此會與 namespaceSelector 相符。
部署至命名空間的 Pod 會觸發 Webhook。
控制層提供的 inject 服務會變更 Pod 規格，以便自動插入 sidecar。

什麼是修訂版本？

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

在目前的 Cloud Service Mesh 安裝程序中，您可以使用修訂字串標示已安裝的控制層。安裝程式會為每個控制層物件標記修訂版本。鍵/值組合中的鍵為 istio.io/rev。對於叢集內控制層，istiod 服務和部署作業通常會使用類似 istio.io/rev=asm-1264-1 的修訂版本標籤，其中 asm-1264-1 會標示 Cloud Service Mesh 版本。修訂版本會成為服務名稱的一部分，例如：istiod-asm-1264-1.istio-system。

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

初期測試升級程序

修訂版本標籤可讓您對叢集內控制層執行 Canary 升級和回溯作業。

初期測試升級

以下步驟說明這項程序的運作方式：

請先使用現有的 Cloud Service Mesh 或開放原始碼 Istio 安裝程序。無論命名空間使用修訂版本標籤或 istio-injection=enabled 標籤，都沒有關係。
安裝新版控制平面時，請使用修訂字串。由於有修訂版本字串，因此新控制層會與現有版本一併安裝。新安裝程序包含新的 webhook 設定，其中 namespaceSelector 已設定為監控具有該特定修訂版本標籤的命名空間。
您可以將附加元件 Proxy 遷移至新的控制層，方法是從命名空間中移除舊標籤、新增新修訂版本標籤，然後重新啟動 Pod。如果您使用修訂版本搭配 Cloud Service Mesh，就必須停止使用 istio-injection=enabled 標籤。即使有修訂版本標籤，具有修訂版本的控制層也不會選取具有 istio-injection 標籤的命名空間中的 Pod。新控制平面的 webhook 會將 sidecar 插入 Pod。
仔細測試與升級控制層相關聯的工作負載，然後繼續推出升級作業，或回復原始控制層。

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

進一步瞭解變異 Webhook 設定

如要進一步瞭解自動側載注入功能的變異 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-1264-1

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

當 Pod 部署至與選取器相符的命名空間時，其 Pod 規格會提交至注入器服務進行變異。要呼叫的注入器服務如下所示：

     service:
        name: istiod-asm-1264-1
        namespace: istio-system
        path: /inject
        port: 443

控制層會在 inject 網址路徑的 443 通訊埠上公開這項服務。

rules 部分指定 webhook 應套用至 Pod 建立作業：

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