Balanceo de carga de Cloud Service Mesh

Cloud Service Mesh usa proxies sidecar o gRPC sin proxy para ofrecer balanceo de carga global a tus microservicios internos. Puede desplegar microservicios internos (basados en proxy sidecar o en gRPC sin proxy) con instancias en varias regiones. Cloud Service Mesh proporciona información sobre el estado, el enrutamiento y el backend a los proxies sidecar o a gRPC sin proxy, lo que les permite realizar un enrutamiento de tráfico óptimo a las instancias de la aplicación en varias regiones de la nube de un servicio.

En el siguiente diagrama, el tráfico de usuarios entra en una Google Cloud implementación a través de un balanceador de carga global externo. El balanceador de carga externo distribuye el tráfico al microservicio Front End en us-central1 o asia-southeast1, en función de la ubicación del usuario final.

La implementación interna incluye tres microservicios globales: Front End, Shopping Cart y Payments. Cada servicio se ejecuta en grupos de instancias gestionadas (MIGs) en dos regiones: us-central1 y asia-southeast1. Cloud Service Mesh usa un algoritmo de equilibrio de carga global que dirige el tráfico del usuario de California a los microservicios implementados en us-central1. Las solicitudes del usuario de Singapur se dirigen a los microservicios de asia-southeast1.

Una solicitud de usuario entrante se enruta al microservicio de frontend. El proxy de servicio instalado en el host con el frontend dirige el tráfico al carrito de la compra. El proxy sidecar instalado en el host con el carrito de compras dirige el tráfico al microservicio de pagos. En un entorno de gRPC sin proxy, tu aplicación gRPC gestionaría el tráfico.

Cloud Service Mesh en una implementación de balanceo de carga global.
Cloud Service Mesh en una implementación de balanceo de carga global (haz clic en la imagen para ampliarla)

En el siguiente ejemplo, si Cloud Service Mesh recibe resultados de comprobaciones de estado que indican que las instancias de máquina virtual (VM) que ejecutan el microservicio Carrito de compras en us-central1 no están en buen estado, Cloud Service Mesh indica al proxy sidecar de los microservicios de frontend que conmute el tráfico al microservicio Carrito de compras que se ejecuta en asia-southeast1. Como el autoescalado está integrado con la gestión del tráfico en Google Cloud, Cloud Service Mesh notifica al MIG de asia-southeast1 el tráfico adicional y el MIG aumenta de tamaño.

Cloud Service Mesh detecta que todos los back-ends del microservicio Payments están en buen estado, por lo que indica al proxy de Envoy de Shopping Cart que envíe una parte del tráfico (hasta la capacidad configurada por el cliente) a asia-southeast1 y el resto a us-central1.

Conmutación por error con Cloud Service Mesh en una implementación de balanceo de carga global.
Conmutación por error con Cloud Service Mesh en una implementación de balanceo de carga global (haz clic en la imagen para ampliarla)

Componentes de balanceo de carga en Cloud Service Mesh

Durante la configuración de Cloud Service Mesh, se configuran varios componentes de balanceo de carga:

  • El servicio de backend, que contiene valores de configuración.
  • Una comprobación de estado, que proporciona comprobaciones de estado para las VMs y los pods de Google Kubernetes Engine (GKE) de tu implementación.
  • Con las APIs de enrutamiento de servicios, un recurso Mesh o Gateway y un recurso Route.
  • Con las APIs de balanceo de carga, una regla de reenvío global, que incluye la dirección IP virtual, un proxy de destino y un mapa de URLs.

Un proxy adicional compatible con la API xDS (como Envoy) se ejecuta en una instancia de VM de cliente o en un pod de Kubernetes. Cloud Service Mesh actúa como plano de control y usa APIs xDS para comunicarse directamente con cada proxy. En el plano de datos, la aplicación envía tráfico a la dirección IP virtual configurada en la regla de reenvío o en el recurso Mesh. El proxy sidecar o tu aplicación gRPC intercepta el tráfico y lo redirige al backend adecuado.

En el siguiente diagrama se muestra una aplicación que se ejecuta en VMs de Compute Engine o pods de GKE, los componentes y el flujo de tráfico en una implementación de Cloud Service Mesh. Muestra Cloud Service Mesh y los recursos de Cloud Load Balancing que se usan para determinar el enrutamiento del tráfico. En el diagrama se muestran las APIs de balanceo de carga antiguas.

Recursos de Cloud Service Mesh que se van a configurar.
Recursos de Cloud Service Mesh que se van a configurar (haz clic en la imagen para ampliarla)

Siguientes pasos