Descubrimiento de servicios

Cloud Service Mesh proporciona descubrimiento de servicios y extremos. Estas funciones permiten agrupar las instancias de máquina virtual (VM) y el contenedor que ejecuta 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. R server es el código de la aplicación que recibe esas solicitudes. Un cliente de la malla de servicios de Cloud es un cliente de Envoy, gRPC o algún otro cliente de xDS que está conectado 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. Cuando la solicitud coincide, Envoy o gRPC aplican cualquier de las políticas de seguridad o del tráfico, elige un backend o un extremo, y 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 puedes definir reglas de enrutamiento que especifican cómo una solicitud saliente (una solicitud enviada por el código de la aplicación) y manejadas por un cliente de Cloud Service Mesh) coincidan con un servicio en particular. Cuando un cliente de la malla de servicios de Cloud maneja una solicitud que coincide con una regla, puede elige 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 maneja 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 la malla de servicios de Cloud sabe que esta solicitud está destinada 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 configuración adicional para habilitar la malla de servicios en la nube.

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

Cloud Service Mesh es compatible con 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?