Balanceo de cargas de la malla de servicios de Cloud

Cloud Service Mesh usa proxies de sidecar o gRPC sin proxy para entregar la carga global para tus microservicios internos. Puedes implementar microservicios internos (basados en proxies de sidecar o sin gRPC) con instancias en varias regiones. La malla de servicios de Cloud proporciona información de estado, enrutamiento y backend a los proxies de sidecar o gRPC sin proxy, lo que les permite realizar un tráfico óptimo de aplicaciones en varias regiones de la nube para un servicio.

En la siguiente diagrama, el tráfico del usuario ingresa a una implementación de Google Cloud a través de un balanceador de cargas global externo. El balanceador de cargas externo distribuye el tráfico al microservicio de frontend en us-central1 o asia-southeast1, según la ubicación del usuario final.

La implementación interna cuenta con tres microservicios globales: frontend, carrito de compras y pagos. Cada servicio se ejecuta en grupos de instancias administrados en dos regiones, us-central1 y asia-southeast1. Cloud Service Mesh usa un balanceador de cargas de balanceo de cargas que dirige el tráfico del usuario de California a la microservicios implementados en us-central1. Las solicitudes del usuario en Singapur se dirigen a los microservicios en asia-southeast1.

Una solicitud de usuario entrante se enruta al microservicio de frontend. Luego, el proxy de servicio instalado en el host con el frontend dirige el tráfico al carrito de compras. El proxy de 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 de gRPC controlaría la administración del tráfico.

Cloud Service Mesh en una implementación de balanceo de cargas global.
Cloud Service Mesh en una implementación de balanceo de cargas global (haz clic para ampliar)

En el siguiente ejemplo, si Cloud Service Mesh recibe resultados de verificación de estado que indican que las instancias de máquina virtual (VM) que ejecutan el carrito de compras el microservicio en us-central1 están en mal estado, la malla de servicios de Cloud le indica proxy de sidecar para que los microservicios del frontend realicen una conmutación por error del tráfico al centro de compras Microservicio de carrito que se ejecuta en asia-southeast1. Dado que el ajuste de escala automático se integra en la administración del tráfico en Google Cloud, Cloud Service Mesh notifica al MIG en asia-southeast1 sobre el tráfico adicional, y este aumentos de tamaño.

Cloud Service Mesh detecta que todos los backends del microservicio Pagos están en buen estado, entonces la malla de servicios de Cloud indica al proxy de Envoy para el carrito de compras envía una parte del tráfico, hasta la latencia configurada capacidad a asia-southeast1 y desborda el resto a us-central1.

Conmutación por error con Cloud Service Mesh en una implementación global de balanceo de cargas.
Conmutación por error con Cloud Service Mesh en una implementación de balanceo de cargas global (haz clic para ampliar)

Componentes del balanceo de cargas en Cloud Service Mesh

Durante la configuración de Cloud Service Mesh, configuras varias cargas de balanceo de cargas componentes:

  • El servicio de backend, que contiene valores de configuración
  • Una verificación de estado, que proporciona verificaciones de estado para las VM y los Pods de Google Kubernetes Engine (GKE) en tu implementación
  • Con las APIs de Service Enrutamiento, un recurso Mesh o Gateway y Un recurso Route.
  • Con las APIs de balanceo de cargas, se crea una regla de reenvío global que incluye una dirección VIP, un proxy de destino y un mapa de URL.

Se ejecuta en un cliente un proxy de sidecar compatible con la API de xDS (como Envoy) de VM o en un Pod de Kubernetes. Cloud Service Mesh actúa como el control y usa las APIs de xDS para comunicarse directamente con cada proxy. En los datos la aplicación envía el tráfico a la dirección VIP configurada en el regla de reenvío o recurso Mesh. El proxy de sidecar o tu aplicación de gRPC intercepta el tráfico y lo redirecciona al backend correspondiente.

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 un Implementación de Cloud Service Mesh. Muestra Cloud Service Mesh y la Recursos de Cloud Load Balancing para determinar el enrutamiento de tráfico. En el diagrama, se muestran las APIs de balanceo de cargas más antiguas.

Los recursos de la malla de servicios de Cloud que se configurarán.
Recursos de la malla de servicios de Cloud que se configurarán (haz clic para ampliar)

¿Qué sigue?