使用 Cloud Service Mesh 插入補充 Proxy
本文說明如何使用 Cloud Service Mesh 設定 Sidecar Proxy 插入功能,以提升網路安全性、可靠性和可觀測性。這些功能會從應用程式的主要容器中移除,並且會在相同的 Pod 中以各自獨立的容器,透過程序以外的共用 Proxy (補充資訊) 執行。這樣一來,您不必重新設計生產應用程式,即可使用Cloud Service Mesh 的功能。
當 Cloud Service Mesh 偵測到您為工作負載 Pod 設定的命名空間標籤時,就會自動植入補充資訊 Proxy (自動植入)。Proxy 會攔截工作負載的所有傳入和傳出流量,並與 Cloud Service Mesh 通訊。
啟用自動補充植入功能
建議使用以 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-1271-5-5788d57586-bljj4 1/1 Running 0 23h app=istiod,istio.io/rev=asm-1271-5,istio=istiod,pod-template-hash=5788d57586 istiod-asm-1271-5-5788d57586-vsklm 1/1 Running 1 23h app=istiod,istio.io/rev=asm-1271-5,istio=istiod,pod-template-hash=5788d57586 - 在輸出內容的 - LABELS欄下方,記下- istiod修訂版本標籤的值 (前置字串為- istio.io/rev=)。在本範例中,這個值為- asm-1271-5。
- 將修訂版本標籤套用至命名空間,並移除 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 ... 
後續步驟
請點選下列連結瞭解更多資訊: