이 문서에는 Cloud Service Mesh를 구성할 때 유용할 수 있는 참고사항이 포함되어 있습니다.
Cloud Service Mesh에 단일 Compute Engine VM 구성
이 절차를 사용하여 사이드카 프록시 배포 및 트래픽 가로채기를 구현하여 VM에 Cloud Service Mesh 서비스에 대한 액세스 권한을 제공할 수 있습니다.
이 절차를 수행하려면 Docker를 설치해야 합니다. Docker Engine 설치는 Docker 안내를 따릅니다.
단일 VM에서 Cloud Service Mesh를 구성하기 위해 이 프로세스를 따르는 경우 일부 설정 작업에서 Linux 호스트에 액세스할 수 있어야 합니다. 호스트는 Virtual Private Cloud 네트워크에서 실행되는 로컬 머신 또는 VM일 수 있습니다.
먼저 구성 파일과 샘플 스크립트를 다운로드하고 준비합니다.
설정 과정에서 사용 중인 Linux 호스트에 로그인합니다.
필요한 파일의 보관 파일을 Linux 호스트에 다운로드하고 압축을 풉니다.
wget https://storage.googleapis.com/traffic-director/traffic-director-xdsv3.tar.gz
tar -xzvf traffic-director-xdsv3.tar.gz; cd traffic-director-xdsv3
이 보관 파일은 다음과 같은 파일을 포함합니다.
sidecar.env – 환경 변수를 갖는 구성 파일
iptables.sh – netfilter 규칙을 설정하는 스크립트
bootstrap_template.yaml – Envoy용 부트스트랩 템플릿 파일
run.sh – sidecar.env 구성 파일을 사용하여 가로채 기용 iptables를 설정하고 Envoy 사이드카 프록시를 실행하는 최상위 스크립트
사이드카 프록시를 실행하는 각 호스트에서 Envoy 프록시 프로세스를 실행할 시스템 사용자를 만듭니다. Envoy 프록시 사용자입니다. Envoy 프록시 사용자는 로그인이 사용 중지됩니다.
sudo adduser --system --disabled-login envoy
sidecar.env 파일을 수정하여 구성을 수정합니다. 각 변수에 대한 자세한 설명은 구성 파일의 인라인 주석을 참조하세요.
sidecar.env 파일에서 ENVOY_USER 변수를 Envoy 프록시의 사용자 이름으로 설정합니다.
다음으로, Cloud Service Mesh를 사용하는 애플리케이션을 실행하는 각 VM 호스트에 대해 다음 단계를 수행합니다.
수정된 sidecar.env 파일이 있는 전체 traffic-director-xdsv3 디렉터리를 Cloud Service Mesh를 사용할 애플리케이션을 실행하는 각 VM 호스트에 복사합니다.
run.sh 스크립트를 시스템의 시작 스크립트에 추가하면 VM이 재부팅될 때마다 스크립트가 실행됩니다.
각 VM 호스트에서 run.sh 스크립트를 실행합니다.
cd traffic-director-xdsv3
sudo ./run.sh start
Envoy 프록시가 올바르게 시작되었는지 확인합니다.
sudo ./run.sh status
다음과 같은 출력이 표시됩니다.
OK: Envoy seems to be running.
OK: Traffic interception seems to be enabled.
다음을 사용하여 트래픽 가로채기 방향을 확인할 수 있습니다.
sudo iptables -S -t nat | grep ISTIO_REDIRECT
예상되는 출력은 다음과 같습니다.
-N ISTIO_REDIRECT
-A ISTIO_OUTPUT -j ISTIO_REDIRECT
-A ISTIO_REDIRECT -p tcp -j REDIRECT --to-ports 15001`
라우팅 규칙 맵
라우팅 규칙 맵에서 라우팅을 구성하는 방법에는 두 가지가 있습니다.
서비스의 실제 대상 VIP와 포트를 기반으로 라우팅을 사용 설정할 수 있습니다. 전달 규칙의 IPAddress 매개변수로 서비스의 VIP를 구성하면 이 주소 및 연결된 포트를 대상으로 하는 트래픽만 일치하고 URL 맵에 지정된 호스트 및 경로 매개변수에 따라 라우팅됩니다.
또는 전달 규칙의 주소를 0.0.0.0으로 설정할 수 있습니다.
이렇게 하면 요청의 대상 IP 주소와 관계없이 대상 포트를 기준으로 트래픽이 일치하도록 프록시가 구성됩니다. 그런 다음 URL 맵에 지정된 호스트 및 경로 매개변수에 따라 트래픽이 라우팅됩니다.
이 두 가지 접근 방식에 따라, 호스트 규칙에 구성된 대로 대상 VIP 및 포트 쌍 또는 대상 포트(VIP가 0.0.0.0인 경우)와 연결된 호스트 이름은 서비스 메시 구성 내에서 고유해야 합니다.
즉, 동일한 호스트 이름을 사용하면서 백엔드 집합이 서로 다른 두 개의 상이한 서비스가 있을 수 없습니다.
VPC 네트워크의 각 전달 규칙은 0.0.0.0 주소를 비롯하여 VPC 네트워크당 IP 주소와 포트의 고유한 조합을 포함해야 합니다. 특정 VPC 네트워크에서 동일한 IP 주소와 포트를 사용하여 전달 규칙을 2개 이상 만들면 첫 번째 전달 규칙만 유효합니다. 나머지는 무시됩니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2024-12-22(UTC)"],[],[],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 ```"]]
