Cloud Service Mesh con grupos de extremos de red de conectividad híbrida

Cloud Service Mesh admite entornos que se extienden más allá de Google Cloud, incluidos los centros de datos locales y otras nubes públicas a las que puedes usar la conectividad híbrida para llegar.

Debes configurar Cloud Service Mesh para que tu malla de servicios pueda enviar tráfico que están fuera de Google Cloud. Estos extremos incluyen lo siguiente:

  • Balanceadores de cargas locales.
  • Aplicaciones de servidores en una instancia de máquina virtual (VM) en otra nube.
  • Cualquier otro destino al que se pueda acceder con conectividad híbrida y con una dirección IP y un puerto.

Debes agregar la dirección IP y los puertos de cada extremo a un grupo de extremos de red de la conectividad híbrida (NEG). Los NEG de conectividad híbrida son del tipo NON_GCP_PRIVATE_IP_PORT.

La compatibilidad de Cloud Service Mesh con servicios locales y de múltiples nubes te permite hacer lo siguiente:

  • Enrutar el tráfico de forma global, incluso a los extremos de los servicios locales y de múltiples nubes.
  • Incorpora los beneficios de la malla de servicios de Cloud y la malla de servicios, como capacidades, como el descubrimiento de servicios y la administración avanzada de tráfico, servicios que se ejecutan en tu infraestructura existente fuera de Google Cloud.
  • Combina las funciones de Cloud Service Mesh con Cloud Load Balancing para llevar los servicios de redes de Google Cloud a múltiples entornos.

Los NEG de conectividad híbrida (NON_GCP_PRIVATE_IP_PORT NEG) no son compatibles con para clientes de gRPC sin proxy.

Casos de uso

Cloud Service Mesh puede configurar las Herramientas de redes entre los servicios basados en VM y contenedores en múltiples entornos, incluidos los siguientes:

  • Google Cloud
  • Centros de datos locales
  • Otras nubes públicas

Enruta el tráfico de la malla a una ubicación local o a otra nube

El caso de uso más simple para esta función es el enrutamiento de tráfico. Tu aplicación ejecuta un proxy de Envoy de la malla de servicios de Cloud . Cloud Service Mesh le indica al cliente sobre tus servicios y los extremos de cada servicio.

Enruta el tráfico de la malla a una ubicación local o a otra nube
Enruta el tráfico de la malla a una ubicación local o a otra nube (haz clic para agrandar)

En el diagrama anterior, cuando la aplicación envía una solicitud a on-prem servicio, el cliente de la malla de servicios de Cloud inspecciona la solicitud saliente y la actualiza su destino. El destino se configura en un extremo asociado con el servicio on-prem (en este caso, 10.2.0.1). La solicitud luego pasa por Cloud VPN o Cloud Interconnect hacia su destino previsto.

Si necesitas agregar más extremos, actualiza Cloud Service Mesh para agregarlos a tu servicio. No es necesario que cambies el código de tu aplicación.

Migra un servicio local existente a Google Cloud

Enviar tráfico a un extremo que no es de Google Cloud te permite enrutar el tráfico a otros entornos. Puedes combinar esta capacidad con la administración avanzada del tráfico para migrar servicios entre entornos.

Migración desde una ubicación local a Google Cloud.
Migra de una ubicación local a Google Cloud (haz clic para agrandar)

En el diagrama anterior, se extiende el patrón anterior. En lugar de configurar Cloud Service Mesh envía todo el tráfico al servicio on-prem, configurar Cloud Service Mesh para usar la división del tráfico basada en el peso para dividir el tráfico entre dos servicios.

La división del tráfico te permite comenzar enviando un 0% del tráfico al servicio cloud y un 100% al servicio on-prem. Luego, puedes aumentar de forma gradual la proporción del tráfico enviado al servicio de cloud. Por último, envías el 100% del tráfico al servicio cloud y puedes retirar el servicio on-prem.

Servicios de red perimetral de Google Cloud para implementaciones locales y de múltiples nubes

Por último, puedes combinar esta funcionalidad con las soluciones de Herramientas de redes de Google Cloud existentes. Google Cloud ofrece una amplia variedad de opciones servicios, como el balanceo de cargas externo global con Google Cloud Armor protección contra denegación de servicio distribuido (DSD), que puedes usar con Cloud Service Mesh para incorporar nuevas capacidades a tu entorno local o a múltiples nubes de Google Cloud. Lo mejor de todo es que no necesitas exponer estos servicios locales o de múltiples nubes a la Internet pública.

Implementaciones que abarcan varios entornos
Implementaciones que abarcan múltiples entornos (haz clic para agrandar)

En el diagrama anterior, el tráfico de los clientes en la Internet pública ingresa red de Google Cloud desde un balanceador de cargas de Google Cloud, como nuestro balanceador de cargas de aplicaciones externo global. Cuando el tráfico llega al balanceador de cargas, puedes aplicar servicios de red perimetral, como la protección contra DSD de Google Cloud Armor o la autenticación de usuario de Identity-Aware Proxy (IAP). Si deseas obtener más información, consulta Servicios de red perimetral para implementaciones de múltiples entornos.

Después de que apliques estos servicios, el tráfico se detendrá brevemente en Google Cloud, donde una aplicación o un proxy independiente (configurado por Cloud Service Mesh) reenvía el tráfico a través de Cloud VPN o Cloud Interconnect a tu servicio local.

Arquitectura y recursos de Google Cloud

En esta sección, se brinda información general sobre los recursos de Google Cloud que puedes usar para proporcionar una malla de servicios administrada por Cloud Service Mesh para entornos locales y de múltiples nubes.

En el siguiente diagrama, se muestran los recursos de Google Cloud que habilitan la asistencia de servicios locales y de múltiples nubes para la malla de servicios de Cloud. El recurso clave es el NEG (y sus extremos de red). Los otros recursos son los que configuras como parte de una configuración estándar de Cloud Service Mesh. Para simplificar, en el diagrama no se muestran opciones como varios servicios de backend globales.

Recursos de Compute Engine para servicios locales y de múltiples nubes.
Recursos de Compute Engine para servicios locales y de múltiples nubes (haz clic para agrandar)

Cuando configuras Cloud Service Mesh, usas la API de servicios de backend globales recurso para crear servicios. Un servicio es una construcción lógica que combina lo siguiente:

  1. Políticas que se deben aplicar cuando un cliente intenta enviar tráfico al servicio.
  2. Uno o más backends o extremos que controlan el tráfico destinado al servicio.

Los servicios locales y de múltiples nubes son como cualquier otro servicio que que configura Cloud Service Mesh. La diferencia clave es que usas un NEG de conectividad híbrida para configurar los extremos de estos servicios. Estos NEG tienen el tipo de extremo de red configurado como NON_GCP_PRIVATE_IP_PORT. Los extremos que agregues a los NEG de conectividad híbrida deben ser combinaciones IP:port válidas a las que puedan acceder tus clientes (por ejemplo, a través de una conectividad híbrida, como Cloud VPN o Cloud Interconnect).

Cada NEG tiene un tipo de extremo de red y solo puede contener extremos de red del mismo tipo. Este tipo determina lo siguiente:

  • El destino al que tus servicios pueden enviar tráfico.
  • El comportamiento de la verificación de estado.

Cuando crees tu NEG, configúralo de la siguiente manera para que puedas enviar tráfico a un destino local o de múltiples nubes.

  • Configura el tipo de extremo de red en NON_GCP_PRIVATE_IP_PORT. Representa una dirección IP accesible. Si esta dirección IP es local o se encuentra en otro proveedor de servicios en la nube, se debe poder acceder a ella desde Google Cloud mediante la conectividad híbrida, como la conectividad proporcionada por Cloud VPN o Cloud Interconnect.
  • Especifica una zona de Google Cloud que minimiza la distancia geográfica entre Google Cloud y tu entorno local o de múltiples nubes. Por ejemplo, si alojas un servicio en un entorno local en Fráncfort, Alemania, puedes especificar la zona europe-west3-a de Google Cloud cuando crees el NEG.

El comportamiento de la verificación de estado para los extremos de red de este tipo difiere del comportamiento de la verificación de estado para otros tipos de extremos de red. Mientras que otros tipos de extremos de red usan el sistema centralizado de verificación de estado de Google Cloud, los extremos de red NON_GCP_PRIVATE_IP_PORT usan el mecanismo de verificación de estado distribuido de Envoy. Para obtener más información, consulta la sección Limitaciones y otras consideraciones.

Consideraciones de conectividad y redes

Tus clientes de la malla de servicios de Cloud, como los proxies de Envoy, deben poder conectarse a Cloud Service Mesh en trafficdirector.googleapis.com:443. Si pierdes la conectividad al plano de control de Cloud Service Mesh, sucede lo siguiente:

  • Los clientes existentes de Cloud Service Mesh no pueden recibir actualizaciones de configuración de Cloud Service Mesh. Seguirán operando según su configuración actual.
  • Los clientes nuevos de Cloud Service Mesh no pueden conectarse a Cloud Service Mesh. No podrán usar la malla de servicios hasta que se vuelva a establecer la conectividad.

Si quieres enviar tráfico entre Google Cloud y entornos locales o de múltiples nubes, los entornos deben estar conectados a través de la conectividad híbrida. Recomendamos una conexión de alta disponibilidad habilitada mediante Cloud VPN o Cloud Interconnect.

Las direcciones IP locales, otras de la nube y de la subred de Google Cloud no deben superponerse.

Limitaciones y otras consideraciones

Las siguientes son limitaciones del uso de NEG de conectividad híbrida.

Configura proxyBind

Solo puedes establecer el valor de proxyBind cuando creas un targetHttpProxy. No puedes actualizar un targetHttpProxy existente.

Interrupción y conectividad en la conectividad

Para obtener detalles sobre los requisitos y las limitaciones de conectividad, consulta la sección Consideraciones de conectividad y redes.

Tipos de backend mixtos

Un servicio de backend puede tener backends de VM o NEG. Si un servicio de backend tiene backends de NEG, todos los NEG deben contener el mismo tipo de extremo de red. No puedes tener un servicio de backend con varios NEG, cada uno con diferentes tipos de extremos.

Un mapa de URL puede tener reglas de host que se resuelvan en diferentes servicios de backend. Puedes tener un servicio de backend solo con NEG de conectividad híbrida (con extremos locales) y un servicio de backend con NEG independientes (con extremos de GKE). El mapa de URL puede contener reglas, por ejemplo, dividir el tráfico basado en el peso, que divide el tráfico en cada uno de estos servicios de backend.

Usa un NEG con extremos de tipo NON_GCP_PRIVATE_IP_PORT con backends de Google Cloud

Es posible crear un servicio de backend con un NEG de conectividad híbrida que apunta a los backends en Google Cloud. Sin embargo, no recomendamos este patrón, ya que los NEG de conectividad híbrida no se benefician de la verificación de estado centralizada. Para obtener una explicación de la verificación de estado centralizada y la verificación de estado distribuida, consulta la sección Verificación de estado.

Registro de extremos

Si deseas agregar un extremo a un NEG, debes actualizar el NEG. Esto se puede hacer de forma manual o se puede automatizar con las API de REST de NEG de Google Cloud o con la CLI de Google Cloud.

Cuando se inicia una instancia nueva de un servicio, puedes usar las API de Google Cloud para registrar la instancia con el NEG que configuraste. Cuando usas grupos de instancias administrados (MIG) de Compute Engine o GKE (en Google Cloud), el controlador de NEG o MIG maneja de forma automática el registro de extremos, respectivamente.

Verificaciones de estado

Cuando usas NEG de conectividad híbrida, el comportamiento de la verificación de estado difiere del comportamiento estándar de verificación de estado de las siguientes maneras:

  • En el caso de los extremos de red del tipo NON_GCP_PRIVATE_IP_PORT, Cloud Service Mesh configura sus clientes para usar el plano de datos a fin de controlar la verificación de estado. Para evitar enviar solicitudes a backends en mal estado, las instancias de Envoy realizan sus propias verificaciones de estado y usan sus propios mecanismos.
  • Debido a que tu plano de datos controla las verificaciones de estado, no puedes usar la consola de Google Cloud, la API o Google Cloud CLI para recuperar el estado de la verificación de estado.

En la práctica, usar NON_GCP_PRIVATE_IP_PORT significa lo siguiente:

  • Debido a que cada cliente de Cloud Service Mesh controla la verificación de estado en un de forma distribuida, es posible que veas un aumento en el tráfico de red debido a la verificación de estado. El aumento depende de la cantidad de clientes de Cloud Service Mesh y de la cantidad de extremos que cada cliente necesita para la verificación de estado. Por ejemplo:
    • Cuando agregas otro extremo a un NEG de conectividad híbrida, los clientes existentes de Cloud Service Mesh pueden comenzar a verificar el estado de los extremos en los NEG de conectividad híbrida.
    • Cuando agregas otra instancia a tu malla de servicios (por ejemplo, una VM que ejecuta el código de la aplicación, así como un cliente de la malla de servicios de Cloud), la instancia nueva puede comenzar a funcionar verificar los extremos en los NEG de conectividad híbrida.
    • El tráfico de red debido a las verificaciones de estado aumenta a una frecuencia cuadrática (O(n^2)).

Red de VPC

Una malla de servicios se identifica de forma única por su nombre de red de nube privada virtual (VPC). Los clientes de Cloud Service Mesh reciben la configuración desde Cloud Service Mesh en función de la red de VPC especificada en la configuración de arranque. Por lo tanto, incluso si tu malla está completamente fuera de un centro de datos de Google Cloud, debes proporcionar un nombre de red de VPC válido en tu configuración de arranque.

Cuenta de servicio

Dentro de Google Cloud, el arranque inicial predeterminado de Envoy está configurado para leer información de la cuenta de servicio desde uno o ambos de los entornos de implementación de Compute Engine y GKE. Cuando se ejecuta fuera de Google Cloud, debes especificar de forma explícita una cuenta de servicio, un nombre de red y un número de proyecto en tu arranque de Envoy. Esta cuenta de servicio debe tener permisos suficientes para conectarse a la API de Cloud Service Mesh.

¿Qué sigue?