将 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. 将 Cloud Run 服务用作 Istio 服务条目。
  3. 已配置 GCPBackend 资源。

创建或修改现有 VirtualService，将 ServiceEntry 和 GCPBackend 都添加为目的地

您可以使用流量拆分功能，将流量从 ServiceEntry 逐步转移到 GCPBackend。您应先将一小部分流量引导至 GCPBackend，然后逐步增加，同时监控是否存在任何问题。

以下示例介绍了如何将 10% 的请求迁移到 GCPBackend。

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

其中：

  • NAMESPACE 是命名空间名称。

在此示例中：

  • VIRTUAL_SERVICEE 是 cr-gcpbackend-migration。
  • SERVICE_ENTRY_HOSTNAME 是 cr-service-entry.com。
  • GCP_BACKEND_HOSTNAME 是 =cr-gcpbackend.com。

（可选）配置 VirtualService 以实现流量镜像

为了进一步确保顺利过渡，您可以配置流量镜像，将流量的副本发送到 GCPBackend，同时仍主要将流量定向到 ServiceEntry。这样，您就可以在不影响主要流量流的情况下测试和验证 GCPBackend 配置。如需了解详情，请参阅 Istio Virtual Service API。

验证功能

请参阅应用日志或 Cloud Service Mesh 指标，检查对 $SERVICE_ENTRY_HOSTNAME 的请求错误率。应该没有任何错误。

如需在应用之外进行测试，您可以部署 curl 客户端。如果请求是使用 GCPBackend API 路由到 CloudRun，则无需向请求显式附加 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 响应。