使用 Cloud Service Mesh 插入補充 Proxy

本文將說明如何使用 Cloud Service Mesh 設定邊車 Proxy 注入功能，以提升網路安全性、可靠性和可觀察性。這些函式會從應用程式的主要容器中移除，並且會在相同的 Pod 中以各自獨立的容器，透過程序以外的共用 Proxy 執行。這樣一來，您就能使用 Cloud Service Mesh 的功能，而無須重新設計要加入服務網格的實際應用程式。

當 Cloud Service Mesh 偵測到您為工作負載 Pod 所設定的命名空間標籤時，就會執行自動補充 Proxy 注入 (自動注入) 作業。這個 Proxy 會攔截所有傳入和傳出工作負載的流量，並與 Cloud Service Mesh 通訊。

執行這些工作所需的權限

如要執行本頁面中的任務，您必須具備 roles/container.clusterAdmin 或更高層級的角色。如要進一步瞭解這個角色的權限，請參閱「 Google Kubernetes Engine 角色」。

啟用自動補充插入功能

建議您使用以 Webhook 為基礎的自動補充器，來注入側邊代理程式，但您也可以手動更新 Pod 的 Kubernetes 設定。

如要啟用自動注入功能，請為命名空間加上預設注入標籤 (如果已設定預設標籤)，或修訂版本標籤。您新增的標籤也取決於您是部署代管的 Cloud Service Mesh (使用 fleet API 或 asmcli)，還是安裝叢集內控制層。此標籤會由側載注入器 webhook 使用，用於將注入的側載與特定控制平面修訂版本建立關聯。

如要啟用自動插入功能，請按照下列步驟操作：

叢集內

使用下列指令，找出 istiod 上的修訂版本標籤：

kubectl -n istio-system get pods -l app=istiod --show-labels

輸出看起來類似以下內容：

NAME                                READY   STATUS    RESTARTS   AGE   LABELS
istiod-asm-1252-3-5788d57586-bljj4   1/1     Running   0          23h   app=istiod,istio.io/rev=asm-1252-3,istio=istiod,pod-template-hash=5788d57586
istiod-asm-1252-3-5788d57586-vsklm   1/1     Running   1          23h   app=istiod,istio.io/rev=asm-1252-3,istio=istiod,pod-template-hash=5788d57586

在輸出內容的 LABELS 欄下，請記下 istiod 修訂版本標籤的值，該值位於前置字串 istio.io/rev= 之後。在這個範例中，這個值為 asm-1252-3。

注意：如果您已設定預設標記，可以將 istio.io/rev 替換為 istio-injection=enabled 標籤。請使用 OUTPUT_DIR 中的 istioctl 執行 istioctl tag list，確認預設標記是否存在。

將修訂版本標籤套用至命名空間，並移除 istio-injection 標籤 (如果有的話)。在下列指令中，NAMESPACE 是您要啟用自動插入功能的命名空間名稱，REVISION 則是您在上一個步驟中記下的修訂版本標籤。
```
kubectl label namespace NAMESPACE  istio-injection- istio.io/rev=REVISION --overwrite
```
您可以忽略輸出內容中的訊息 "istio-injection not found"。這表示命名空間先前沒有 istio-injection 標籤，而 Cloud Service Mesh 的新安裝作業或新部署作業應會包含此標籤。由於命名空間同時具有 istio-injection 和修訂版本標籤時，自動插入行為並未定義，因此 Cloud Service Mesh 說明文件中的所有 kubectl label 指令都會明確確保只設定一個。
請按照下一節的步驟重新啟動受影響的 Pod。

代管服務網格

使用下列指令找出可用的發布版本：
```
kubectl -n istio-system get controlplanerevision
```
輸出結果會與下列內容相似：
```
NAME                AGE
asm-managed         6d7h
```
在輸出內容中，選取 NAME 欄下方的值，即為 Cloud Service Mesh 版本的發布管道對應的 REVISION 標籤。將此標籤套用至命名空間，並移除 istio-injection 標籤 (如果有的話)。在下列指令中，將 REVISION 替換為您在上述步驟中記下的修訂版本標籤，並將 NAMESPACE 替換為您要啟用自動插入功能的命名空間名稱：
```
kubectl label namespace NAMESPACE  istio-injection- istio.io/rev=REVISION --overwrite
```
您可以忽略輸出內容中的訊息 "istio-injection not found"。這表示命名空間先前沒有 istio-injection 標籤，而 Cloud Service Mesh 的新安裝作業或新部署作業應會包含此標籤。由於命名空間同時具有 istio-injection 和修訂版本標籤時，自動插入行為並未定義，因此 Cloud Service Mesh 說明文件中的所有 kubectl label 指令都會明確確保只設定一個。
請按照下一節的步驟重新啟動受影響的 Pod。

如果您也部署了選用的 Google 管理資料平面，請按以下方式標註 demo 命名空間：

kubectl annotate --overwrite namespace YOUR_NAMESPACE \
mesh.cloud.google.com/proxy='{"managed":"true"}'

重新啟動 Pod 以更新補充 Proxy

透過自動附加元件插入功能，您可以透過 Pod 重新啟動更新現有 Pod 的附加元件：

重新啟動 Pod 的方式取決於 Pod 是否是部署的一部分。

如果您使用了 Deployment，請重新啟動 Deployment，這樣便可重新啟動所有具有附屬程式的 Pod：
```
kubectl rollout restart deployment -n YOUR_NAMESPACE
```
如果您未使用部署作業，請刪除 Pod，系統會自動使用 sidecar 重新建立 Pod：
```
kubectl delete pod -n YOUR_NAMESPACE --all
```
請確認命名空間中的所有 Pod 都已注入 sidecar：
```
kubectl get pod -n YOUR_NAMESPACE
```
在以下先前指令的範例輸出內容中，請注意 READY 欄表示每個工作負載都有兩個容器：主要容器和附屬 Proxy 的容器。
```
NAME                    READY   STATUS    RESTARTS   AGE
YOUR_WORKLOAD           2/2     Running   0          20s
...
```

後續步驟

請點選下列連結瞭解更多資訊：