이 가이드에서는 자동 Envoy 배포를 위한 추가 옵션 및 작업에 대한 정보를 제공합니다.
추가 인스턴스 템플릿 만들기 옵션
자동 Envoy 프록시 배포를 위한 인스턴스 템플릿을 만들 때 다음 매개변수를 사용하여 배포의 일부 측면과 프록시 동작을 정의할 수 있습니다.
매개변수
값 및 설명
필수 또는 선택사항
--service-proxy
enabled
VM에 서비스 프록시 및 에이전트를 설치하고 구성할지 여부를 제어합니다.
서비스 프록시를 자동으로 배포하고 구성하려면 필수 항목입니다. 이 설정을 생략하면 서비스 프록시가 설치 또는 구성되지 않습니다.
--service-proxy:serving-ports
세미콜론으로 구분된 포트 목록.
애플리케이션/워크로드가 작동하는 포트입니다. 서비스 프록시가 인바운드 트래픽을 가로채서 localhost의 지정된 제공 포트로 이를 전달합니다.
선택사항
이 플래그를 생략하면 서비스 프록시가 워크로드의 아웃바운드 트래픽만 처리합니다. 인바운드 트래픽은 서비스 프록시로 처리되지 않습니다.
--service-proxy:proxy-port
단일 포트
서비스 프록시가 리슨하는 포트입니다. VM이 트래픽을 가로채고 이 포트로 리디렉션하여 서비스 프록시가 처리하도록 합니다.
선택사항.
이 플래그를 생략하면 기본값은 15001입니다.
--service-proxy:network
유효한 VPC 네트워크의 이름입니다. 서비스 프록시 컨트롤 플레인에서 서비스 프록시의 동적 구성을 생성하는 데 사용되는 Google Cloud VPC 네트워크입니다.
VM이 둘 이상의 네트워크에 있는 경우 필요합니다. 이 경우가 아니면 선택사항입니다. 이 플래그를 생략하면 VM 인스턴스 템플릿을 만드는 동안 --network 매개변수를 사용하여 지정된 값이 사용됩니다.
--service-proxy:tracing
ON 또는 OFF 서비스 프록시가 분산 추적 정보를 생성하도록 사용 설정합니다. ON로 설정하면 서비스 프록시의 제어 영역이 요청 ID 기반 추적을 사용 설정하는 구성을 생성합니다.
자세한 내용은 Envoy 프록시용 generate_request_id 문서를 참조하세요.
선택사항. 이 플래그를 생략하면 추적이 사용 설정되지 않습니다.
--service-proxy:access-log
제어 영역에 의해 서비스 프록시로 전송되는 액세스 로그의 파일 경로입니다. 모든 수신 및 발신 요청은 이 파일에 기록됩니다. 자세한 내용은 Envoy 프록시의 파일 액세스 로그 문서를 참조하세요.
안에 큰따옴표(")로 지정되어 세미콜론(;)으로 구분된 포트 또는 포트 범위 목록이며, 리디렉션에서 제외됩니다. intercept-all-outbound-traffic 플래그가 설정된 경우에만 적용됩니다. 이 옵션에 gcloud beta를 사용합니다.
예를 들면 다음과 같습니다.
exclude-outbound-port-ranges="81;8080-8090"
선택사항.
--service-proxy:scope(미리보기)
scope 옵션은 Gateway 리소스에 대한 논리적 구성 경계를 정의합니다.
VM이 시작되면 서비스 프록시가 Cloud Service Mesh와 통신하여 이 범위 이름의 게이트웨이에 연결된 경로에 해당하는 라우팅 정보를 검색합니다. scope가 지정된 경우 네트워크 값이 무시됩니다. scope 및 mesh 값은 동시에 지정할 수 없습니다. 이 옵션에 gcloud beta를 사용합니다.
선택사항.
--service-proxy:mesh(미리보기)
mesh 옵션은 Mesh 리소스에 대한 논리적 구성 경계를 정의합니다.
VM이 시작되면 서비스 프록시가 Cloud Service Mesh와 통신하여 이 메시 이름의 Mesh에 연결된 경로에 해당하는 라우팅 정보를 검색합니다. mesh가 지정된 경우 네트워크 값이 무시됩니다. scope 및 mesh 값은 동시에 지정할 수 없습니다. 이 옵션에 gcloud beta를 사용합니다.
선택사항.
--service-proxy:project-number(미리보기)
project-number 옵션은 Mesh 및 Gateway 리소스가 생성되는 프로젝트를 지정합니다. 지정하지 않으면 인스턴스가 있는 프로젝트가 사용됩니다. 이것은 새 서비스 경로 지정 API에만 적용됩니다.
선택사항.
--service-proxy-labels
key=value 형식의 키/값 쌍입니다. 서비스 프록시에 적용할 수 있는 라벨입니다. 이러한 내용은 Envoy 프록시의 부트스트랩 메타데이터에 반영됩니다. 라벨은 프록시 메타데이터로 설정하려는 모든 key=value 쌍일 수 있습니다 (예: 구성 필터링과 함께 사용). 애플리케이션 및 버전 라벨에 이러한 플래그를 사용할 수 있습니다(예: app=review 또는 version=canary). 둘을 함께 사용할 수도 있습니다.
선택사항.
예를 들어 다음 gcloud 명령어는 proxy-it이라는 인스턴스 템플릿을 만듭니다. 이 템플릿으로 생성된 인스턴스에는 Envoy 프록시와 서비스 프록시 에이전트가 설치되어 있습니다.
다음 다이어그램은 제공 포트를 8080으로 지정하는 경우의 트래픽 흐름을 보여줍니다. 포트 8080에 대한 인바운드 TCP 연결은 iptable에 의해 가로채기를 당하여 Envoy 프록시로 리디렉션된 다음 TCP 포트 8080에서 리슨하는 VM의 애플리케이션으로 전달됩니다. 또한 다음 사항도 적용됩니다.
Cloud Service Mesh에 구성된 서비스 VIP의 모든 아웃바운드 연결은 netfilter를 구성하는 iptable에 의해 가로채기를 당합니다. netfilter는 네트워크 스택을 통과하는 해당 트래픽이 가로채기를 당하고 Envoy 프록시로 리디렉션되도록 합니다. 그러면 Cloud Service Mesh가 구성된 방식에 따라 트래픽이 부하 분산됩니다.
다른 모든 인바운드 연결은 iptables에 의해 가로채기를 당하지 않으며 VM에 직접 전달됩니다.
외부 엔드포인트에 대한 모든 연결은 중단 없이 외부 IP 주소로 직접 전달됩니다.
모든 UDP 트래픽은 iptable에 의해 중단되지 않고 대상으로 직접 전달됩니다.
다음 다이어그램을 참조하세요.
Cloud Service Mesh를 사용한 트래픽 분산(확대하려면 클릭)
다이어그램의 트래픽 흐름은 다음과 같습니다.
대상 포트 80이 있는 인바운드 트래픽은 가로채기를 당하고 포트에서 리슨하는 서비스로 직접 라우팅되지 않습니다.
대상 포트 8080이 있는 인바운드 트래픽은 가로채기를 당하고 Envoy 리스너 포트로 리디렉션됩니다.
Envoy는 (2)에서 localhost 포트 8080에서 리슨하는 서비스 2로 트래픽을 전달합니다.
Cloud Service Mesh 전달 규칙 VIP 및 포트를 대상으로 하는 아웃바운드 트래픽은 가로채기를 당하고 Envoy 리스너 포트로 리디렉션됩니다.
Envoy는 트래픽을 (4)에서 대상 Cloud Service Mesh 백엔드 서비스 백엔드의 엔드포인트로 전달합니다.
Cloud Service Mesh VIP 및 포트를 대상으로 하는 아웃바운드 트래픽이며 가로채기를 당하지 않으며 외부 서비스로 직접 라우팅됩니다.
라벨 사용
Cloud Service Mesh 메타데이터 필터링에 사용할 라벨을 지정하거나 Envoy 프록시에 대한 액세스 로깅을 사용 설정하려면 --service-proxy-labels 또는 --service-proxy access-log 파라미터를 사용합니다.
Envoy 프록시는 VM의 서비스에 대한 상태 확인 포트를 가로챌 수 있습니다. 이렇게 하면 상태 확인 프로브가 애플리케이션과 Envoy 프록시에 대해 보고합니다. Envoy 프록시가 올바르게 실행되지 않으면 트래픽이 VM으로 전달되지 않습니다. 예를 들면 다음과 같습니다.
업데이터를 호출할 때 --min-ready 매개변수를 3분 이상의 값으로 설정합니다. --min-ready 매개변수를 사용하면 VM이 업데이트된 후 관리형 인스턴스 그룹이 대기하다가 다음 VM 업데이트를 진행할 수 있습니다.
이 매개변수가 없으면 새로 만든 VM이 Envoy 및 서비스 프록시 에이전트를 완전히 부팅할 시간이 없으며 업데이트가 너무 빨리 진행됩니다.
관리형 인스턴스 그룹에서 순차적 업데이트를 수행하려면 다음 단계를 따르세요.
위에서 설명한 대로 서비스 프록시 정보로 새 인스턴스 템플릿을 만듭니다.
서비스 프록시 정보를 포함하고 있고 목표가 프록시 소프트웨어의 가장 최신인 안정적인 버전으로 업데이트하는 것일 경우 인스턴스 템플릿의 원래 버전이 업데이트에 사용될 수 있습니다.
관리형 인스턴스 그룹의 순차적 업데이트를 수행합니다. REPLACE가 업데이터가 수행해야 하는 최소 작업으로 설정되어 있는지 확인합니다. 인스턴스 그룹이 최신 버전의 프록시 소프트웨어를 설치하고 인스턴스 템플릿에 지정된 대로 구성합니다.
업데이트 처리를 사용하여 관리형 인스턴스 그룹에서 서비스 프록시 구성요소를 삭제할 수도 있습니다.
--service-proxy 플래그를 지정하지 않고 새 인스턴스 템플릿을 만듭니다.
관리형 인스턴스 그룹 업데이트 프로세스를 사용하여 순차적 업데이트를 수행합니다.
이렇게 하면 VM에서 Envoy 프록시가 삭제됩니다. 관리형 인스턴스 그룹이 백엔드 서비스에 연결된 유일한 MIG인 경우 Cloud Service Mesh를 설정할 때 만든 Cloud Service Mesh 구성을 삭제하고자 할 수 있습니다.
[[["이해하기 쉬움","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,["# Options for Compute Engine VM setup using automatic Envoy deployment\n====================================================================\n\n| **Note:** This guide only supports Cloud Service Mesh with Google Cloud APIs and does not support Istio APIs. For more information see, [Cloud Service Mesh overview](/service-mesh/docs/overview).\n\nThis guide provides you with information on additional options and tasks for\nautomated Envoy deployment.\n\nAdditional instance template creation options\n---------------------------------------------\n\nWhen you create an instance template for automated Envoy proxy deployment, you\ncan use the following parameters to define some aspects of the deployment and\nthe behavior of the proxies.\n\nFor example, the following `gcloud` command creates an instance template\ncalled `proxy-it`. Instances created from this template have the Envoy proxy and\nservice proxy agent installed. \n\n```\ngcloud compute instance-templates create proxy-it \\\n --service-proxy enabled\n```\n\nIn the following example, the instance template is called `proxy-it`, the Envoy\nproxy and service proxy agent are installed, the serving port and proxy port are\nset, tracing is enabled, and a label is defined. \n\n```\ngcloud compute instance-templates create proxy-it \\\n --service-proxy enabled,serving-ports=8080,proxy-port=15001,tracing=ON \\\n --service-proxy-labels version=canary\n```\n\nThe following diagram illustrates the traffic flow when you specify the serving\nport as `8080`. Inbound TCP connections to port `8080` are intercepted by\niptables and redirected to the Envoy proxy, which then passes them to the\napplication on your VM listening on TCP port `8080`. In addition:\n\n- All outbound connections to the VIPs of services configured in Cloud Service Mesh are intercepted by iptables, which configures netfilter. Netfilter ensures that the corresponding traffic traversing the network stack is intercepted and redirected to the Envoy proxy. The traffic is then load balanced based on how you have Cloud Service Mesh configured.\n- All other inbound connections are not intercepted by iptables, and are passed directly services on the VM.\n- All connections to external endpoints are directly passed to external IP addresses without being intercepted.\n- All UDP traffic is passed directly to the destination without being intercepted by iptables.\n\nThis is illustrated in the following diagram.\n[](/static/service-mesh/docs/images/td-auto-envoy.svg) Traffic distribution with Cloud Service Mesh (click to enlarge)\n\nThe traffic flows in the diagram are as follows:\n\n1. Inbound traffic with destination port `80`, not intercepted and routed directly to service listening on the port.\n2. Inbound traffic with destination port `8080`, intercepted and redirected to the Envoy listener port.\n3. Envoy forwards traffic from (2) to service 2 listening on localhost port `8080`.\n4. Outbound traffic destined to Cloud Service Mesh forwarding rule VIP and port, intercepted and redirected to Envoy listener port.\n5. Envoy forwards traffic from (4) to endpoint of backend of destination Cloud Service Mesh backend service.\n6. Outbound traffic destined to non-Cloud Service Mesh VIP and port, not intercepted, and routed directly to external service.\n\nUsing labels\n------------\n\nIf you want to specify labels to use with Cloud Service Mesh metadata\nfiltering or enable access logging for the Envoy proxies, use the\n`--service-proxy-labels` or `--service-proxy access-log` parameters.\n\nFor example: \n\n```\ngcloud compute instance-templates create td-vm-template-auto \\\n --service-proxy enabled,access-log=/var/log/envoy/access.log,network=default \\\n --service-proxy-labels myapp=review,version=canary\n```\n\nThe Envoy proxy can intercept the health check ports for services on the VMs. If\nyou do this, the health check probes report on your application and on the Envoy\nproxies. Traffic is not directed to the VM if the Envoy proxy is not running\ncorrectly. For example: \n\n```\ngcloud compute instance-templates create td-vm-template-auto \\\n --service-proxy=enabled,serving-ports=\"80;8080\"\n```\n\nUsing the managed instance group update process\n-----------------------------------------------\n\nIf you used the [automated process](#auto-envoy-config) for configuring the\nEnvoy proxies, you can use the [managed instance group update process](/compute/docs/instance-groups/rolling-out-updates-to-managed-instance-groups)\nto update your managed instance group. Use this process to:\n\n- Add the service proxy components to an existing managed instance group and enroll it in a Cloud Service Mesh network.\n- Update the service proxy components on the VMs.\n\nBefore you perform the rolling update, do the following.\n\n1. Set [connection draining](/load-balancing/docs/enabling-connection-draining) on the backend service to a value of at least 30 seconds.\n2. Use the `--min-ready` parameter, set to a value of 3 minutes or more, when you call the updater. The `--min-ready` parameter makes the managed instance group wait after a VM is updated before proceeding to update the next VM. Without this, the newly-created VM has no time to fully boot up Envoy and the service proxy agent, and the update proceeds too quickly.\n\nTo perform the rolling update on the managed instance group, follow these\nsteps.\n\n1. Create a new instance template, as described above, with the service proxy information. The original version of the instance template can be used for the update if it contains the service proxy information and your goal is to update to the most recent stable version of the proxy software.\n2. Perform a rolling update of the managed instance group. Make sure that you set `REPLACE` as the [minimum action that the Updater must perform](/compute/docs/instance-groups/rolling-out-updates-to-managed-instance-groups#minimal_action). The instance group installs the latest version of the proxy software and configures it as specified in the instance template.\n\nYou can also remove the service proxy components from a managed instance group\nusing the update process:\n\n1. Create a new instance template without specifying the flag `--service-proxy`.\n\n2. Perform a rolling update using the managed instance group update process.\n\nThis removes the Envoy proxy from your VMs. If that managed instance group was\nthe only MIG attached to the backend service, you might want to remove the\nCloud Service Mesh configuration that you created when you set up\nCloud Service Mesh."]]
