Descripción general de Cloud Service Mesh
Este documento está dirigido a los administradores de red y los propietarios de servicios que deseen familiarizarse con Cloud Service Mesh y sus funciones. Este es un documento heredado que se aplica a la configuración que usa las APIs de balanceo de cargas.
Cloud Service Mesh es un plano de control administrado para las herramientas de redes de aplicaciones. Cloud Service Mesh te permite entregar servicios globales con alta disponibilidad con funciones avanzadas de redes de aplicaciones, como la administración del tráfico y la observabilidad.
A medida que crece la cantidad de servicios y microservicios en tu implementación, sueles enfrentarte a desafíos comunes de las herramientas de redes de aplicaciones como los siguientes:
- ¿Cómo hago que mis servicios sean resilientes?
- ¿Cómo obtengo tráfico a mis servicios y cómo los servicios se enteran del resto o se comunican entre sí?
- ¿Cómo puedo entender lo que sucede cuando mis servicios se comunican entre sí?
- ¿Cómo actualizo mis servicios sin arriesgar una interrupción?
- ¿Cómo administro la infraestructura que permite mi implementación?
Cloud Service Mesh te ayuda a resolver este tipo de desafíos en una implementación moderna basada en servicios. Cloud Service Mesh se basa en la infraestructura administrada por Google Cloud para que no tengas que administrar tu propia infraestructura. Enfócate en enviar el código de la aplicación que resuelva los problemas empresariales mientras permites que Cloud Service Mesh administre las complejidades de las redes de las aplicaciones.
Cloud Service Mesh
Un patrón común para resolver los desafíos de las herramientas de redes de aplicaciones es usar una malla de servicios. Cloud Service Mesh admite una malla de servicios y otros patrones de implementación que se adaptan a tus necesidades.
En una malla de servicios común, se cumple lo siguiente:
- Implementas tus servicios en un clúster de Kubernetes.
- Cada Pod de los servicios tiene un proxy dedicado (por lo general, Envoy) que se ejecuta como un proxy de sidecar.
- Cada proxy de sidecar se comunica con la infraestructura de red (un plano de control) instalado en tu clúster. El plano de control informa a los proxies de sidecar sobre los servicios, los extremos y las políticas en tu malla de servicios.
- Cuando un Pod envía o recibe una solicitud, la solicitud va al proxy de sidecar del Pod. El proxy de sidecar controla la solicitud, por ejemplo, la envía a su destino previsto.
En los diagramas de este documento y otros documentos de Cloud Service Mesh, los íconos rosas de seis lados representan los proxies. El plano de control se conecta a cada proxy y proporciona información que los proxies necesitan para controlar las solicitudes. Las flechas entre los cuadros muestran los flujos de tráfico. Por ejemplo, el código de la aplicación en Service A envía una solicitud. El proxy controla la solicitud y la reenvía a Service B.
Este modelo te permite quitar la lógica de red del código de la aplicación. Puedes enfocarte en ofrecer valor empresarial mientras tu infraestructura se encarga de las herramientas de redes de la aplicación.
En qué se diferencia Cloud Service Mesh
Cloud Service Mesh funciona de manera similar a ese modelo, pero lo hace diferente en aspectos importantes. Todo comienza con el hecho de que Cloud Service Mesh es un servicio administrado por Google Cloud. No se instala, no se ejecuta en tu clúster y no necesitas mantenerlo.
En el siguiente diagrama, Cloud Service Mesh es el plano de control. Hay cuatro servicios en este clúster de Kubernetes, cada uno con proxies de sidecar que están conectados a Cloud Service Mesh. La malla de servicios de Cloud brinda la
información necesaria para enrutar solicitudes. Por ejemplo, el código de la aplicación en un Pod que pertenece a Service A envía una solicitud. El proxy de sidecar que se ejecuta junto con este Pod controla la solicitud y la enruta a un Pod que pertenece a Service B.
Más allá de la malla de servicios
Cloud Service Mesh admite más tipos de implementaciones que una malla de servicios típica.
Kubernetes de varios clústeres
Con Cloud Service Mesh, obtienes redes de aplicaciones que funcionan en los clústeres de Kubernetes. En el siguiente diagrama, Cloud Service Mesh proporciona el plano de control para los clústeres de Kubernetes en us-central1 y europe-west1.
Las solicitudes se pueden enrutar entre los tres servicios en us-central1, entre los dos servicios en europe-west1 y entre los servicios en los dos clústeres.
La malla de servicios se puede extender a múltiples clústeres de Kubernetes en varias regiones de Google Cloud. Los servicios en un clúster pueden comunicarse con los servicios en otro clúster. Incluso puedes tener servicios que tienen pods en varios clústeres.
Con el balanceo de cargas global basado en la proximidad de Cloud Service Mesh, las solicitudes destinadas a Service B se dirigen al pod más cercano que puede entregar la solicitud. También obtienes una conmutación por error sin problemas. Si un Pod está inactivo, la solicitud se conmuta por error de forma automática a otro Pod que puede entregar la solicitud, incluso si este Pod está en un clúster de Kubernetes diferente.
Máquinas virtuales
Kubernetes se está volviendo más popular, pero muchas cargas de trabajo se implementan en instancias de máquina virtual (VM). Cloud Service Mesh también resuelve las herramientas de redes de aplicaciones para estas cargas de trabajo. Las cargas de trabajo basadas en VM interoperan con las basadas en Kubernetes.
En el siguiente diagrama, el tráfico ingresa a tu implementación a través del balanceador de cargas de aplicaciones externo. Se enruta a Service A en el clúster de Kubernetes en asia-southeast1 y a Service D en una VM en europe-west1.
Google proporciona un mecanismo sin interrupciones para configurar cargas de trabajo basadas en VM con Cloud Service Mesh. Solo agregas una marca a la plantilla de instancias de VM de Compute Engine y Google maneja la configuración de la infraestructura. Esta configuración incluye instalar y configurar los proxies que entregan capacidades de herramientas de redes de aplicaciones.
gRPC sin proxy
gRPC es un marco de trabajo de RPC de código abierto con muchas funciones que puedes usar para escribir microservicios de alto rendimiento. Con Cloud Service Mesh, puedes llevar las funciones de red de aplicaciones (como el descubrimiento de servicios, el balanceo de cargas y la administración del tráfico) a tus aplicaciones de gRPC. Si deseas obtener más información, consulta Cloud Service Mesh y gRPC: servicios sin proxy para tu malla de servicios.
En el siguiente diagrama, las aplicaciones de gRPC enrutan el tráfico a servicios basados en clústeres de Kubernetes en una región y a servicios que se ejecutan en VM en regiones diferentes. Dos de los servicios incluyen proxies de sidecar, y los otros no tienen proxy.
Cloud Service Mesh admite servicios de gRPC sin proxy. Estos servicios usan una versión reciente de la biblioteca de gRPC de código abierto que admite las API de xDS. Tus aplicaciones de gRPC pueden conectarse a Cloud Service Mesh mediante las mismas API de xDS que usa Envoy.
Después de conectar tus aplicaciones, la biblioteca de gRPC se encarga de las funciones de red de aplicaciones, como el descubrimiento de servicios, el balanceo de cargas y la administración del tráfico. Estas funciones ocurren de forma nativa en gRPC, por lo que no se requieren proxies de servicio, por eso se llaman aplicaciones de gRPC sin proxy.
Entrada y puertas de enlace
Para muchos casos de uso, debes [controlar el tráfico que se origina de clientes que no están configurados por Cloud Service Mesh. Por ejemplo, es posible que debas ingresar tráfico de Internet público a los microservicios. También se recomienda configurar un balanceador de cargas como un proxy inverso que controle el tráfico desde un cliente antes de enviarlo a un destino.
En el siguiente diagrama, un balanceador de cargas de aplicaciones externo habilita la entrada de clientes externos, con tráfico enrutado a servicios en un clúster de Kubernetes. Un balanceador de cargas de aplicaciones interno enruta el tráfico interno al servicio que se ejecuta en la VM.
Cloud Service Mesh funciona con Cloud Load Balancing para proporcionar una experiencia de entrada administrada. Debes configurar un balanceador de cargas externo o interno y, luego, configurarlo para enviar tráfico a los microservicios. En el diagrama anterior, los clientes públicos de Internet llegan a tus servicios a través del balanceador de cargas de aplicaciones externo. Los clientes, como los microservicios que residen en tu red de nube privada virtual (VPC), usan un balanceador de cargas de aplicaciones interno para llegar a los servicios.
En algunos casos de uso, es posible que desees configurar Cloud Service Mesh para configurar una puerta de enlace. Esta puerta de enlace es, en esencia, un proxy inverso, por lo general, Envoy que se ejecuta en una o más VM, que escucha las solicitudes entrantes, las administra y las envía a un destino. El destino puede estar en cualquier región de Google Cloud o clúster de Google Kubernetes Engine (GKE). Incluso puede ser un destino fuera de Google Cloud al que se pueda acceder desde Google Cloud mediante la conectividad híbrida. Para obtener más información sobre cuándo usar una puerta de enlace, consulta Tráfico de entrada para la malla.
En el siguiente diagrama, una VM en la región europe-west1 ejecuta un proxy que actúa como una puerta de enlace a tres servicios que no ejecutan proxies. El tráfico de un balanceador de cargas de aplicaciones externo y de un balanceador de cargas de aplicaciones interno se enruta a la puerta de enlace y, luego, a los tres servicios.
Varios entornos
Si tienes servicios en Google Cloud, de manera local, en otras nubes o en todos los anteriores, los desafíos fundamentales de las herramientas de redes de la aplicación son los mismos. ¿Cómo obtienes tráfico a estos servicios? ¿Cómo los servicios se comunican entre sí?
En el siguiente diagrama, Cloud Service Mesh enruta el tráfico de los servicios que se ejecutan en Google Cloud a Service G, que se ejecutan en otra nube pública, y a Service E y Service F, que se ejecutan en un centro de datos local.
Service A, Service B y Service C, usan Envoy como un proxy de sidecar, mientras que Service D es un servicio de gRPC sin proxy.
Cuando usas Cloud Service Mesh, puedes enviar solicitudes a destinos fuera de Google Cloud. Esto te permite usar Cloud Interconnect o Cloud VPN para enrutar el tráfico de forma privada desde servicios dentro de Google Cloud hasta servicios o puertas de enlace en otros entornos.
Configura Cloud Service Mesh
La configuración de Cloud Service Mesh consta de dos pasos. Después de completar el proceso de configuración, tu infraestructura controla las redes de la aplicación y Cloud Service Mesh mantiene todo actualizado según los cambios en tu implementación.
Implementa tus aplicaciones
Primero, implementas el código de la aplicación en contenedores o VM. Google proporciona mecanismos que te permiten agregar infraestructura de herramientas de redes de aplicaciones (por lo general, proxies de Envoy) a tus instancias de VM y Pods. Esta infraestructura está configurada para comunicarse con Cloud Service Mesh y aprender sobre tus servicios.
Configura Cloud Service Mesh
A continuación, configura los servicios globales y define cómo se debe manejar el tráfico. Si deseas configurar Cloud Service Mesh, puedes usar la consola de Google Cloud (para algunas funciones y parámetros de configuración), Google Cloud CLI, la API de Traffic Director y otras herramientas, como Terraform.
Después de completar estos pasos, Cloud Service Mesh estará listo para configurar la infraestructura de red de tu aplicación.
Infraestructura maneja las redes de aplicaciones
Cuando una aplicación envía una solicitud a my-service, la infraestructura de red de la aplicación (por ejemplo, un proxy de sidecar de Envoy) controla la solicitud según la información recibida de Cloud Service Mesh. Esto habilita una solicitud con el objetivo de que my-service se enrute sin interrupciones a una instancia de aplicación que puede recibir la solicitud.
Supervisión y actualizaciones continuas
Cloud Service Mesh supervisa las instancias de aplicaciones que constituyen tus servicios. Esta supervisión permite que Cloud Service Mesh detecte que un servicio está en buen estado o que su capacidad cambió, por ejemplo, cuando se crea un Pod de Kubernetes nuevo. Según esta información, Cloud Service Mesh actualiza la infraestructura de red de tu aplicación de forma continua.
Funciones
Las funciones de Cloud Service Mesh brindan capacidades de redes de aplicaciones a tus microservicios. En esta sección, se analizan algunos aspectos destacados.
Plano de control completamente administrado, verificación de estado y balanceo de cargas
Deseas invertir tu tiempo en entregar valor empresarial, no en administrar la infraestructura. Cloud Service Mesh es una solución completamente administrada, por lo que no necesitas instalar, configurar ni actualizar la infraestructura. Aprovechas la misma infraestructura que usa Google para las verificaciones de estado y el balanceo de cargas global.
Compila en productos de código abierto
Cloud Service Mesh usa el mismo plano de control (API de xDS) que usan los proyectos de código abierto populares, como Istio y Envoy. Para ver las versiones de API compatibles, consulta las APIs del plano de control de xDS.
La infraestructura que ofrece capacidades de red para aplicaciones, ya sea Envoy o gRPC, según el caso práctico, también es de código abierto, por lo que no tienes que preocuparte por depender de una infraestructura de propiedad exclusiva.
Escalabilidad
Cloud Service Mesh se creó para cumplir con tus requisitos de escalamiento, desde soluciones de redes de aplicaciones únicas hasta implementaciones masivas de malla de servicios con miles de servicios.
Descubrimiento de servicios y seguimiento de tus extremos y backends
Cuando la aplicación envía una solicitud a my-service, la infraestructura maneja la solicitud sin problemas y la envía al destino correcto. La aplicación no necesita saber nada sobre direcciones IP, protocolos ni otras complejidades de red.
Balanceo de cargas y conmutación por error global
Cloud Service Mesh usa el balanceo de cargas global y la verificación de estado de Google para equilibrar de forma óptima el tráfico según la ubicación del cliente y del backend, la proximidad del backend, el estado y la capacidad. Para mejorar la disponibilidad del servicio, puedes hacer que el tráfico realice conmutaciones por error de forma automática hacia backends en buen estado con capacidad. Puedes personalizar el balanceo de cargas para distribuir el tráfico y satisfacer adecuadamente tus necesidades empresariales.
Administración del tráfico
La administración avanzada del tráfico, incluidos el enrutamiento y la manipulación de solicitudes (según el nombre de host, la ruta de acceso, los encabezados, las cookies y más), te permiten determinar cómo fluye el tráfico entre tus servicios. También puedes aplicar acciones como reintentos, redireccionamientos y división de tráfico según el peso para las implementaciones de versiones canary. Los patrones avanzados, como la inserción de errores, la duplicación de tráfico y la detección de valores atípicos, permiten casos de uso de DevOps que mejoran la resiliencia.
Observabilidad
La infraestructura de red de aplicaciones recopila información de telemetría, como métricas, registros y seguimientos, que se pueden agregar de forma centralizada en Google Cloud Observability. Después de recopilar esta información, puedes obtener estadísticas y crear alertas para que, si algo sale mal, se te notifique.
Controles del servicio de VPC
Puedes usar los Controles del servicio de VPC a fin de proporcionar seguridad adicional para los recursos y servicios de tu aplicación. Puedes agregar proyectos a perímetros de servicio que protejan recursos y servicios (como Cloud Service Mesh) de las solicitudes que se originan fuera del perímetro. Para obtener más información sobre los Controles del servicio de VPC, consulta la Descripción general de los Controles del servicio de VPC.
Para obtener más información sobre el uso de Cloud Service Mesh con los Controles del servicio de VPC, consulta la página Productos compatibles.
¿Qué sigue?
Este es un documento heredado que se aplica principalmente a las APIs de balanceo de cargas. Te recomendamos que no configures Cloud Service Mesh con las APIs de balanceo de cargas.
Para implementar Cloud Service Mesh, sigue estos pasos:
- Para Compute Engine con VMs, usa las APIs de Service Enrutamiento.
- Para Google Kubernetes Engine con Pods, usa las APIs de Gateway.
Si deseas encontrar casos prácticos y patrones de arquitectura para servicios de gRPC sin proxy, consulta la descripción general de los servicios de gRPC sin proxy.
Para obtener información sobre cómo la administración del tráfico te permite controlar la manera en que se maneja el tráfico, consulta la Descripción general de la administración avanzada del tráfico.
Para obtener información sobre cómo Cloud Service Mesh admite entornos más allá de Google Cloud, consulta los siguientes documentos: