Traffic Director con grupos de extremos de red de Internet

Puedes configurar Traffic Director para usar grupos de extremos de red (NEG) de Internet del tipo INTERNET_FQDN_PORT. El servicio externo se representa con su nombre de dominio completamente calificado (FQDN) y su número de puerto en el NEG. El NEG solo puede contener un par FQDN:Port, y el servicio de backend puede contener solo un NEG de este tipo. El FQDN se resuelve mediante el orden de resolución de nombres de la red de nube privada virtual (VPC) subyacente.

Expande la malla de servicios de Traffic Director mediante backends de FQDN

La malla de servicios de Traffic Director puede enrutar el tráfico a servicios privados a los que se puede acceder mediante una conectividad híbrida, incluidos los servicios nombrados locales, de Internet y de múltiples nubes. Se hace referencia al servicio remoto por su FQDN.

Extiende la malla de servicios de Traffic Director a ubicaciones locales o de múltiples nubes mediante backends de FQDN a través de conectividad híbrida
Extensión de la malla de servicios de Traffic Director a ubicaciones locales o de múltiples nubes mediante backends de FQDN a través de conectividad híbrida (haz clic para ampliar)

También puedes enrutar el tráfico a servicios a los que se puede acceder a través de la Internet pública.

Extiende la malla de servicios de Traffic Director a un servicio de Internet mediante backends de FQDN
Extensión de la malla de servicios de Traffic Director a un servicio de Internet mediante backends de FQDN (haz clic para ampliar)

Arquitectura y recursos de Google Cloud

En esta sección, se describen los recursos y la arquitectura para configurar Traffic Director con un NEG de Internet.

Grupo de extremos de red INTERNET_FQDN_PORT

Para enrutar el tráfico a un servicio externo al que se hace referencia por su FQDN, usa el NEG de Internet global del tipo INTERNET_FQDN_PORT. El NEG contiene el FQDN de tu servicio y su número de puerto. Traffic Director programa el FQDN en proxies de Envoy mediante la configuración de xDS.

Traffic Director en sí no garantiza la resolución de nombres y la accesibilidad de los extremos remotos. El FQDN debe poder resolverse mediante el orden de resolución de nombres de la red de VPC a la que se conectan los proxies de Envoy, y se debe poder acceder a los extremos resueltos desde los proxies de Envoy.

Verificaciones de estado

El comportamiento de la verificación de estado para los extremos de red del tipo INTERNET_FQDN_PORT difiere del comportamiento de la verificación de estado para otros tipos de extremos de red usados con Cloud Load Balancing y Traffic Director. Si bien la mayoría de los demás tipos de extremos de red usan el sistema centralizado de verificación de estado de Google Cloud, los NEG que se usan para extremos en entornos de múltiples nubes (INTERNET_FQDN_PORT y NON_GCP_PRIVATE_IP_PORT ) utiliza el mecanismo de verificación de estado distribuido de Envoy.

Envoy admite los siguientes protocolos para la verificación de estado:

  • HTTP
  • HTTPS
  • HTTP/2
  • TCP

Para configurar las verificaciones de estado, debes usar las APIs de Compute Engine.

Consideraciones de DNS

Hay dos consideraciones distintas con respecto al DNS:

  • El servidor DNS que aloja los registros de recursos de tu servicio externo.
  • Es el modo con el que el proxy de Envoy está configurado a fin de usar DNS para la administración de conexiones.

Servidor de Cloud DNS

Puedes crear una zona privada administrada de Cloud DNS para alojar los registros DNS en tu proyecto de Google Cloud. También puedes usar otras funciones de Cloud DNS, como zonas de reenvío, para recuperar registros de un servidor DNS local.

Modo DNS de Envoy

El modo DNS de Envoy, que también se conoce como descubrimiento de servicios, especifica cómo el proxy de Envoy usa registros DNS para administrar las conexiones salientes. Traffic Director configura Envoy para usar el modo DNS estricto. El modo de DNS estricto habilita el balanceo de cargas en todos los extremos resueltos. Respeta el estado de la verificación de estado y desvía las conexiones a los extremos que están en mal estado o que ya no se resuelven mediante DNS. No puedes cambiar este modo.

Para obtener más información sobre el descubrimiento de servicios, consulta la documentación de Envoy.

Conectividad y enrutamiento

Si enrutas el tráfico a un servicio privado, los siguientes son los requisitos para la conectividad de red subyacente:

  • La conectividad híbrida entre la red de VPC y el centro de datos local o la nube pública de terceros se establece mediante Cloud VPN o Cloud Interconnect.
  • Las reglas y rutas de firewall de VPC están configuradas de forma correcta para establecer la accesibilidad bidireccional desde Envoy a los extremos del servicio privado y, si corresponde, al servidor DNS local.
  • Para una conmutación por error regional de alta disponibilidad exitosa, se debe habilitar el enrutamiento dinámico global. Para obtener más información, consulta Modo de enrutamiento dinámico.

Si enrutas el tráfico a un servicio externo al que se puede acceder en Internet, se cumplen los siguientes requisitos:

  • Las instancias de máquina virtual (VM) de cliente en la red de VPC deben tener una dirección IP externa o Cloud NAT.
  • La ruta predeterminada debe estar presente para el tráfico de salida a Internet.

En ambos casos anteriores, el tráfico usa el enrutamiento de la red de VPC.

Seguridad

Los backends del FQDN son compatibles con las funciones de seguridad de Traffic Director y las API de Traffic Director. En las conexiones salientes a tu servicio externo, puedes configurar el FQDN en el encabezado de SNI mediante las políticas de TLS de cliente.

Limitaciones y consideraciones

  • Los NEG de Internet del tipo INTERNET_IP_PORT no son compatibles con Traffic Director.
  • Se requiere la versión 1.15.0 de Envoy o una superior con los backends de FQDN.
  • Usa las API de Google Cloud CLI o API de REST para configurar Traffic Director. No se admite la configuración de extremo a extremo con la consola de Google Cloud.
  • Los backends de FQDN solo son compatibles con Envoy. No se admite gRPC sin proxy.

  • Cuando usas el tipo INTERNET_FQDN_PORT de NEG con Traffic Director, las verificaciones de estado de los extremos remotos se realizan mediante el mecanismo de verificación de estado distribuido de Envoy. Cada vez que se agrega un extremo remoto nuevo, todos los proxies de Envoy comienzan a verificar su estado de forma independiente.

    De forma similar, cuando se agrega un proxy de Envoy nuevo a la malla, comienza a verificar todos los extremos remotos. Por lo tanto, según la cantidad de proxies de Envoy y de extremos remotos en tu implementación, la malla de verificación de estado resultante puede causar un tráfico de red significativo y una carga excesiva en los extremos remotos. Puedes elegir no configurar las verificaciones de estado.

  • El estado de la verificación de estado no es visible en la consola de Google Cloud para los backends de FQDN.

  • No se admite la verificación de estado que usa los protocolos UDP, SSL y gRPC.

  • No se admiten las siguientes opciones de verificación de estado:

    • Verificación de estado de HTTP/HTTP2/HTTPS
      • --proxy-header
      • --response
    • Verificación de estado de TCP
      • --proxy-header
      • --request
      • --response

¿Qué sigue?