將 Istio ServiceEntry 遷移至 Cloud Run 的 GCPBackend

本頁面說明如何從 ServiceEntry 遷移至 GCPBackend，並展示 Istio 的流量管理功能如何確保順利且安全地完成遷移。

遷移至 GCPBackend 可帶來下列優勢：

  1. 簡化應用程式程式碼：您不必在應用程式中手動注入 IAM JWT，可降低複雜度和潛在錯誤。
  2. 提升安全性：善用自動 IAM JWT 注入功能，確保 GKE 和 Cloud Run 之間的通訊安全。
  3. 流暢的遷移作業：利用流量拆分和鏡像功能安全地遷移流量，不會中斷應用程式。
  4. 提升管理效率：簡化設定和管理作業。

事前準備

以下各節假設您已：

  1. 已啟用 Cloud Service Mesh 的 GKE 叢集。
  2. Istio 服務項目。
  3. 為 Cloud Run 服務設定 GCPBackend 資源。

建立或修改現有 VirtualService，將 ServiceEntry 和 GCPBackend 都納入目的地

您可以使用流量拆分功能，逐步將流量從 ServiceEntry 轉移至 GCPBackend。您應先將一小部分的流量導向 GCPBackend，然後逐漸增加流量，同時監控是否有任何問題。

以下範例說明如何將 10% 的要求遷移至 GCPBackend。

cat <<EOF > virtual-service.yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: gcpbackend-migration
  namespace: NAMESPACE
spec:
  hosts:
  - service-entry.com
  http:
  - route:
    - destination:
        host: gcpbackend.com
      weight: 10 # 10% traffic to gcp backend.
    - destination:
        host: service-entry.com
      weight: 90 # 90% traffic to service entry
EOF
kubectl apply -f virtual-service.yaml

其中：

  • NAMESPACE 是命名空間名稱。

在這個例子中：

  • VIRTUAL_SERVICE為 gcpbackend-migration。
  • SERVICE_ENTRY_HOSTNAME為 service-entry.com。
  • GCP_BACKEND_HOSTNAME為 gcpbackend.com。

(選用) 設定 VirtualService 以進行流量鏡像

為進一步確保順利轉換，您可以設定流量鏡像，將流量副本傳送至 GCPBackend，同時仍主要將流量導向 ServiceEntry。這樣一來，您就能測試及驗證 GCPBackend 設定，而不會影響主要流量。詳情請參閱 Istio Virtual Service API。

驗證功能

請參閱應用程式記錄或 Cloud Service Mesh 指標，檢查對 $SERVICE_ENTRY_HOSTNAME 的要求錯誤率。現在應該不會再出現錯了。

如要在應用程式外部進行測試，可以部署 curl 用戶端。如果要求是使用 GCPBackend API 路由至 Cloud Run，則要求不需要明確附加 IAM 權杖，因為 Cloud Service Mesh 會自動附加。

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: testcurl
  namespace: default
spec:
  containers:
  - name: curl
    image: curlimages/curl
    command: ["sleep", "3000"]
EOF

kubectl exec testcurl -c curl -- curl "$SERVICE_ENTRY_HOSTNAME"

輸出內容應為有效的 HTTP 200 回應。