Cloud Service Mesh con grupos de extremos de red de Internet
Puedes configurar Cloud Service Mesh 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 Cloud Service Mesh mediante backends de FQDN
La malla de servicios de Cloud Service Mesh 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.
También puedes enrutar el tráfico a servicios a los que se puede acceder a través de la Internet pública.
Arquitectura y recursos de Google Cloud
En esta sección, se describen los recursos y la arquitectura para configurar Cloud Service Mesh 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. Cloud Service Mesh programa el FQDN en proxies de Envoy mediante la configuración de xDS.
Cloud Service Mesh en sí no garantiza la resolución de nombres ni 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 Cloud Service Mesh. 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
Puedes configurar las verificaciones de estado mediante 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. Cloud Service Mesh 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 Cloud Service Mesh y las APIs. 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 Cloud Service Mesh. - Se requiere la versión 1.15.0 de Envoy o una superior con los backends de FQDN.
- Usa Google Cloud CLI o las APIs de REST para configurar Cloud Service Mesh. 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 Cloud Service Mesh, 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
- Verificación de estado de HTTP/HTTP2/HTTPS
¿Qué sigue?
- Para configurar Cloud Service Mesh con NEG de Internet, consulta Configura backends externos.
- Para obtener información sobre los NEG de conectividad híbrida, consulta Cloud Service Mesh con NEG de conectividad híbrida.