[[["易于理解","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-09-04。"],[],[],null,["# Set up advanced configurations\n==============================\n\nThis document contains notes that might be helpful when configuring\nCloud Service Mesh.\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\nConfiguring a single Compute Engine VM for Cloud Service Mesh\n-------------------------------------------------------------\n\nUse this procedure as an example of how sidecar proxy deployment and traffic\ninterception can be implemented to provide a VM with access to\nCloud Service Mesh services.\n\nTo use this procedure, you need to have Docker installed. Follow\n[Docker's instructions](https://docs.docker.com/engine/install/) for installing Docker Engine.\n\nIf you are following this process to configure Cloud Service Mesh on a\nsingle VM, some setup tasks require that you have access to a Linux host. The\nhost can be a local machine or a VM running on your Virtual Private Cloud network.\n\nFirst, download and prepare the configuration files and sample scripts.\n\n1. Log in to the Linux host you are using during the setup process.\n\n2. Download the archive of required files to the Linux host and untar the\n archive:\n\n ```\n wget https://storage.googleapis.com/traffic-director/traffic-director-xdsv3.tar.gz\n tar -xzvf traffic-director-xdsv3.tar.gz; cd traffic-director-xdsv3\n ```\n\n The archive contains the following files:\n - **sidecar.env** -- Config file with environment variables.\n - **iptables.sh** -- Script for setting up netfilter rules.\n - **bootstrap_template.yaml** -- Bootstrap template file for Envoy.\n - **run.sh** -- Top-level script that uses the `sidecar.env` configuration file to set up `iptables` for interception and to run the Envoy sidecar proxy.\n3. On each host that runs a sidecar proxy, create a system user to run the\n Envoy proxy process. This is the Envoy proxy user. Login is disabled for\n the Envoy proxy user.\n\n ```\n sudo adduser --system --disabled-login envoy\n ```\n4. Edit the `sidecar.env` file to modify the configuration. Read the inline\n comments in the configuration file for a detailed description of each\n variable.\n\n 1. In the `sidecar.env` file, set the `ENVOY_USER` variable to the username that you choose to be the Envoy proxy user.\n\nNext, for each VM host that runs applications using Cloud Service Mesh, perform\nthe following steps:\n\n1. Copy the entire `traffic-director-xdsv3` directory with the modified `sidecar.env` file to each VM host running applications that you expect to use Cloud Service Mesh.\n2. Add the `run.sh` script to your system's startup script, which ensures that the script is run after every VM reboot.\n3. On each VM host, run the `run.sh` script:\n\n ```\n cd traffic-director-xdsv3\n sudo ./run.sh start\n ```\n4. Verify that the Envoy proxy started correctly.\n\n ```\n sudo ./run.sh status\n ```\n\n You should see the following output: \n\n ```\n OK: Envoy seems to be running.\n OK: Traffic interception seems to be enabled.\n ```\n\n You can verify traffic interception direction by using the following: \n\n ```\n sudo iptables -S -t nat | grep ISTIO_REDIRECT\n ```\n\n The expected output is: \n\n ```\n -N ISTIO_REDIRECT\n -A ISTIO_OUTPUT -j ISTIO_REDIRECT\n -A ISTIO_REDIRECT -p tcp -j REDIRECT --to-ports 15001`\n ```\n\n \u003cbr /\u003e\n\n| **Note:** With this configuration, all TCP traffic, except traffic on port tcp/22, is intercepted by the sidecar proxy. Traffic to TCP services that are not configured in Cloud Service Mesh are silently discarded by the proxy. To avoid losing traffic, follow the [Advanced traffic interception\n| configuration](#advanced_interception) section below.\n\nRouting rule maps\n-----------------\n\nThere are two ways to configure routing in a routing rule map.\n\nYou can enable routing based on the actual destination VIP and port of the\nservice. If you configure a VIP of your service as the `IPAddress` parameter of\nthe forwarding rule, only traffic destined to this address, and the associated\nport, is matched, and routed, based on the host and path parameters\nspecified in the URL map.\n\nAlternatively, you can set the address of your forwarding rule to `0.0.0.0`.\nThis will configure the proxies to only match traffic based on the destination\nport, regardless of the destination IP address of the request. Traffic is then\nrouted based on the host and path parameters specified in the URL map.\n\nBased on these two approaches, hostnames, as configured in the host rules,\nassociated with a destination VIP and port pair, or with a destination port\n(when VIP is `0.0.0.0`), must be unique within your service mesh configuration.\nThat is, you cannot have two different services, with different sets of\nbackends, that both use the same hostname.\n\nRegardless of the method selected, traffic to the VIP that your service\nhostname/FQDN resolves to, and the port that your service is listening on, must\nbe intercepted and redirected to the sidecar proxy. Refer to\n[Configuring a single Compute Engine VM for\nCloud Service Mesh](#per_host_config) for full host configuration details.\n\nEach forwarding rule in a VPC network must have a unique combination of IP\naddress and port per VPC network, including the `0.0.0.0` address. If you\ncreate more than one forwarding rule with the same IP address and port in a\nparticular VPC network, only the first forwarding rule is valid. The others are\nignored.\n\nTo avoid losing traffic, follow the [Advanced traffic interception\nconfiguration](#advanced_interception) section below.\n\nAdvanced traffic interception configuration\n-------------------------------------------\n\nIf your VMs run applications that need access to services configured by\nCloud Service Mesh, you must install a sidecar proxy and configure traffic\ninterception on the VMs to allow the sidecar proxy to manage traffic routing to\nthe backends of those services.\n| **Note:** If the managed instance group VMs serve as a backend only and its applications do not need access to Cloud Service Mesh services, you can skip this section.\n\nIf intercepting all outgoing VM traffic is not acceptable for your\ndeployment, you can redirect specific traffic to the sidecar proxy, while the\nrest of the traffic will follow the regular route defined by your host\nnetworking configuration.\n\nTo achieve this, modify the Compute Engine VM host setup in\n[Cloud Service Mesh setup with VMs and manual Envoy deployment](/service-mesh/docs/service-routing/set-up-gce-vms)\nprocedure as follows:\n\n1. Decide on the range of IP addresses that Cloud Service Mesh-controlled\n services should resolve to. Traffic destined to these IP addresses is\n intercepted and redirected to the sidecar proxy. The range is specific to\n your deployment.\n\n2. In the `sidecar.env` file, set the value of `SERVICE_CIDR` to this range.\n Traffic to these IP addresses is redirected by netfilter to a sidecar proxy\n and load-balanced according to the configuration provided by\n Cloud Service Mesh.\n\n3. The sidecar proxy is not strictly required to run as a dedicated user that\n is excluded from traffic interception. However, this is still recommended.\n\n4. After you execute the `run.sh` script, as directed in the main procedure,\n `iptables` is configured for the interception and redirection of this specific\n range, only.\n\n5. Run the following command to verify that the netfilter is configured\n correctly. For ${SERVICE_CIDR}, substitute the value you configured as the\n intercepted IP address range.\n\n ```\n sudo iptables -L -t nat | grep -E \"(ISTIO_REDIRECT).+${SERVICE_CIDR})\"\n ```"]]
