이 페이지에서는 ServiceEntry에서 GCPBackend로 마이그레이션하는 방법을 설명하며, Istio의 트래픽 관리 기능을 사용하여 원활하고 안전하게 전환하는 방법을 보여줍니다.
GCPBackend로 마이그레이션하면 다음과 같은 이점이 있습니다.
엔드포인트 검색 - 백엔드 서비스의 VM 엔드포인트는 VM 인스턴스가 추가되거나 삭제될 때 자동으로 업데이트됩니다.
중앙 집중식 상태 점검 - VM 엔드포인트의 상태가 확인되고 트래픽이 비정상 백엔드에서 정상 백엔드로 자동 라우팅됩니다.
글로벌 부하 분산 및 고급 부하 분산 알고리즘 - VM 엔드포인트를 여러 리전에 배포할 수 있습니다. Google의 부하 분산 알고리즘을 사용하여 이러한 리전에서 부하 분산 동작을 구성합니다. 자세한 내용은 https://cloud.google.com/service-mesh/v1.24/docs/service-routing/advanced-load-balancing-overview 및 https://cloud.google.com/service-mesh/v1.24/docs/service-routing/advanced-load-balancing-overview를 참조하세요.
원활한 마이그레이션: 트래픽 분할 및 미러링을 활용하여 애플리케이션을 중단하지 않고도 트래픽을 안전하게 마이그레이션합니다.
ServiceEntry와 GCPBackend를 모두 대상으로 포함하도록 VirtualService를 만들거나 기존 VirtualService를 수정
트래픽 분할을 사용하여 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.comhttp:
-route:
-destination:
host:gcpbackend.comweight:10# 10% traffic to gcp backend.-destination:
host:service-entry.comweight:90# 90% traffic to service entry
EOF
kubectlapply-fvirtual-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 Service Mesh에서 자동으로 연결하므로 요청에 명시적으로 연결된 IAM 토큰이 필요하지 않습니다.
[[["이해하기 쉬움","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(UTC)"],[],[],null,["# Migrate Istio ServiceEntry to GCPBackend for Compute Engine VMs\n===============================================================\n\n|\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/v1.24/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/v1.24/docs/service-routing/advanced-load-balancing-overview and https://cloud.google.com/service-mesh/v1.24/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----------------\n\nThe following sections assume that you have:\n\n1. [A GKE Cluster with Cloud Service Mesh enabled](/service-mesh/v1.24/docs/onboarding/provision-control-plane).\n2. An Istio Service Entry.\n3. Configured GCPBackend resource for [Compute Engine VM](/service-mesh/v1.24/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------------------------------------------------------------------------------------------------------------\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----------------------\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."]]