Integración de Cloud Service Mesh con Service Directory
En este documento se ofrece una descripción general de cómo usar el registro de servicios de Service Directory con Cloud Service Mesh, que permite a Cloud Service Mesh enrutar el tráfico y aplicar políticas de tráfico a los servicios registrados en Service Directory. Este documento está dirigido a los desarrolladores de Cloud Service Mesh que quieran integrar sus aplicaciones con otros servicios de Google Cloud.
Service Directory es un registro de servicios que almacena información sobre los servicios de red que se han registrado en él, como sus nombres, ubicaciones y atributos. Puedes registrar tus servicios automáticamente, capturando todos los detalles. Además, se pueden registrar todos los servicios, independientemente de su infraestructura.
El registro puede contener no solo Google Cloud servicios, sino también servicios híbridos que se ejecuten on-premise o en otras nubes públicas. Para entender mejor la información de este documento, te recomendamos que te familiarices con los conceptos básicos de las operaciones de Directorio de servicios.
Cuando usas el registro de servicios de Service Directory con Cloud Service Mesh, la integración hace que los servicios del registro de servicios estén disponibles para las aplicaciones de tu malla y para las pasarelas configuradas por Cloud Service Mesh. Se admite la integración de Cloud Service Mesh con Service Directory, con Envoy y con gRPC sin proxy, para las integraciones de Service Directory con balanceadores de carga de red internos de tipo pasarela, balanceadores de carga de aplicaciones internos y Private Service Connect de nivel 4.
Para integrar tus servicios, registra un servicio en Directorio de servicios y, a continuación, vincula el servicio a un servicio backend de Cloud Service Mesh. Una vez que se establece un enlace, Cloud Service Mesh consulta Service Directory para obtener información sobre el servicio registrado y cómo se puede acceder a él. Cloud Service Mesh también monitoriza cualquier cambio en el servicio. Al usar la integración, tu malla de servicios y tu gateway autogestionado pueden enviar tráfico a estos servicios. También te permite aplicar políticas, como las políticas de gestión avanzada del tráfico, que configures en Cloud Service Mesh.
Cuando usas esta integración, la vinculación de servicio actúa como backend, independientemente del tipo de backend que use el servicio. La integración simplifica la implementación de Cloud Service Mesh, ya que este puede enviar tráfico al servicio independientemente del tipo de backend.
Cuando un servicio se registra en Service Directory, no es necesario configurar grupos de instancias ni diferentes tipos de grupos de puntos finales de red (NEGs) para acceder a los servicios que necesitas. Puedes registrar automáticamente Google Kubernetes Engine, los balanceadores de carga internos y Private Service Connect en Service Directory, lo que simplifica aún más el acceso de Cloud Service Mesh a estos servicios.
Recursos utilizados por la integración
La integración entre Cloud Service Mesh y Service Directory usa los siguientes recursos.
Servicios de Directorio de servicios
Directorio de servicios es un registro de servicios. Service Directory te permite registrar varios tipos de servicios, incluidos los que se basan en Google Cloud u otros entornos (por ejemplo, un centro de datos local). Cada servicio consta de un nombre único y de cero o más puntos finales de servicio. Un punto final de servicio consta de una dirección, un puerto, propiedades y metadatos. Si no hay ningún endpoint,no puedes enrutar tráfico al servicio.
Enlaces a servicios
Una vinculación de servicio es un recurso que incluye el nombre de dominio completo (FQDN) del servicio Service Directory. Por ejemplo,
projects/test-proj/locations/us-east1/namespaces/test-namespace/services/test-service
es un FQDN de un servicio de Service Directory.
Servicios de backend
Los servicios de backend son recursos de configuración que proporcionan información a Cloud Service Mesh, incluidos los backends, como los grupos de instancias gestionados, a los que el servicio de backend dirige el tráfico. Los servicios de backend que hacen referencia a enlaces de servicio no pueden tener backends. Para usar la integración de Cloud Service Mesh con Service Directory, crea un servicio de backend para hacer referencia a las vinculaciones de servicio.
Un servicio de backend puede tener varios enlaces de servicio. Esta configuración es útil en situaciones en las que tienes implementaciones regionales de la misma aplicación. Puede registrar cada implementación regional en una instancia regional de Service Directory, como servicio regional 1 y servicio regional 2. Cada uno de estos servicios de Service Directory regionales se puede asociar al mismo servicio de backend mediante dos enlaces de servicio. La vinculación de servicio global 1 se asociaría al servicio regional 1 de la región A, y la vinculación de servicio global 2 se asociaría al servicio regional 2 de la región B.
Casos prácticos
La integración de tu implementación de Cloud Service Mesh con Service Directory permite nuevos casos prácticos que resultan útiles cuando dependes de servicios que pertenecen o publican otros equipos u organizaciones.
Hacer que los servicios estén disponibles en Cloud Service Mesh
Service Directory se integra con Google Cloud productos como GKE, los balanceadores de carga de red de paso a través internos y los balanceadores de carga de aplicaciones internos. Cuando los productores de servicios crean un servicio de GKE o un balanceador de carga, pueden registrarlo en el Directorio de servicios.
Una vez que un servicio se ha registrado en Directorio de servicios, puedes configurar Cloud Service Mesh para que se comunique con él. Los clientes de Cloud Service Mesh pueden comunicarse con los servicios que se ejecutan detrás de los balanceadores de carga de red de paso a través internos y los balanceadores de carga de aplicaciones internos.
Mejorar la coordinación entre los productores y los consumidores de servicios
Las grandes empresas tienen muchos equipos de desarrolladores independientes. Estos equipos ponen sus servicios a disposición de otros equipos para que puedan usar las funciones que ofrece el servicio compartido. Esto crea dependencias entre equipos. Aunque estas dependencias permiten a los equipos compartir sus esfuerzos, también generan una sobrecarga de coordinación.
Cuando usas Service Directory, un equipo (el productor) registra un servicio que quiere poner a disposición de otros equipos u organizaciones (los consumidores). El productor comparte una referencia a este servicio con un consumidor. El consumidor puede usar esta referencia para buscar el servicio del productor en Service Directory y descubrir los endpoints del servicio. Por ejemplo, el punto final puede ser una dirección IP virtual (VIP) en la que el servicio del productor espera recibir tráfico.
La integración de Cloud Service Mesh con Service Directory te permite automatizar el proceso vinculando un servicio de Service Directory a un servicio backend de Cloud Service Mesh, lo que ofrece las siguientes ventajas:
- Cloud Service Mesh resuelve automáticamente los endpoints del servicio sincronizándolos desde Directorio de servicios. Si se actualizan los endpoints del servicio Service Directory, Cloud Service Mesh sincroniza automáticamente estos cambios.
- En Cloud Service Mesh, puedes definir varias políticas de enrutamiento y gestión del tráfico, como los tiempos de espera. Estas políticas le permiten ajustar cómo emiten solicitudes sus aplicaciones al servicio Service Directory. Para obtener información sobre el enrutamiento y la gestión del tráfico en Cloud Service Mesh, consulta Gestión avanzada del tráfico.
- Cloud Service Mesh usa funciones de gestión del tráfico, como el balanceo de carga basado en la proximidad, para dirigir de forma óptima el tráfico de las aplicaciones a los endpoints. Por ejemplo, minimiza el tiempo de ida y vuelta.
Cuando tú, como consumidor, usas Cloud Service Mesh y asocias un servicio backend a un servicio de Service Directory, se reduce la sobrecarga de coordinación entre equipos.
- Vincula el servicio
Paymentspor su nombre. Cloud Service Mesh comparte información sobre el servicio
Paymentscon sus clientes.- Por ejemplo, los proxies sidecar que se ejecutan en tu malla de servicios ahora conocen el endpoint (por ejemplo,
10.0.0.1:80) en el que se puede acceder al servicio.
- Por ejemplo, los proxies sidecar que se ejecutan en tu malla de servicios ahora conocen el endpoint (por ejemplo,
Tus aplicaciones pueden llamar a este servicio por su nombre sin que tú ni tu aplicación tengáis que saber nada sobre el endpoint del servicio externo. En el diagrama, el servicio es el servicio
Payments.Cuando el productor del servicio actualiza el servicio externo (por ejemplo, cambia su endpoint), Cloud Service Mesh detecta la actualización y la comparte sin problemas con sus clientes.
Acceder a servicios dentro de un perímetro mediante un punto de entrada
Un equipo puede agrupar una colección de servicios en un perímetro de Controles de Servicio de VPC y exponer esos servicios a través de un único punto de entrada. Este punto de entrada se puede registrar en Directorio de servicios y ponerlo a disposición de los usuarios que quieran acceder a los servicios del perímetro. Para obtener más información sobre los perímetros de Controles de Servicio de VPC, consulta Configuración y detalles del perímetro de servicio.
Por ejemplo, un equipo crea una pasarela de entrada mediante un balanceador de carga de aplicaciones interno que distribuye las solicitudes a una colección de servicios de Kubernetes en un clúster. Esta puerta de enlace de entrada se registra automáticamente como un servicio en Directorio de servicios. Un consumidor que quiera acceder a los servicios de Kubernetes puede buscar esta pasarela de entrada en Service Directory. A continuación, el consumidor puede configurar la malla de Cloud Service Mesh para acceder a los servicios del perímetro a través de la pasarela.
Conectar servicios entre dominios
Puede que tengas servicios en diferentes dominios que necesites conectar.
Conectar servicios entre organizaciones
Es posible que quieras acceder a servicios propiedad de otra organización, como las APIs de Google (por ejemplo, Cloud SQL) o servicios gestionados de terceros.
Service Directory admite Private Service Connect. Cuando creas un endpoint de Private Service Connect en tu red, el endpoint se puede registrar como servicio en el Directorio de servicios. Después, puedes asociar este servicio a Cloud Service Mesh para que los clientes de la malla, como los clientes de Envoy y gRPC, y las pasarelas autogestionadas, como Apigee, puedan llamar a estos servicios.
En el ejemplo anterior, que usa Cloud Storage, se muestra cómo puedes usar Private Service Connect para llamar a las APIs de Google mediante un endpoint de tu red de nube privada virtual.
Conectar servicios entre redes de VPC
Algunas empresas utilizan varias redes de VPC como parte de suGoogle Cloud despliegue. En estos casos, es posible que un servicio de una red de VPC necesite acceder a un servicio de otra red de VPC. Puedes configurar el emparejamiento de VPCs para acceder a un servicio en otra red de VPC, pero esta configuración crea complicaciones cuando hay intervalos de direcciones IP superpuestos entre las redes emparejadas.
Private Service Connect puede hacer que un servicio de una red de VPC sea accesible de forma segura y privada para los servicios de otra red de VPC mediante un único IP:port punto final.
Ejemplos adicionales en distintos dominios
Los dos ejemplos anteriores ilustran casos en los que puede que tengas que usar el seguimiento entre dominios, pero hay muchos más. Por ejemplo, creas una pasarela que se encuentra en la intersección de dos regiones Google Cloud . Los servicios de una región pueden acceder a los servicios de otra región a través de esta pasarela. Registra la pasarela como un servicio en Service Directory y, a continuación, usa la pasarela con Cloud Service Mesh, tal como se describe en este documento.
Aplicar políticas cuando se accede a los servicios
Cloud Service Mesh admite funciones como la gestión avanzada del tráfico, que se pueden configurar mediante políticas. Por ejemplo, puedes definir una política de duplicación de tráfico para que, cada vez que un cliente envíe una solicitud a un servicio de backend concreto, el tráfico también se envíe a un segundo servicio de backend.
Cuando vinculas un servicio de Service Directory a un servicio de backend de Cloud Service Mesh, puedes configurar estos tipos de políticas en Cloud Service Mesh. Tus proxies de sidecar, proxies intermedios o de extremo, y clientes sin proxy se informan sobre estas políticas y las aplican.
Algunos ejemplos:
- División del tráfico basada en el peso, por ejemplo, entre dos servicios de Service Directory
- Duplicación del tráfico (por ejemplo, a un servicio de auditoría)
users se replican en el servicio audit (haz clic para ampliar)Compatibilidad con Cloud Service Mesh y clientes actuales
Aunque Cloud Service Mesh esté desplegado en tu organización, es posible que tengas clientes que no lo usen. Por ejemplo, es posible que tengas que acceder a un servicio desde una máquina virtual que no forme parte de una malla de servicios.
Cuando vinculas un servicio de Service Directory a un servicio de backend de Cloud Service Mesh, los clientes de Cloud Service Mesh obtienen automáticamente información actualizada sobre ese servicio. Tus clientes que no usen Cloud Service Mesh pueden buscar y usar información de servicios en Service Directory.
Limitaciones
Cloud Service Mesh no admite NEGs FQDN (INTERNET_FQDN_PORT NEGs) en la integración de Service Directory.
Siguientes pasos
- Consulta cómo configurar la integración.
- Para obtener información sobre la observabilidad con esta integración, consulta Observabilidad y depuración con Service Directory.