Resolución de nombre del DNS

Este documento se aplica a Cloud Service Mesh con Envoy y las APIs de balanceo de cargas anteriores, que incluyen reglas de reenvío.

En este documento, se explica la relación entre la dirección IP virtual de una regla de reenvío y cómo se asocia la regla de reenvío con un servicio. En el documento, también se describe cómo planificar y configurar DNS para una comunicación de servicio a servicio en una malla de servicios de Cloud Service Mesh.

Considera este ejemplo, en el que hay tres servicios, service-a, service-b y service-c, que se comunican entre sí. Los desarrolladores suelen usar nombres de dominio completamente calificados en su código para servicio a servicio la comunicación. Si tu nombre de dominio es ejemplo.com, los tres servicios podrían ser se representa de la siguiente manera:

  • service-a.example.com
  • service-b.example.com
  • service-c.example.com

Cuando configuras los recursos de Cloud Service Mesh para crear una malla de servicios, configuras una regla de reenvío para cada uno de los servicios. Una regla de reenvío representa el par IP:Port del servicio de destino. Para que el tráfico de salida sea interceptado por un proxy de sidecar de Envoy, la dirección IP de destino debe coincidir con la dirección IP asociada con la regla de reenvío. Por lo tanto, debes aprovisionar una dirección IP para cada servicio. Por ejemplo:

  • service-a.example.com tiene la dirección IP 10.0.0.100.
  • service-b.example.com tiene la dirección IP 10.0.0.101.
  • service-c.example.com tiene la dirección IP 10.0.0.102.

La configuración correspondiente de Cloud Service Mesh tiene tres reglas de reenvío, FR1, FR2 y FR3, cada una con el puerto 80:

  • FR1 tiene la dirección IP 10.0.0.100:80, que está asociada con service-a.example.com.
  • FR2 tiene la dirección IP 10.0.0.101:80, que está asociada con service-b.example.com.
  • FR3 tiene la dirección IP 10.0.0.102:80, que está asociada con service-c.example.com.

Cuando service-a invoca service-b mediante el nombre de dominio completamente calificado (FQDN) service-b.example.com, ocurren tres situaciones:

  1. service-a primero realiza una búsqueda de DNS para service-b.example.com a fin de resolver la dirección IP de service-b.
  2. El dominio se resuelve en 10.0.0.101 para que coincida con la dirección IP configurada de la regla de reenvío de service-b.
  3. El proxy de Envoy ahora puede interceptar el tráfico y enrutarlo al servicio de backend que tiene los backends de service-b, ya sean NEG o MIG.

Puedes configurar una zona privada administrada por Cloud DNS para alojar el recurso registros de tus servicios.