DNS 이름 변환

이 문서는 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를 호출하면 다음과 같은 세 가지 상황이 발생합니다.

  1. service-a는 먼저 service-b.example.com에 대한 DNS 조회를 수행하여 service-b의 IP 주소를 확인합니다.
  2. 도메인이 service-b의 전달 규칙에 구성된 IP 주소와 일치하는 10.0.0.101로 확인됩니다.
  3. 이제 Envoy 프록시가 트래픽을 가로채 NEG 또는 MIG와 관계없이 service-b의 백엔드가 있는 백엔드 서비스로 라우팅할 수 있습니다.

Cloud DNS 관리형 비공개 영역을 구성하여 서비스의 리소스 레코드를 호스팅할 수 있습니다.