Cloud Service Mesh con grupos de puntos finales de red de Internet

Puedes configurar Cloud Service Mesh para que use grupos de endpoints de red (NEGs) de Internet de tipo INTERNET_FQDN_PORT. El servicio externo se representa mediante su nombre de dominio completo (FQDN) y su número de puerto en el NEG. El NEG solo puede contener un par FQDN:Port y el servicio de backend solo puede contener 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.

Ampliar la malla de servicios de Cloud Service Mesh con back-ends FQDN

La malla de servicios de Cloud Service Mesh puede enrutar el tráfico a servicios privados a los que se puede acceder mediante conectividad híbrida, incluidos los servicios locales, multinube y de Internet con nombre. Se hace referencia al servicio remoto mediante su FQDN.

Extender la malla de servicios de Cloud Service Mesh a ubicaciones on-premise o multinube mediante back-ends FQDN a través de conectividad híbrida.
Extensión de la malla de servicios de Cloud Service Mesh a ubicaciones locales o multicloud mediante back-ends FQDN a través de conectividad híbrida (haz clic en la imagen para ampliarla)

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

Extender la malla de servicios de Cloud Service Mesh a un servicio de Internet mediante back-ends FQDN.
Extensión de la malla de servicios de Cloud Service Mesh a un servicio de Internet mediante back-ends FQDN (haz clic en la imagen para ampliarla)

Google Cloud recursos y arquitectura

En esta sección se describen los recursos y la arquitectura para configurar Cloud Service Mesh con un NEG de Internet.

INTERNET_FQDN_PORT grupo de puntos finales de red

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

Cloud Service Mesh no garantiza la resolución de nombres ni la accesibilidad de los endpoints remotos. El FQDN debe poder resolverse mediante el orden de resolución de nombres de la red de VPC a la que están conectados los proxies de Envoy, y los endpoints resueltos deben ser accesibles desde los proxies de Envoy.

Comprobaciones del estado

El comportamiento de las comprobaciones del estado de los puntos finales de red de tipo INTERNET_FQDN_PORT es diferente al de otros tipos de puntos finales de red que se usan con Cloud Load Balancing y Cloud Service Mesh. Mientras que la mayoría de los otros tipos de endpoints de red usan el sistema de comprobación de estado centralizado de Google Cloud, los NEG que se usan para los endpoints en entornos multicloud (INTERNET_FQDN_PORT y NON_GCP_PRIVATE_IP_PORT) usan el mecanismo de comprobación de estado distribuido de Envoy.

Envoy admite los siguientes protocolos para comprobar el estado:

  • HTTP
  • HTTPS
  • HTTP/2
  • TCP

Las comprobaciones del estado se configuran mediante las APIs de Compute Engine.

Consideraciones sobre DNS

Hay dos aspectos distintos que debes tener en cuenta en relación con el DNS:

  • El servidor DNS que aloja los registros de recursos de tu servicio externo.
  • El modo con el que se configura el proxy de Envoy para usar DNS en la gestión de conexiones.

Servidor Cloud DNS

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

Modo DNS de Envoy

El modo DNS de Envoy, también llamado descubrimiento de servicios, especifica cómo usa el proxy de Envoy los registros DNS para gestionar las conexiones salientes. Cloud Service Mesh configura Envoy para usar el modo DNS estricto. El modo DNS estricto habilita el balanceo de carga en todos los endpoints resueltos. Respeta el estado de la comprobación de estado y agota las conexiones a los endpoints que no están en buen 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 tráfico a un servicio privado, la conectividad de red subyacente debe cumplir los siguientes requisitos:

  • 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 de cortafuegos y las rutas de la VPC están configuradas correctamente para establecer la accesibilidad bidireccional desde Envoy a los endpoints de tu servicio privado y, si procede, al servidor DNS local.
  • Para que la conmutación por error de alta disponibilidad regional se realice correctamente, debe habilitarse el enrutamiento dinámico global. Para obtener más información, consulta el modo de enrutamiento dinámico.

Si enrutas el tráfico a un servicio externo al que se puede acceder a través de Internet, debes cumplir los siguientes requisitos:

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

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

Seguridad

Los backends FQDN son compatibles con las funciones de seguridad de Cloud Service Mesh y las APIs. En las conexiones salientes a tu servicio externo, puedes configurar el nombre de dominio completo en el encabezado SNI mediante políticas de TLS de cliente.

Limitaciones y consideraciones

  • Las NEGs de Internet de tipo INTERNET_IP_PORT no se admiten en Cloud Service Mesh.
  • Se requiere la versión 1.15.0 de Envoy o una posterior con back-ends FQDN.
  • Usa la CLI de Google Cloud o las APIs REST para configurar Cloud Service Mesh. No se admite la configuración integral mediante la consola Google Cloud .
  • Los back-ends FQDN solo se admiten con Envoy. No se admite gRPC sin proxy.

  • Cuando usas el tipo de NEG INTERNET_FQDN_PORT con Cloud Service Mesh, las comprobaciones de estado de los endpoints remotos se realizan mediante el mecanismo de comprobación de estado distribuido de Envoy. Cada vez que se añade un nuevo endpoint remoto, todos los proxies de Envoy empiezan a comprobar su estado de forma independiente.

    Del mismo modo, cuando se añade un nuevo proxy de Envoy a la malla, empieza a comprobar todos los endpoints remotos. Por lo tanto, en función del número de proxies de Envoy y de endpoints remotos de tu implementación, la malla de comprobación del estado resultante puede provocar un tráfico de red significativo y una carga excesiva en los endpoints remotos. Puedes optar por no configurar comprobaciones del estado.

  • El estado de la comprobación de estado no se muestra en la consola de Google Cloud para las backends de FQDN.

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

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

    • Comprobación del estado de HTTP, HTTP/2 o HTTPS
      • --proxy-header
      • --response
    • Comprobación del estado de TCP
      • --proxy-header
      • --request
      • --response

Siguientes pasos