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

Cloud Service Mesh admite entornos que van más allá de Google Cloud, como centros de datos on-premise y otras nubes públicas a las que puedes acceder mediante conectividad híbrida.

Configura Cloud Service Mesh para que tu malla de servicios pueda enviar tráfico a endpoints que estén fuera de Google Cloud. Entre estos endpoints se incluyen los siguientes:

  • Balanceadores de carga locales.
  • Aplicaciones de servidor en una instancia de máquina virtual en otra nube.
  • Cualquier otro destino al que puedas acceder con conectividad híbrida y que se pueda alcanzar con una dirección IP y un puerto.

Añade la dirección IP y el puerto de cada endpoint a un grupo de endpoints de red (NEG) de conectividad híbrida. Los NEGs de conectividad híbrida son de tipo NON_GCP_PRIVATE_IP_PORT.

Gracias a la compatibilidad de Cloud Service Mesh con los servicios on-premise y multinube, puedes hacer lo siguiente:

  • Dirige el tráfico a nivel mundial, incluidos los endpoints de los servicios on-premise y multinube.
  • Aprovecha las ventajas de Cloud Service Mesh y de la malla de servicios, incluidas funciones como la detección de servicios y la gestión avanzada del tráfico, en los servicios que se ejecutan en tu infraestructura fuera de Google Cloud.
  • Combina las funciones de Cloud Service Mesh con Cloud Load Balancing para ofrecer servicios de red en varios entornos. Google Cloud

Los NEGs de conectividad híbrida (NON_GCP_PRIVATE_IP_PORT NEGs) no se admiten con clientes gRPC sin proxy.

Casos prácticos

Cloud Service Mesh puede configurar la red entre servicios basados en máquinas virtuales y en contenedores en varios entornos, entre los que se incluyen los siguientes:

  • Google Cloud
  • Centros de datos on-premise
  • Otras nubes públicas

Dirigir el tráfico de la malla a una ubicación on-premise u otra nube

El caso de uso más sencillo de esta función es el enrutamiento del tráfico. Tu aplicación está ejecutando un proxy de Envoy de Cloud Service Mesh . Cloud Service Mesh informa al cliente sobre tus servicios y los endpoints de cada servicio.

Dirigir el tráfico de la malla a una ubicación on-premise u otra nube.
Enrutamiento del tráfico de la malla a una ubicación local u otra nube (haz clic en la imagen para ampliarla)

En el diagrama anterior, cuando tu aplicación envía una solicitud al servicio on-prem, el cliente de Cloud Service Mesh inspecciona la solicitud saliente y actualiza su destino. El destino se establece en un endpoint asociado al servicio on-prem (en este caso, 10.2.0.1). La solicitud se envía a través de Cloud VPN o Cloud Interconnect hasta su destino.

Si necesitas añadir más endpoints, actualiza Cloud Service Mesh para añadirlos a tu servicio. No es necesario que cambie el código de su aplicación.

Migrar un servicio local a Google Cloud

Si envías tráfico a un endpoint que no sea deGoogle Cloud , podrás dirigir el tráfico a otros entornos. Puedes combinar esta función con la gestión avanzada del tráfico para migrar servicios entre entornos.

Migrar de una ubicación local a Google Cloud.
Migrar de una ubicación local a Google Cloud (haz clic para ampliar)

El diagrama anterior amplía el patrón anterior. En lugar de configurar Cloud Service Mesh para que envíe todo el tráfico al servicio on-prem, puedes configurarlo para que use la división del tráfico basada en el peso para dividir el tráfico entre dos servicios.

La división del tráfico le permite empezar enviando el 0% del tráfico al servicio cloud y el 100% al servicio on-prem. Después, puedes aumentar gradualmente la proporción de tráfico que se envía al servicio cloud. Finalmente, envías el 100% del tráfico al servicio cloud y puedes retirar el servicio on-prem.

Google Cloud Servicios de perímetro de red para despliegues on-premise y multinube

Por último, puedes combinar esta función con las Google Cloudsoluciones de red Google Cloud que ya ofrece.ofrece una amplia gama de servicios de red, como el balanceo de carga externo global con Google Cloud Armor para la protección contra ataques de denegación de servicio distribuido (DDoS), que puedes usar con Cloud Service Mesh para incorporar nuevas funciones a tus servicios locales o multicloud. Lo mejor de todo es que no tienes que exponer estos servicios on-premise o multicloud a la red pública de Internet.

Despliegues en varios entornos.
Despliegues que abarcan varios entornos (haz clic en la imagen para ampliarla)

En el diagrama anterior, el tráfico de los clientes de Internet público entra en la red deGoogle Clouda través de un balanceador de carga, como nuestro balanceador de carga de aplicación externo global. Google Cloud Cuando el tráfico llega al balanceador de carga, puedes aplicar servicios de perímetro de red, como la protección contra DDoS de Cloud Armor o la autenticación de usuarios de Identity-Aware Proxy (IAP). Para obtener más información, consulta Servicios de perímetro de red para despliegues multientorno.

Después de aplicar estos servicios, el tráfico hace una breve parada enGoogle 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 on-premise.

Google Cloud recursos y arquitectura

En esta sección se proporciona información general sobre los recursos de Google Cloudque puedes usar para proporcionar una malla de servicios gestionada por Cloud Service Mesh en entornos on-premise y multinube.

En el siguiente diagrama se muestran los recursos de Google Cloud que permiten la compatibilidad con servicios on-premise y multinube para Cloud Service Mesh. El recurso clave es el NEG y sus endpoints de red. Los demás recursos son los que configuras como parte de una configuración estándar de Cloud Service Mesh. Para simplificarlo, el diagrama no muestra opciones como varios servicios de backend globales.

Recursos de Compute Engine para servicios on-premise y multinube.
Recursos de Compute Engine para servicios locales y multicloud (haz clic en la imagen para ampliarla)

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

  1. Políticas que se aplican cuando un cliente intenta enviar tráfico al servicio.
  2. Uno o varios backends o endpoints que gestionan el tráfico destinado al servicio.

Los servicios on-premise y multinube son como cualquier otro servicio que configura Cloud Service Mesh. La diferencia principal es que se usa un NEG de conectividad híbrida para configurar los endpoints de estos servicios. Estos NEGs tienen el tipo de endpoint de red definido como NON_GCP_PRIVATE_IP_PORT. Los endpoints que añadas a los NEGs de conectividad híbrida deben ser combinaciones IP:port válidas a las que puedan acceder tus clientes, por ejemplo, a través de la conectividad híbrida, como Cloud VPN o Cloud Interconnect.

Cada NEG tiene un tipo de punto final de red y solo puede contener puntos finales de red del mismo tipo. Este tipo determina lo siguiente:

  • El destino al que pueden enviar tráfico tus servicios.
  • Comportamiento de comprobación del estado.

Cuando cree su NEG, configúrelo de la siguiente manera para poder enviar tráfico a un destino on-premise o multinube.

  • Asigna el valor NON_GCP_PRIVATE_IP_PORT al tipo de punto final de red. Esto representa una dirección IP accesible. Si esta dirección IP es local o de otro proveedor de servicios en la nube, se debe poder acceder a ella desde Google Cloud mediante una conectividad híbrida, como la que ofrecen Cloud VPN o Cloud Interconnect.
  • Especifica una Google Cloud zona que minimice la distancia geográfica entre Google Cloud y tu entorno local o multicloud. Por ejemplo, si alojas un servicio en un entorno local en Fráncfort (Alemania), puedes especificar la zona europe-west3-a Google Cloud al crear el NEG.

El comportamiento de las comprobaciones del estado de los puntos finales de red de este tipo es diferente al de otros tipos de puntos finales de red. Mientras que otros tipos de endpoints de red usan el sistema de comprobación del estado centralizado de Google Cloud, los endpoints de red NON_GCP_PRIVATE_IP_PORT usan el mecanismo de comprobación del estado distribuido de Envoy. Para obtener más información, consulta la sección Limitaciones y otras consideraciones.

Consideraciones sobre la conectividad y las redes

Tus clientes de Cloud Service Mesh, como los proxies de Envoy, deben poder conectarse a Cloud Service Mesh en trafficdirector.googleapis.com:443. Si pierdes la conectividad con el plano de control de Cloud Service Mesh, ocurrirá lo siguiente:

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

Si quieres enviar tráfico entre Google Cloud y entornos on-premise o multinube, los entornos deben estar conectados mediante conectividad híbrida. Te recomendamos que habilites una conexión de alta disponibilidad mediante Cloud VPN o Cloud Interconnect.

Las direcciones IP y los intervalos de direcciones IP de las subredes, de otros proveedores de servicios en la nube y on-premise no deben solaparse. Google Cloud

Limitaciones y otras consideraciones

A continuación, se indican las limitaciones de las NEGs de conectividad híbrida.

Configurando proxyBind

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

Conectividad e interrupciones de la conectividad

Para obtener más información sobre los requisitos y las limitaciones de conectividad, consulta la sección Consideraciones sobre la conectividad y las redes.

Tipos de backend mixtos

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

Un mapa de URLs puede tener reglas de host que se resuelvan en diferentes servicios de backend. Puede que tengas un servicio de backend con NEGs de conectividad híbrida (con endpoints locales) y otro con NEGs independientes (con endpoints de GKE). El mapa de URLs puede contener reglas, como la división del tráfico basada en el peso, que dividen el tráfico entre cada uno de estos servicios backend.

Usar un NEG con endpoints de tipo NON_GCP_PRIVATE_IP_PORT con Google Cloud backends

Es posible crear un servicio de backend con un NEG de conectividad híbrida que apunte a backends en Google Cloud. Sin embargo, no recomendamos este patrón porque los NEG de conectividad híbrida no se benefician de la comprobación de estado centralizada. Para obtener una explicación sobre las comprobaciones de estado centralizadas y distribuidas, consulta la sección Comprobaciones de estado.

Registro de endpoints

Si quieres añadir un endpoint a un NEG, debes actualizar el NEG. Puedes hacerlo manualmente o automatizarlo mediante las APIs REST de Google Cloud NEG o Google Cloud CLI.

Cuando se inicia una nueva instancia de un servicio, puedes usar las APIs Google Cloud para registrar la instancia en el NEG que hayas configurado. Cuando se usan grupos de instancias gestionadas (MIGs) de Compute Engine o GKE (en Google Cloud), el controlador de MIG o NEG gestiona automáticamente el registro de los endpoints, respectivamente.

Comprobaciones del estado

Cuando usas NEGs de conectividad híbrida, el comportamiento de las comprobaciones de estado difiere del comportamiento de las comprobaciones de estado centralizadas estándar de las siguientes formas:

  • En el caso de los endpoints de red de tipo NON_GCP_PRIVATE_IP_PORT, Cloud Service Mesh configura sus clientes para que usen el plano de datos para gestionar la comprobación del estado. Para evitar enviar solicitudes a back-ends que no estén en buen estado, las instancias de Envoy realizan sus propias comprobaciones de estado y usan sus propios mecanismos.
  • Como tu plano de datos gestiona las comprobaciones de estado, no puedes usar la consola, la API ni la CLI de Google Cloud para obtener el estado de las comprobaciones de estado.Google Cloud

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

  • Como cada cliente de Cloud Service Mesh gestiona la comprobación del estado de forma distribuida, es posible que observes un aumento del tráfico de red debido a la comprobación del estado. El aumento depende del número de clientes de Cloud Service Mesh y del número de endpoints que cada cliente necesite comprobar. Por ejemplo:
    • Cuando añades otro endpoint a un NEG de conectividad híbrida, es posible que los clientes de Cloud Service Mesh empiecen a comprobar el estado de los endpoints de los NEGs de conectividad híbrida.
    • Cuando añades otra instancia a tu malla de servicios (por ejemplo, una instancia de VM que ejecuta el código de tu aplicación, así como un cliente de Cloud Service Mesh), la nueva instancia puede empezar a comprobar el estado de los endpoints de los NEGs de conectividad híbrida.
    • El tráfico de red debido a las comprobaciones del estado aumenta a un ritmo cuadrático (O(n^2)).

Red VPC

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

Cuenta de servicio

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

Siguientes pasos