使用 Cloud Service Mesh 插入補充 Proxy

本文說明如何使用 Cloud Service Mesh 設定 Sidecar 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-1264-1-5788d57586-bljj4   1/1     Running   0          23h   app=istiod,istio.io/rev=asm-1264-1,istio=istiod,pod-template-hash=5788d57586
istiod-asm-1264-1-5788d57586-vsklm   1/1     Running   1          23h   app=istiod,istio.io/rev=asm-1264-1,istio=istiod,pod-template-hash=5788d57586

在輸出內容的 LABELS 欄下方，記下 istiod 修訂版本標籤的值 (前置字串為 istio.io/rev=)。在本範例中，這個值為 asm-1264-1。

注意：如果已設定預設標記，您可以將 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

使用自動 Sidecar 插入功能時，您可以重新啟動 Pod，更新現有 Pod 的 Sidecar：

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

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

後續步驟

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