Migrate Istio ServiceEntry to GCPBackend for Cloud Run

Preview

This product or feature is subject to the "Pre-GA Offerings Terms" in the General Service Terms section of the Service Specific Terms. Pre-GA products and features are available "as is" and might have limited support. For more information, see the launch stage descriptions.

Note: This guide only supports Cloud Service Mesh with Istio APIs and does not support Google Cloud APIs. For more information see, Cloud Service Mesh overview.

This page shows you how to migrate from ServiceEntry to GCPBackend, demonstrating how Istio's traffic management capabilities can ensure a smooth and safe transition.

Migrating to GCPBackend provides the following benefits:

1. Simplified application code: you can eliminate the need for manual IAM JWT injection in the application, reducing complexity and potential errors.
2. Improved security: take advantage of automatic IAM JWT injection for more secure communication between GKE and Cloud Run.
3. Seamless migration: Utilize traffic splitting and mirroring to safely migrate traffic without disrupting the application.
4. Enhanced manageability: Benefit from the streamlined configuration and management.

Before you begin

The following sections assume that you have:

1. A GKE Cluster with Cloud Service Mesh enabled.
2. A Cloud Run service as Istio Service Entry.
3. Configured GCPBackend resource.

Create or modify the existing VirtualService to include both the ServiceEntry and GCPBackend as destinations

You can use traffic splitting to gradually shift traffic from the ServiceEntry to the GCPBackend. You should start with a small percentage of traffic directed to the GCPBackend and gradually increase it while monitoring for any issues.

The following example describes migrating 10% of the requests to the 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

Where:

• NAMESPACE is the namespace name.

In this example:

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

(Optional) Configure VirtualService for Traffic Mirroring

To further ensure a smooth transition, you can configure traffic mirroring to send a copy of the traffic to the GCPBackend while still primarily directing traffic to the ServiceEntry. This allows for testing and validation of the GCPBackend configuration without impacting the primary traffic flow. For more information, see the Istio Virtual Service API.

Validate functionality

Refer to your application logs or Cloud Service Mesh metrics to check error rate of requests to $SERVICE_ENTRY_HOSTNAME. There shouldn't be any errors.

To test outside of your application, you can deploy a curl client. If the request is routed to CloudRun using the GCPBackend API then the request doesn't need an IAM token explicitly attached to the request because Cloud Service Mesh attaches it automatically.

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"

The output should be a valid HTTP 200 response.