将 Istio ServiceEntry 迁移到 GCPBackend for Cloud Run

本页面介绍了如何从 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 路由到 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 响应。