[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["難以理解","hardToUnderstand","thumb-down"],["資訊或程式碼範例有誤","incorrectInformationOrSampleCode","thumb-down"],["缺少我需要的資訊/範例","missingTheInformationSamplesINeed","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間:2025-09-04 (世界標準時間)。"],[],[],null,["Migrate Istio ServiceEntry to GCPBackend for Compute Engine VMs\n| **Preview**\n|\n|\n| This product or feature is subject to the \"Pre-GA Offerings Terms\" in the General Service Terms section\n| of the [Service Specific Terms](/terms/service-terms#1).\n|\n| Pre-GA products and features are available \"as is\" and might have limited support.\n|\n| For more information, see the\n| [launch stage descriptions](/products#product-launch-stages).\n| **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](/service-mesh/docs/overview).\n\nThis page shows you how to migrate from ServiceEntry to GCPBackend,\ndemonstrating how Istio's traffic management capabilities can ensure a smooth\nand safe transition.\n\nMigrating to GCPBackend provides the following benefits:\n\n1. Endpoint Discovery - VM endpoints in the Backend Service are automatically updated when VM instances are added or removed.\n2. Centralized Health Checking - VM endpoints are health checked and traffic is automatically routed away from unhealthy to healthy backends.\n3. Global load balancing and advanced load balancing algorithms - VM endpoints can be deployed in multiple regions. Use our load balancing algorithms to configure load balancing behavior across these regions. See https://cloud.google.com/service-mesh/docs/service-routing/advanced-load-balancing-overview and https://cloud.google.com/service-mesh/docs/service-routing/advanced-load-balancing-overview for more details.\n4. Seamless migration: Utilize traffic splitting and mirroring to safely migrate traffic without disrupting the application.\n5. Enhanced manageability: Benefit from the streamlined configuration and management.\n\nBefore you begin\n\nThe following sections assume that you have:\n\n1. [A GKE Cluster with Cloud Service Mesh enabled](/service-mesh/docs/onboarding/provision-control-plane).\n2. An Istio Service Entry.\n3. Configured GCPBackend resource for [Compute Engine VM](/service-mesh/docs/route-to-Compute Engine-vms#configure_a_service_as_a_gcpbackend).\n\nCreate or modify the existing VirtualService to include both the ServiceEntry and GCPBackend as destinations\n\nYou can use traffic splitting to gradually shift traffic from the ServiceEntry\nto the GCPBackend. You should start with a small percentage of traffic directed\nto the GCPBackend and gradually increase it while monitoring for any issues.\n\nThe following example describes migrating 10% of the requests to the GCPBackend. \n\n cat \u003c\u003cEOF \u003e virtual-service.yaml\n apiVersion: networking.istio.io/v1alpha3\n kind: VirtualService\n metadata:\n name: gcpbackend-migration\n namespace: \u003cvar translate=\"no\"\u003eNAMESPACE\u003c/var\u003e\n spec:\n hosts:\n - \u003cvar translate=\"no\"\u003eservice-entry.com\u003c/var\u003e\n http:\n - route:\n - destination:\n host: \u003cvar translate=\"no\"\u003egcpbackend.com\u003c/var\u003e\n weight: 10 # 10% traffic to gcp backend.\n - destination:\n host: \u003cvar translate=\"no\"\u003eservice-entry.com\u003c/var\u003e\n weight: 90 # 90% traffic to service entry\n EOF\n kubectl apply -f virtual-service.yaml\n\nWhere:\n\n- \u003cvar translate=\"no\"\u003eNAMESPACE\u003c/var\u003e is the namespace name.\n\nIn this example:\n\n- \u003cvar translate=\"no\"\u003eVIRTUAL_SERVICE\u003c/var\u003e is `gcpbackend-migration`.\n- \u003cvar translate=\"no\"\u003eSERVICE_ENTRY_HOSTNAME\u003c/var\u003e is `service-entry.com`.\n- \u003cvar translate=\"no\"\u003eGCP_BACKEND_HOSTNAME\u003c/var\u003e is `gcpbackend.com`.\n\n(Optional) Configure VirtualService for Traffic Mirroring\n\nTo further ensure a smooth transition, you can configure traffic mirroring to\nsend a copy of the traffic to the GCPBackend while still primarily directing\ntraffic to the ServiceEntry. This allows for testing and validation of the\nGCPBackend configuration without impacting the primary traffic flow. For more\ninformation, see the [Istio Virtual Service API](https://istio.io/latest/docs/reference/config/networking/virtual-service/#HTTPMirrorPolicy).\n\nValidate functionality\n\nRefer to your application logs or Cloud Service Mesh metrics to check error\nrate of requests to $SERVICE_ENTRY_HOSTNAME. There shouldn't be any errors.\n\nTo test outside of your application, you can deploy a curl client. If the\nrequest is routed to using the GCPBackend API then the request doesn't\nneed an IAM token explicitly attached to the request because\nCloud Service Mesh attaches it automatically. \n\n cat \u003c\u003cEOF | kubectl apply -f -\n apiVersion: v1\n kind: Pod\n metadata:\n name: testcurl\n namespace: default\n spec:\n containers:\n - name: curl\n image: curlimages/curl\n command: [\"sleep\", \"3000\"]\n EOF\n\n kubectl exec testcurl -c curl -- curl \"$SERVICE_ENTRY_HOSTNAME\"\n\nThe output should be a valid HTTP 200 response."]]