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

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

使用 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 設定。

如要啟用自動插入功能，請使用預設插入標籤標記命名空間 (如果已設定預設標籤)，或使用修訂版本標籤標記命名空間。側車注入器 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。

重新啟動 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
...
```

後續步驟

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