[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-08-13。"],[],[],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."]]
