Descubrimiento de servicios

Cloud Service Mesh proporciona descubrimiento de servicios y de endpoints. Estas funciones te permiten agrupar las instancias de máquina virtual y las instancias de contenedor que ejecutan tu código como endpoints de tus servicios.

Cloud Service Mesh monitoriza estos servicios para poder compartir información actualizada sobre las comprobaciones de estado con sus clientes. Por lo tanto, cuando una de tus aplicaciones usa su cliente de Cloud Service Mesh (como un proxy sidecar de Envoy o una aplicación gRPC sin proxy) para enviar una solicitud, se beneficia de la información actualizada sobre tus servicios.

En el contexto de Cloud Service Mesh, un cliente es un código de aplicación que se ejecuta en una VM o un contenedor que formula solicitudes para enviarlas a un servidor. Un servidor es un código de aplicación que recibe estas solicitudes. Un cliente de Cloud Service Mesh es un cliente de Envoy, gRPC u otro cliente de xDS que está conectado a Cloud Service Mesh y forma parte del plano de datos.

En el plano de datos, Envoy o gRPC hacen lo siguiente:

  1. Examina una solicitud y la asocia a un servicio de backend, un recurso que configuras durante la implementación.
  2. Una vez que se ha encontrado una coincidencia para la solicitud, Envoy o gRPC aplican las políticas de tráfico o de seguridad configuradas anteriormente, eligen un backend o un endpoint y dirigen la solicitud a ese backend o endpoint.

Descubrimiento de servicios

Cloud Service Mesh proporciona descubrimiento de servicios. Cuando configuras Cloud Service Mesh, creas servicios de backend. También puedes definir reglas de enrutamiento que especifiquen cómo se asocia una solicitud saliente (una solicitud enviada por el código de tu aplicación y gestionada por un cliente de Cloud Service Mesh) a un servicio concreto. Cuando un cliente de Cloud Service Mesh gestiona una solicitud que coincide con una regla, puede elegir el servicio que debe recibir la solicitud.

Por ejemplo:

  • Tienes una VM que ejecuta tu aplicación. Esta VM tiene un proxy sidecar de Envoy que está conectado a la malla de servicios de Cloud y gestiona las solicitudes salientes en nombre de la aplicación.
  • Has configurado un servicio de backend llamado payments. Este servicio de backend tiene dos backends de grupo de endpoints de red (NEG) que apuntan a varias instancias de contenedor que ejecutan el código de tu servicio payments.
  • Has configurado un recurso Mesh que define una malla llamada sidecar-mesh.
  • Has configurado un recurso Route que define los destinos del tráfico del servicio de backend payments y el nombre de host helloworld-gce.

Con esta configuración, cuando tu aplicación (en la VM) envía una solicitud HTTP a payments.example.com, el cliente de Cloud Service Mesh sabe que esta solicitud está destinada al servicio payments.

Cuando usas Cloud Service Mesh con servicios gRPC sin proxy, el descubrimiento de servicios funciona de forma similar. Sin embargo, una biblioteca gRPC que actúe como cliente de Cloud Service Mesh solo obtiene información sobre los servicios para los que especifiques un resolvedor xDS. De forma predeterminada, Envoy obtiene información sobre todos los servicios configurados en la red de nube privada virtual (VPC) especificada en el archivo de arranque de Envoy.

Descubrimiento de endpoints

El descubrimiento de servicios permite que los clientes conozcan tus servicios. El descubrimiento de endpoints permite a los clientes conocer las instancias que ejecutan tu código.

Cuando creas un servicio, también especificas los backends de ese servicio. Estos backends son VMs de grupos de instancias gestionados (MIGs) o contenedores de NEGs. Cloud Service Mesh monitoriza estos MIGs y NEGs para saber cuándo se crean y se eliminan instancias y endpoints.

Cloud Service Mesh comparte continuamente información actualizada sobre estos servicios con sus clientes. Esta información permite a los clientes evitar enviar tráfico a endpoints que ya no existen. También permite a los clientes obtener información sobre los nuevos endpoints y aprovechar la capacidad adicional que ofrecen.

Además de añadir endpoints a MIGs o NEGs y configurar Cloud Service Mesh, no necesitas ninguna configuración adicional para habilitar el descubrimiento de servicios con Cloud Service Mesh.

Intercepción del tráfico de proxy de sidecar en Cloud Service Mesh

Cloud Service Mesh admite el modelo de proxy sidecar. En este modelo, cuando una aplicación envía tráfico a su destino, el tráfico se intercepta y se redirige a un puerto del proxy sidecar en el host en el que se ejecuta la aplicación. El proxy sidecar decide cómo balancear la carga del tráfico y, a continuación, envía el tráfico a su destino.

Con Cloud Service Mesh y las APIs de enrutamiento de servicios, la intercepción del tráfico se gestiona automáticamente.

Siguientes pasos