이 문서는 Envoy를 사용하는 Cloud Service Mesh 및 전달 규칙을 포함한 이전 부하 분산 API에 적용됩니다.
이 문서에서는 전달 규칙의 가상 IP 주소와 전달 규칙이 서비스에 연결되는 방식을 설명합니다. 또한 Cloud Service Mesh 서비스 메시에서 서비스 간 통신에 사용되는 DNS를 계획하고 구성하는 방법도 설명합니다.
이 예시에서는 서로 통신하는 세 서비스인 service-a, service-b, service-c가 있다고 가정해 보겠습니다. 개발자는 서비스 간 통신을 위해 코드에서 정규화된 도메인 이름을 사용하는 경우가 많습니다. 도메인 이름이 example.com인 경우 세 가지 서비스가 다음과 같이 표시될 수 있습니다.
service-a.example.com
service-b.example.com
service-c.example.com
서비스 메시를 만들기 위해 Cloud Service Mesh 리소스를 구성할 때는 각 서비스에 전달 규칙을 구성합니다. 전달 규칙은 대상 서비스의 IP:Port 쌍을 나타냅니다. Envoy 사이드카 프록시에서 이그레스 트래픽을 가로채려면 대상 IP 주소가 전달 규칙과 연결된 IP 주소와 일치해야 합니다. 따라서 각 서비스에 IP 주소를 프로비저닝해야 합니다. 예를 들면 다음과 같습니다.
service-a.example.com의 IP 주소는 10.0.0.100입니다.
service-b.example.com의 IP 주소는 10.0.0.101입니다.
service-c.example.com의 IP 주소는 10.0.0.102입니다.
상응하는 Cloud Service Mesh 구성에는 각각 80 포트를 사용하는 세 가지 전달 규칙(FR1, FR2, FR3)이 있습니다.
FR1의 IP 주소는 service-a.example.com과 연관된 10.0.0.100:80입니다.
FR2의 IP 주소는 service-b.example.com과 연관된 10.0.0.101:80입니다.
FR3의 IP 주소는 service-c.example.com과 연관된 10.0.0.102:80입니다.
service-a가 정규화된 도메인 이름(FQDN) service-b.example.com을 사용하여 service-b를 호출하면 다음과 같은 세 가지 상황이 발생합니다.
service-a는 먼저 service-b.example.com에 대한 DNS 조회를 수행하여 service-b의 IP 주소를 확인합니다.
도메인이 service-b의 전달 규칙에 구성된 IP 주소와 일치하는 10.0.0.101로 확인됩니다.
이제 Envoy 프록시가 트래픽을 가로채 NEG 또는 MIG와 관계없이 service-b의 백엔드가 있는 백엔드 서비스로 라우팅할 수 있습니다.
Cloud DNS 관리형 비공개 영역을 구성하여 서비스의 리소스 레코드를 호스팅할 수 있습니다.
[[["이해하기 쉬움","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,["# DNS name resolution\n===================\n\nThis document applies to Cloud Service Mesh with Envoy and the older load-balancing\nAPIs, which include forwarding rules.\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 explains the relationship between a forwarding rule's virtual IP\naddress and how the forward rule is associated with a service. The document also\noutlines how to plan and configure DNS for a service-to-service communication in\na Cloud Service Mesh service mesh.\n\nConsider this example, in which there are three services, `service-a`,\n`service-b`, and `service-c`, that communicate with each other. Developers often\nuse fully- qualified-domain names in their code for service-to-service\ncommunication. If your domain name is example.com, the three services might be\nrepresented as:\n\n- `service-a.example.com`\n- `service-b.example.com`\n- `service-c.example.com`\n\nWhen you configure Cloud Service Mesh resources to create a service mesh,\nyou configure a forwarding rule for each of the services. A forwarding rule\nrepresents the `IP:Port` pair of the destination service. For egress traffic to\nbe intercepted by an Envoy sidecar proxy, the destination IP address must match\nwith the IP address associated with the forwarding rule. Therefore, you need to\nprovision an IP address for each service. For example:\n\n- `service-a.example.com` has the IP address `10.0.0.100`\n- `service-b.example.com` has the IP address `10.0.0.101`\n- `service-c.example.com` has the IP address `10.0.0.102`\n\nThe corresponding Cloud Service Mesh configuration has three forwarding rules,\nFR1, FR2, and FR3, each using port `80`:\n\n- FR1 has IP address `10.0.0.100:80`, which is associated with `service-a.example.com`.\n- FR2 has IP address `10.0.0.101:80`, which is associated with `service-b.example.com`.\n- FR3 has IP address `10.0.0.102:80`, which is associated with `service-c.example.com`.\n\nWhen `service-a` invokes `service-b` using the fully qualified domain name (FQDN)\n`service-b.example.com`, three things happen:\n\n1. `service-a` first performs a DNS lookup for `service-b.example.com` to resolve `service-b`'s IP address.\n2. The domain is resolved to `10.0.0.101` so that it matches the configured IP address of `service-b`'s forwarding rule.\n3. The Envoy proxy is now able to intercept traffic and route it to the backend service that has `service-b`'s backends, whether those are NEGs or MIGs.\n\nYou can configure a Cloud DNS managed private zone to host the resource\nrecords for your services."]]
