Descubrimiento de servicios

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

Cloud Service Mesh supervisa estos servicios para que pueda compartir información actualizada de la verificación de estado con sus clientes. Por lo tanto, cuando una de tus aplicaciones usa su cliente de malla de servicios de Cloud (como un proxy de sidecar de Envoy o una aplicación de 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 la aplicación que se ejecuta en una VM o contenedor y que formula solicitudes que se envían a un servidor. Un servidor es un código de la aplicación que recibe esas solicitudes. Un cliente de Cloud Service Mesh es un cliente de Envoy, gRPC o de otro cliente de xDS que se conecta a Cloud Service Mesh y es parte del plano de datos.

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

  1. Examina una solicitud y hace coincidir la solicitud con un servicio de backend, un recurso que configuras durante la implementación.
  2. Una vez que la solicitud coincide, Envoy o gRPC aplica cualquier política de seguridad o tráfico configurada previamente, elige un backend o extremo y dirige la solicitud a ese backend o extremo.

Descubrimiento de servicios

Cloud Service Mesh proporciona el descubrimiento de servicios. Cuando configuras Cloud Service Mesh, creas servicios de backend. También defines las reglas de enrutamiento que especifican cómo se hace coincidir una solicitud saliente (una solicitud enviada por el código de tu aplicación y manejada por un cliente de Cloud Service Mesh) a un servicio en particular. Cuando un cliente de Cloud Service Mesh controla 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 de sidecar de Envoy que está conectado a Cloud Service Mesh y controla las solicitudes salientes en nombre de la aplicación.
  • Configuraste un servicio de backend llamado payments. Este servicio de backend tiene dos backends de grupos de extremos de red (NEG) que apuntan a varias instancias de contenedor que ejecutan el código para tu servicio payments.
  • Configuraste un recurso Mesh que define una malla llamada sidecar-mesh.
  • Configuraste un recurso Route que define los destinos de tráfico para el 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 es una solicitud dirigida al servicio payments.

Cuando usas Cloud Service Mesh con servicios de gRPC sin proxy, el descubrimiento de servicios funciona de manera similar. Sin embargo, una biblioteca de gRPC que actúa como cliente de la malla de servicios de Cloud solo obtiene información sobre los servicios para los que especificas un agente de resolución 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 extremos

Service Discovery permite que los clientes conozcan tus servicios. La detección de extremos permite que los clientes conozcan las instancias que ejecutan tu código.

Cuando creas un servicio, también especificas sus backends. Estos backends son VM en grupos de instancias administrados (MIG) o contenedores en NEG. Cloud Service Mesh supervisa estos MIG y NEG para que sepa cuándo se crean y quitan las instancias y los extremos.

La malla de servicios de Cloud comparte de forma continua información actualizada sobre estos servicios con sus clientes. Esto permite que los clientes eviten enviar tráfico a extremos que ya no existen. También permite a los clientes obtener información sobre extremos nuevos y aprovechar la capacidad adicional que proporcionan estos extremos.

Además de agregar extremos a MIG o NEG y configurar Cloud Service Mesh, no necesitas ninguna configuración adicional para habilitar el descubrimiento de servicios con Cloud Service Mesh.

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

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

Con Cloud Service Mesh y las APIs de enrutamiento de servicio, la interceptación de tráfico se administra automáticamente.

¿Qué sigue?