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

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

翻新作業的設定更新

本文說明將服務網格從 ISTIOD 控制層升級至 TRAFFIC_DIRECTOR 控制層前，可能需要對代管 Cloud Service Mesh 進行的設定更新。

以下列出可能需要進行的設定更新，以便為叢集現代化做好準備。請參閱各節的更新說明：

多叢集
啟用 Workload Identity Federation for GKE
啟用代管 CNI
Sidecar 中非標準的二進位檔用法
遷移至 Istio Ingress 閘道

如要進一步瞭解現代化工作流程，請參閱「受管理控制層現代化」頁面。

從 Istio 密鑰遷移至 multicluster_mode

如果叢集使用 TRAFFIC_DIRECTOR 控制層，則不支援多叢集密鑰。本文說明如何從使用 Istio 多叢集密鑰，改為使用 multicluster_mode。

Istio 密鑰與宣告式 API 總覽

開放原始碼 Istio 多叢集端點探索功能會使用 istioctl 或其他工具，在叢集中建立 Kubernetes Secret。這個密鑰可讓叢集將流量負載平衡至網格中的另一個叢集。ISTIOD 控制層接著會讀取這個密鑰，並開始將流量轉送至其他叢集。

Cloud Service Mesh 具有宣告式 API，可控制多叢集流量，不必直接建立 Istio 密鑰。這個 API 會將 Istio 密鑰視為實作詳細資料，而且比手動建立 Istio 密鑰更可靠。日後的 Cloud Service Mesh 功能將依附於宣告式 API，您無法直接使用 Istio 密鑰來使用這些新功能。宣告式 API 是唯一支援的未來發展方向。

如果您使用 Istio Secret，請盡快改用宣告式 API。請注意，multicluster_mode 設定會指示每個叢集將流量導向網格中的所有其他叢集。使用密鑰可讓您更彈性地設定，針對網格中的每個叢集，設定要將流量導向哪個其他叢集。如要查看宣告式 API 和 Istio 密鑰支援功能的所有差異，請參閱「使用 Istio API 支援的功能」。

從 Istio 密鑰遷移至宣告式 API

如果您使用車隊功能 API 透過自動管理方式佈建 Cloud Service Mesh，則不需要按照這些操作說明進行。只有透過 asmcli --managed 完成新手上路程序，才需要執行這些步驟。

請注意，這項程序會變更指向叢集的密鑰。在此期間，系統會先移除端點，然後再重新加入。在移除和新增端點之間，流量會短暫還原為在本機路由，而不是負載平衡至其他叢集。詳情請參閱 GitHub 問題。

如要從使用 Istio 密鑰改為使用宣告式 API，請按照下列步驟操作。請同時或快速連續執行下列步驟：

在要啟用多叢集端點探索功能的艦隊中，為每個叢集啟用宣告式 API，方法是設定 multicluster_mode=connected。請注意，如要避免叢集可供探索，您必須明確設定 multicluster_mode=disconnected。

使用下列指令，為叢集啟用多叢集端點探索功能：
```
 kubectl patch configmap/asm-options -n istio-system --type merge -p '{"data":{"multicluster_mode":"connected"}}'
```
使用下列指令，讓叢集退出端點探索：
```
 kubectl patch configmap/asm-options -n istio-system --type merge -p '{"data":{"multicluster_mode":"disconnected"}}'
```
刪除舊密鑰。

在叢集上設定 multicluster_mode=connected 後，每個叢集都會為其他也設定 multicluster_mode=connected 的叢集產生新的密碼。密鑰會放在 istio-system 命名空間中，格式如下：
```
istio-remote-secret-projects-PROJECT_NAME-locations-LOCATION-memberships-MEMBERSHIPS
```
每個密鑰也會套用 istio.io/owned-by: mesh.googleapis.com 標籤。

建立新密鑰後，您可以手動刪除使用 istioctl create-remote-secret 建立的任何密鑰：
```
kubectl delete secret SECRET_NAME -n istio-system
```

遷移完成後，請檢查要求指標，確認要求已按照預期路徑傳送。

啟用 GKE 適用的工作負載身分聯盟

建議您使用 Workload Identity Federation，以安全的方式存取 Google Kubernetes Engine 工作負載。這樣就能存取 Compute Engine、BigQuery 和 Machine Learning API 等服務。 Google Cloud Workload Identity Federation 使用 IAM 政策，因此不需要手動設定，也不會採用服務帳戶金鑰檔案等安全性較低的驗證方法。如要進一步瞭解 Workload Identity Federation，請參閱「GKE 適用的 Workload Identity Federation 運作方式」。

下一節說明如何啟用 Workload Identity Federation。

在叢集上啟用 Workload Identity Federation

確認叢集已啟用 Workload Identity Federation。如要這麼做，請確保 GKE 叢集已設定 Workload Identity 聯盟集區，這是 IAM 憑證驗證的必要條件。

使用下列指令，檢查叢集設定的工作負載身分集區：
```
gcloud container clusters describe CLUSTER_NAME \
  --format="value(workloadIdentityConfig.workloadPool)"
```
將 CLUSTER_NAME 替換為您的 GKE 叢集名稱。如果尚未為 gcloud 指定預設區域或地區，執行這項指令時，可能也需要指定 --region 或 --zone 標記。
如果輸出內容為空白，請按照「更新現有叢集」一文中的操作說明，在現有 GKE 叢集上啟用 Workload Identity。

在節點集區上啟用 Workload Identity Federation

在叢集上啟用 Workload Identity Federation 後，必須將節點集區設定為使用 GKE 中繼資料伺服器。

列出 Standard 叢集的所有節點集區。執行 gcloud container node-pools list 指令：
```
gcloud container node-pools list --cluster CLUSTER_NAME
```
將 CLUSTER_NAME 替換為您的 GKE 叢集名稱。如果尚未為 gcloud 指定預設區域或地區，執行這項指令時，可能也需要指定 --region 或 --zone 標記。
確認每個節點集區都使用 GKE 中繼資料伺服器：
```
gcloud container node-pools describe NODEPOOL_NAME \
    --cluster=CLUSTER_NAME \
    --format="value(config.workloadMetadataConfig.mode)"
```
更改下列內容：
- 將 NODEPOOL_NAME 替換為節點集區的名稱。
- 將 CLUSTER_NAME 替換為 GKE 叢集的名稱。
如果輸出內容不含 GKE_METADATA，請按照「更新現有節點集區」指南更新節點集區。

啟用代管容器網路介面 (CNI)

本節將說明如何在 Google Kubernetes Engine 上啟用 Cloud Service Mesh 的代管 CNI。

代管 CNI 總覽

代管容器網路介面 (CNI) 是 Google 實作的 Istio CNI。CNI 外掛程式會設定 iptables 規則，簡化 Pod 網路。這樣一來，應用程式和 Envoy 代理程式之間就能重新導向流量，不必再使用管理 iptables 所需的 init-container 權限。

Istio CNI 外掛程式會取代 istio-init 容器。istio-init 容器先前負責設定 Pod 的網路環境，以啟用 Istio Sidecar 的流量攔截功能。CNI 外掛程式會執行相同的網路重新導向功能，但額外的好處是減少對進階權限的需求，進而提升安全性。

因此，為了提升安全性與可靠性，並簡化管理和疑難排解作業，所有 Managed Cloud Service Mesh 部署作業都必須使用代管 CNI。

對 init 容器的影響

初始化容器是專用容器，會在應用程式容器之前執行，用於設定工作。設定工作可能包括下載設定檔、與外部服務通訊，或執行應用程式初始化前置作業。在叢集中啟用受管理 CNI 時，依賴網路存取權的 Init 容器可能會發生問題。

使用受管理 CNI 設定 Pod 的程序如下：

CNI 外掛程式會設定 Pod 網路介面、指派 Pod IP，並將流量重新導向至尚未啟動的 Istio 補充資訊 Proxy。
所有 init 容器都會執行並完成。
Istio Sidecar Proxy 會與應用程式容器一併啟動。

因此，如果 init 容器嘗試建立外送網路連線，或連線至網格內的服務，init 容器的網路要求可能會遭到捨棄或錯誤路由。這是因為在發出要求時，管理 Pod 網路流量的 Istio Sidecar Proxy 並未執行。詳情請參閱 Istio CNI 說明文件。

為叢集啟用代管 CNI

請按照本節中的步驟，在叢集上啟用代管 CNI。

從 init 容器中移除網路依附元件。請考慮下列替代方案：
- 修改應用程式邏輯或容器：您可以修改服務，移除對需要網路要求的 init 容器的依附元件，或在 Sidecar Proxy 啟動後，在應用程式容器中執行網路作業。
- 使用 Kubernetes ConfigMap 或 Secret：將網路要求擷取的設定資料儲存在 Kubernetes ConfigMap 或 Secret 中，然後掛接至應用程式容器。如需替代解決方案，請參閱 Istio 說明文件。
在叢集上啟用代管 CNI：
1. 進行下列設定變更：
  1. 執行下列指令，找出 controlPlaneRevision。
```
kubectl get controlplanerevision -n istio-system
```
  2. 在 ControlPlaneRevision (CPR) 自訂資源 (CR) 中，將標籤 mesh.cloud.google.com/managed-cni-enabled 設為 true。
```
kubectl label controlplanerevision CPR_NAME \
    -n istio-system mesh.cloud.google.com/managed-cni-enabled=true \
    --overwrite
```
    將 CPR_NAME 換成上一步輸出內容中「NAME」資料欄的值。
  3. 在 asm-options ConfigMap 中，將 ASM_OPTS 值設為 CNI=on。
```
kubectl patch configmap asm-options -n istio-system \
    -p '{"data":{"ASM_OPTS":"CNI=on"}}'
```
  4. 在 ControlPlaneRevision (CPR) 自訂資源 (CR) 中，將標籤 mesh.cloud.google.com/force-reprovision 設為 true。這項操作會觸發控制層重新啟動。
    
    注意： 不建議使用這個方法重新啟動控制層，只應在進行 Cloud Service Mesh 現代化時使用。
```
kubectl label controlplanerevision CPR_NAME \
    -n istio-system mesh.cloud.google.com/force-reprovision=true \
    --overwrite
```
2. 檢查功能狀態。使用下列指令擷取功能狀態：
```
gcloud container fleet mesh describe --project FLEET_PROJECT_ID
```
  將 FLEET_PROJECT_ID 替換為車隊主機專案的 ID。一般來說，FLEET_PROJECT_ID 的名稱與專案相同。
  - 確認 MANAGED_CNI_NOT_ENABLED 條件已從 servicemesh.conditions 中移除。
  - 請注意，狀態最多可能需要 15 到 20 分鐘才會更新。請稍待片刻，然後重新執行指令。
3. 叢集的功能狀態為 Active 時，請重新啟動 Pod。controlPlaneManagement.state

避免在 Sidecar 中使用非標準二進位檔

本節將說明如何讓部署作業與無發行版本 Envoy Proxy 映像檔相容。

Distroless Envoy Proxy 補充映像檔

Cloud Service Mesh 會根據控制層設定，使用兩種 Envoy Proxy Sidecar 映像檔：包含各種二進位檔的 Ubuntu 映像檔，以及 Distroless 映像檔。Distroless 基本映像檔是最小的容器映像檔，只包含必要元件，因此可優先考量安全性及資源最佳化。減少攻擊面，有助於防範安全漏洞。詳情請參閱 Distroless Proxy 映像檔說明文件。

二進位檔相容性

最佳做法是將容器執行階段的內容限制為僅包含必要套件。這種做法可提升安全性，並改善常見安全漏洞與弱點 (CVE) 掃描器的訊號雜訊比。Distroless Sidecar 映像檔的依附元件數量最少，且已移除所有非必要的執行檔、程式庫和偵錯工具。因此，您無法在容器內執行殼層指令，或使用 curl、ping 或其他偵錯公用程式 (例如 kubectl exec)。

讓叢集與無發行版本的映像檔相容

從設定中移除對任何不支援的二進位檔 (例如 bash 或 curl) 的參照。特別是在 istio-proxy、istio-init 或 istio-validation 容器內的 Readiness、Startup 和 Liveness探查，以及 Lifecycle PostStart 和 PreStop掛鉤。
某些用途更適合交由其他替代方案處理，例如 holdApplicationUntilProxyStarts。
如要進行偵錯，可以使用臨時容器附加至執行中的工作負載 Pod。接著即可檢查並執行自訂指令。如需範例，請參閱「收集 Cloud Service Mesh 記錄」。

如果找不到特定用途的解決方案，請參閱「取得支援」一文，與支援團隊聯絡。 Google Cloud

遷移至 Istio Ingress Gateway

本節說明如何遷移至 Istio Ingress Gateway。您可以透過兩種方法遷移至 Istio 輸入閘道：

透過流量拆分進行階段式遷移

這個方法會優先減少中斷情形，逐步將流量傳送至新的 Istio 閘道，讓您監控一小部分要求的效能，並在必要時快速還原。請注意，設定第 7 層流量分割對某些應用程式來說可能很困難，因此您需要在轉換期間同時管理兩個閘道系統。如需相關步驟，請參閱「分階段遷移並分配流量」一節。
直接遷移

這個方法是在徹底完成測試後，同時將所有流量重新導向新的 Istio 閘道。這種做法的優點是與舊閘道的基礎架構完全分離，因此可彈性設定新閘道，不受現有設定的限制。不過，如果轉換期間新閘道發生非預期問題，停機風險就會增加。如需相關步驟，請參閱「直接遷移」一文。

下列遷移範例假設您有一個 HTTP 服務 (httpbin) 在應用程式命名空間 (預設) 中執行，並使用 Kubernetes Gateway API 對外公開。相關設定如下：

閘道：k8-api-gateway (位於 istio-ingress 命名空間中) - 設定為監聽通訊埠 80 上的 HTTP 流量，適用於任何以 .example.com 結尾的主機名稱。
HTTPRoute：httpbin-route (位於 default 命名空間中) - 將主機名稱為 httpbin.example.com 且路徑開頭為 /get 的任何 HTTP 要求，導向至 default 命名空間中的 httpbin 服務。
您可以使用外部 IP 34.57.246.68 存取 httpbin 應用程式。

基本閘道示意圖

階段式遷移作業 (拆分流量)

佈建新的 Istio Ingress Gateway

按照「部署範例閘道」一節中的步驟部署新的 Ingress 閘道，並根據需求自訂範例設定。anthos-service-mesh 存放區中的範例適用於部署 istio-ingressgateway loadBalancer 服務和對應的 ingress-gateway Pod。

閘道資源範例 (istio-ingressgateway.yaml)

 apiVersion: networking.istio.io/v1beta1
 kind: Gateway
 metadata:
   name: istio-api-gateway
   namespace: GATEWAY_NAMESPACE
 spec:
   selector:
     istio: ingressgateway  # The selector should match the ingress-gateway pod labels.
   servers:
   - port:
       number: 80
       name: http
       protocol: HTTP
     hosts:   # or specific hostnames if needed
     - "httpbin.example.com"

套用 Gateway 設定來管理流量：
```
kubectl apply -f istio-ingressgateway.yaml -n GATEWAY_NAMESPACE
```
請確認 Gateway 資源中的「spec.selector」與 ingress-gateway Pod 的標籤相符。舉例來說，如果 ingress-gateway Pod 具有 istio=ingressgateway 標籤，閘道設定也必須選取這個 istio=ingressgateway 標籤。

為新閘道設定初始路徑

使用 Istio VirtualService 為應用程式定義初始轉送規則。

VirtualService 範例 (my-app-vs-new.yaml)：

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: httpbin-vs
  namespace: APPLICATION_NAMESPACE
spec:
    gateways:
    - istio-ingress/istio-api-gateway  # Replace with <gateway-namespace/gateway-name>
    hosts:
    - httpbin.example.com
    http:
    - match:
      - uri:
          prefix: /get
      route:
      - destination:
          host: httpbin
          port:
            number: 8000

套用 VirtualService：

kubectl apply -f my-app-vs-new.yaml -n MY_APP_NAMESPACE

透過新部署的 Istio Ingress Gateway 存取後端 (httpbin) 服務

將 Ingress 主機環境變數設為與最近部署的 istio-ingressgateway 負載平衡器相關聯的外部 IP 位址：

export INGRESS_HOST=$(kubectl -n GATEWAY_NAMESPACE get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')

確認使用新閘道即可存取應用程式 (httpbin)：

curl -s -I -HHost:httpbin.example.com "http://$INGRESS_HOST/get"

輸出內容類似如下：

HTTP/1.1 200 OK

使用新的 Istio Ingress 閘道要求流程

修改現有 Ingress，進行流量拆分

確認新閘道 (例如 istio-api-gateway) 設定成功後，即可開始透過該閘道轉送部分流量。如要這麼做，請更新目前的 HTTPRoute，將一小部分的流量導向新閘道，其餘流量則繼續使用現有閘道 (k8-api-gateway)。

開啟 httproute 進行編輯：

kubectl edit httproute httpbin-route -n MY_APP_NAMESPACE

新增後端參照，指向新的 Ingress Gateway 的 LoadBalancer 服務，初始權重為 10%，並更新舊閘道後端的權重。

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: httpbin-route
  namespace: MY_APP_NAMESPACE  # your application's namespace
spec:
  parentRefs:
  - name: k8-api-gateway
    namespace: istio-ingress
  hostnames: ["httpbin.example.com"]
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /get
    backendRefs:
    - name: httpbin
      port: 8000
      weight: 90
    - name: istio-ingressgateway # Newly deployed load balancer service
      namespace: GATEWAY_NAMESPACE
      port: 80
      weight: 10

使用參照授權，授予跨命名空間參照的權限。

如要允許應用程式命名空間 (預設) 中的 HTTPRoute 存取閘道命名空間 (istio-ingress) 中的 loadbalancer 服務，您可能需要建立參照授權。這項資源可做為安全控管機制，明確定義允許的跨命名空間參照。

以下 istio-ingress-grant.yaml 說明參考授權的範例：

apiVersion: gateway.networking.k8s.io/v1beta1
kind: ReferenceGrant
metadata:
  name: istio-ingressgateway-grant
  namespace: istio-ingress # Namespace of the referenced resource
spec:
  from:
  - group: gateway.networking.k8s.io
    kind: HTTPRoute 
    namespace: MY_APP_NAMESPACE # Namespace of the referencing resource
  to:
  - group: ""               # Core Kubernetes API group for Services
    kind: Service
    name: istio-ingressgateway # Loadbalancer Service of the new ingress gateway

套用推薦補助金：

kubectl apply -f istio-ingress-grant.yaml -n GATEWAY_NAMESPACE

驗證對現有外部 IP 位址的要求 (例如 34.57.246.68) 未失敗。下列 check-traffic-flow.sh 說明如何編寫指令碼，檢查要求失敗情形：

# Update the following values based on your application setup
external_ip="34.57.246.68" # Replace with existing external IP
url="http://$external_ip/get"
host_name="httpbin.example.com"

# Counter for successful requests
success_count=0

# Loop 50 times
for i in {1..50}; do
  # Perform the curl request and capture the status code
  status_code=$(curl -s -HHost:"$host_name" -o /dev/null -w "%{http_code}" "$url")
  # Check if the request was successful (status code 200)
  if [ "$status_code" -eq 200 ]; then
    ((success_count++))  # Increment the success counter
  else
    echo "Request $i: Failed with status code $status_code"
  fi
done

# After the loop, check if all requests were successful
if [ "$success_count" -eq 50 ]; then
  echo "All 50 requests were successful!"
else
  echo "Some requests failed.  Successful requests: $success_count"
fi

執行指令碼，確認無論流量路徑為何，要求都不會失敗：
```
chmod +x check-traffic-flow.sh
./check-traffic-flow.sh
```

要求流程，流量會分配到現有閘道和新的 Istio Ingress 閘道

逐步提高流量百分比

如果現有外部 IP 位址沒有任何要求失敗 (例如 34.57.246.68)，請調整 HTTPRoute 中的後端權重，逐步將更多流量轉移至新的 Istio Ingress 閘道。以 10%、20% 等小幅度增加 istio-ingressgateway 的權重，並減少舊閘道的權重。

使用下列指令更新現有的 HTTPRoute：

kubectl edit httproute httpbin-route -n MY_APP_NAMESPACE

完整遷移流量並移除舊閘道

新的 Istio Ingress Gateway 展現穩定效能並成功處理要求後，請將所有流量轉移至該閘道。更新 HTTPRoute，將舊閘道的後端權重設為 0，新閘道的後端權重則設為 100。
流量完全路由至新閘道後，請更新應用程式主機名稱 (例如 httpbin.example.com) 的外部 DNS 記錄，指向在「佈建新的 Istio Ingress 閘道」中建立的負載平衡器服務外部 IP 位址。

最後，請刪除舊閘道和相關聯的資源：

kubectl delete gateway OLD_GATEWAY -n GATEWAY_NAMESPACE
kubectl delete service OLD_GATEWAY_SERVICE -n GATEWAY_NAMESPACE

直接遷移