Cloud Service Mesh용으로 이러한 리소스를 만들고 구성할 때 Cloud Service Mesh는 이 값을 사용하여 데이터 영역으로 전송되는 구성을 만들며, 여기에는 Envoy 프록시 및 프록시리스 gRPC 애플리케이션과 같은 xDS 클라이언트가 포함됩니다. 그러면 데이터 영역에서 이 구성에 따라 트래픽을 처리합니다.
전달 규칙은 대상 프록시를 참조하고 IP 주소와 포트가 포함됩니다.
Cloud Service Mesh 배포의 경우 전달 규칙의 부하 분산 스키마를 INTERNAL_SELF_MANAGED로 설정해야 합니다. 그러면 대상 프록시가 URL 맵을 참조합니다. 이 3가지 리소스가 결합되어 라우팅 규칙 맵을 구성합니다.
validateForProxyless 필드가 TRUE로 설정된 대상 gRPC 프록시를 참조하는 전달 규칙의 IP 주소는 0.0.0.0로 설정되어야 합니다. validateForProxyless가 TRUE로 설정되면 0.0.0.0 이외의 IP 주소로 지정된 구성이 거부됩니다.
라우팅 규칙 맵은 클라이언트에서 서비스 메시 내부의 서버로 트래픽을 전달하는 방법을 정의합니다.
지원되는 대상 프록시 유형
Cloud Service Mesh는 다음과 같은 대상 프록시 유형을 지원합니다.
클라이언트와 서버가 HTTP 또는 HTTP/2 트래픽을 주고받을 때 구성하는 대상 HTTP 프록시입니다.
클라이언트와 서버가 HTTPS 트래픽을 주고받을 때 구성하는 대상 HTTPS 프록시입니다. 이는 Envoy 프록시로 서비스 보안을 설정할 때 필요합니다.
클라이언트와 서버가 TCP 트래픽을 주고받을 때 구성하는 대상 TCP 프록시입니다.
클라이언트와 서버가 gRPC 트래픽을 주고받을 때 구성하는 대상 gRPC 프록시입니다. 대상 gRPC 프록시에는 프록시리스 gRPC 서비스를 배포할 때 TRUE로 설정되는 validateForProxyless 필드가 포함됩니다.
Envoy 사이드카 프록시로 트래픽 라우팅
Envoy 사이드카 프록시에 Cloud Service Mesh를 사용하는 경우 클라이언트 요청이 다음과 같이 라우팅됩니다.
네트워크 스택은 요청을 가로채서 이를 Envoy 사이드카 프록시로 리디렉션합니다.
Envoy 사이드카 프록시는 요청의 IP 주소와 포트를 확인합니다.
IP 주소와 포트 쌍은 부하 분산 스키마가 INTERNAL_SELF_MANAGED로 설정된 모든 전달 규칙에 지정된 IP 주소 및 포트에서 확인됩니다.
일치하는 IP 주소 및 포트가 있는 전달 규칙이 발견되면 Envoy는 전달 규칙이 참조하는 대상 HTTP 또는 gRPC 프록시를 찾습니다.
이 동작은 프록시리스 gRPC 애플리케이션의 경우 서로 다릅니다. gRPC 클라이언트를 구성할 때 클라이언트가 연결해야 하는 서비스의 대상 URI를 지정합니다. 이 URI는 xds 이름 리졸버 스키마와 hostname:port 형식을 사용합니다(예: xds:///example.hostname:8080).
프록시리스 gRPC 클라이언트가 Cloud Service Mesh에 연결할 때 Cloud Service Mesh는 다음과 같이 서비스에 따라 정보를 전송합니다.
Cloud Service Mesh는 INTERNAL_SELF_MANAGED로 설정된 부하 분산 스키마가 있는 전달 규칙을 찾아 포트가 대상 URI에 지정된 포트와 일치하는 전달 규칙을 찾습니다.
Cloud Service Mesh는 이러한 각 전달 규칙의 대상 gRPC 프록시 또는 대상 HTTP 프록시를 찾습니다.
Cloud Service Mesh는 이러한 대상 gRPC 프록시 또는 대상 HTTP 프록시에서 참조하는 URL 맵을 찾습니다.
Cloud Service Mesh는 URL 맵에서 hostname[:port] 형식도 있는 호스트 규칙을 확인하고 일치하는 항목을 찾습니다.
일치하는 항목을 찾으면 Cloud Service Mesh는 gRPC 클라이언트에 라우팅 규칙 및 서비스 정보를 반환합니다.
또한 일치하는 항목이 두 개 이상 발견되면 동작이 정의되지 않고 예기치 않은 동작이 발생할 수 있습니다. 이는 일반적으로 다음 두 가지 조건이 모두 충족되는 경우에 발생합니다.
여러 URL 맵에서 동일한 호스트 이름이 사용됩니다.
부하 분산 스키마 INTERNAL_SELF_MANAGED를 사용하는 여러 전달 규칙이 동일한 포트를 지정합니다.
따라서 동일한 포트를 지정하는 전달 규칙이 참조하는 여러 URL 맵에서 동일한 호스트 이름을 다시 사용하지 않는 것이 좋습니다.
다음 단계
트래픽 관리를 통해 트래픽이 처리되는 방식을 세밀하게 제어하는 방법에 대해 알아보려면 고급 트래픽 관리 개요를 참조하세요
[[["이해하기 쉬움","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,["# Routing rule maps overview\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 document applies only to Cloud Service Mesh with the load balancing APIs. We\nstrongly recommend that you use the\n[service routing APIs](/service-mesh/docs/service-routing/service-routing-overview).\n\nA routing rule map consists of the following:\n\n- A [forwarding rule](/service-mesh/legacy/load-balancing-apis/forwarding-rules) that references a target proxy\n- A [target proxy](/service-mesh/legacy/load-balancing-apis/target-proxies) that references a URL map\n- A [URL map](/load-balancing/docs/url-map-concepts) that contains various routing rules\n\nWhen you create and configure these resources for Cloud Service Mesh,\nCloud Service Mesh uses the values to create the configuration that it\nsends to your data plane, which includes xDS clients such as Envoy\nproxies and proxyless gRPC applications. The data plane then handles traffic\naccording to this configuration.\n\nA forwarding rule references a target proxy, and has an IP address and a port.\nFor Cloud Service Mesh deployments, the forwarding rule's load-balancing\nscheme must be set to `INTERNAL_SELF_MANAGED`. The target proxy, in turn,\nreferences a URL map. These three resources combine to form a routing rule map.\n\nA forwarding rule that references a target gRPC proxy with the\n`validateForProxyless` field set to `TRUE` must have its IP address set to\n`0.0.0.0`. When `validateForProxyless` is set to `TRUE`, configurations that\nspecify an IP address other than `0.0.0.0` are rejected.\n\nThe routing rule map defines how traffic passes from clients to servers inside\na service mesh.\n\nSupported target proxy types\n----------------------------\n\nCloud Service Mesh supports the following target proxy types:\n\n- **Target HTTP proxy**, which you configure when your clients and servers send or receive HTTP or HTTP/2 traffic.\n- **Target HTTPS proxy**, which you configure when your clients and servers send or receive HTTPS traffic. This is required when you set up service security with Envoy proxies.\n- **Target TCP proxy**, which you configure when your clients and servers send or receive TCP traffic.\n- **Target gRPC proxy** , which you configure when your clients and servers send or receive gRPC traffic. Target gRPC proxies contain the field `validateForProxyless`, which is set to `TRUE` when you deploy proxyless gRPC services.\n\nTraffic routing with Envoy sidecar proxies\n------------------------------------------\n\nWhen you use Cloud Service Mesh with Envoy sidecar proxies, client requests\nare routed as follows:\n\n- The network stack intercepts the request and redirects it to your Envoy sidecar proxy.\n- The Envoy sidecar proxy looks at the request's IP address and port.\n- The IP address and port pair are checked against the IP address and port specified in any forwarding rules that have the load-balancing scheme set to `INTERNAL_SELF_MANAGED`.\n- If a forwarding rule with a matching IP address and port is found, Envoy looks at the target HTTP proxy or the target gRPC proxy that the forwarding rule references.\n- Envoy checks the URL map that the target proxy references.\n- Envoy routes the request according to the rules specified in the URL map.\n\nFor information about how traffic is routed with a target TCP proxy, see\n[Routing TCP traffic with Cloud Service Mesh](/service-mesh/legacy/load-balancing-apis/configure-tcp).\n\nTraffic routing with proxyless gRPC applications\n------------------------------------------------\n\nThis behavior is different for proxyless gRPC applications. When you configure\na gRPC client, you specify the target URI for the service that the client\nneeds to contact. This URI uses the `xds` name resolver scheme and the\n`hostname:port` format---for example `xds:///example.hostname:8080`.\n\nWhen the proxyless gRPC client connects to Cloud Service Mesh,\nCloud Service Mesh sends it information corresponding to the service\nas follows:\n\n- Cloud Service Mesh looks for forwarding rules with the load-balancing scheme set to `INTERNAL_SELF_MANAGED` to find forwarding rules whose port matches the port specified in the target URI.\n- Cloud Service Mesh finds the target gRPC proxy or the target HTTP proxy for each of these forwarding rules.\n- Cloud Service Mesh finds the URL maps referenced by these target gRPC proxies or target HTTP proxies.\n- Cloud Service Mesh checks the host rules in the URL map, which also have the `hostname[:port]` format, and looks for a match.\n- When a match is found, Cloud Service Mesh returns routing rules and service information to the gRPC client.\n\nIf more than one match is found, the behavior is undefined and can\nlead to unpredictable behavior. This generally happens when both of the following\nconditions are met:\n\n- The same hostname is used across multiple URL maps.\n- Multiple forwarding rules with the load-balancing scheme `INTERNAL_SELF_MANAGED` specify the same port.\n\nFor this reason, we recommend that you don't re-use the same hostname across\nmultiple URL maps that are referenced by forwarding rules that specify the same\nport.\n\nWhat's next\n-----------\n\n- To get fine-grained control over how traffic is handled, see the\n [Advanced traffic management overview](/service-mesh/legacy/load-balancing-apis/advanced-traffic-management-legacy).\n\n- To learn more about Cloud Service Mesh, see the\n [Cloud Service Mesh overview](/service-mesh/legacy/load-balancing-apis/overview)."]]
