Descripción general de Cloud Service Mesh
Este documento está dirigido a los administradores de red y a los propietarios de servicios que deseen familiarizarse con Cloud Service Mesh y sus capacidades. Este es un documento heredado que se aplica a las configuraciones que usan 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 capacidades avanzadas de red de aplicaciones, como la administración del tráfico 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 un entorno una implementación basada en servicios. La malla de servicios de Cloud se basa infraestructura para que no tengas que administrar tu propia infraestructura. Tú enfocarse en enviar código de la aplicación que resuelva tus problemas empresariales mientras lo que permite que Cloud Service Mesh administre las complejidades de las redes de 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 malla de servicios y otros patrones de implementación que se ajusten 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 y otros documentos de Cloud Service Mesh,
los iconos rosas laterales 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 mover la lógica de red fuera de tu aplicación código. 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
La malla de servicios de Cloud funciona de manera similar a ese modelo, pero es diferente en cuanto a maneras. Todo comienza con el hecho de que Cloud Service Mesh es una 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. Existen cuatro
servicios en este clúster de Kubernetes, cada uno con proxies de sidecar que
conectadas a la malla de servicios de Cloud. Cloud Service Mesh proporciona la información que
los proxies deben enrutar las 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 toda
clústeres de Kubernetes. En el siguiente diagrama, Cloud Service Mesh proporciona la
plano de control para 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 proximidad de Cloud Service Mesh,
destinados 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). La malla de servicios de Cloud resuelve las redes de aplicaciones para estas cargas de trabajo. tus cargas de trabajo basadas en VM interoperan con para tus cargas de trabajo 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 la malla de servicios en la nube. 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 aportar capacidades de redes de aplicaciones (como el descubrimiento de servicios, el balanceo de cargas y la administración del tráfico) a tus aplicaciones de gRPC. Para 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 con las mismas APIs de xDS que usa Envoy.
Después de conectar tus aplicaciones, la biblioteca de gRPC se encarga de funciones de red de aplicaciones, como el descubrimiento de servicios, y la administración del tráfico. Estas funciones ocurren de forma nativa en gRPC, así que los proxies no son necesarios; por eso se denominan gRPC sin proxy. aplicaciones.
Entrada y puertas de enlace
Para muchos casos de uso, es necesario [manejar el tráfico que se origina de los clientes que no configura Malla de servicios de Cloud. 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 con tráfico enrutado a servicios en un clúster de Kubernetes. Los el balanceador de cargas de aplicaciones interno enruta el tráfico interno al servicio que se ejecuta en la VM.
La malla de servicios de Cloud funciona con Cloud Load Balancing para proporcionar un de entrada administrada. Debes configurar un balanceador de cargas externo o interno y, luego, configurarlo para enviar tráfico a los microservicios. En En el diagrama anterior, los clientes públicos de Internet llegan a tus servicios a través del balanceador de cargas de aplicaciones externo. Clientes, como microservicios que residen en tu red de nube privada virtual (VPC), usa un balanceador de cargas de aplicaciones interno para llegar a tus servicios.
En algunos casos de uso, es posible que desees configurar Cloud Service Mesh para establecer 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 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. Tráfico
de un balanceador de cargas de aplicaciones externo y uno 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 desde los servicios
que se ejecutan en Google Cloud para Service G, que se ejecuta 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 en 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 del proceso de configuración, tu infraestructura controla las redes de las aplicaciones y Cloud Service Mesh mantiene todo actualizado según los cambios en tu de Google Workspace.
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 redes de aplicaciones (por lo general, con proxies de Envoy) a las instancias de VM y los Pods. Esta infraestructura está para hablar 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. Para configurar Cloud Service Mesh, puedes usar la consola de Google Cloud (para algunas funciones y configuraciones), Google Cloud CLI, la API de Traffic Director, entre otras de software, como Terraform.
Después de que completes estos pasos, Cloud Service Mesh estará listo para configurar tu infraestructura de red de aplicaciones.
Infraestructura maneja las redes de aplicaciones
Cuando una aplicación envía una solicitud a my-service, las herramientas de redes de tu 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 aplicación que constituyen tu de Google Cloud. Esta supervisión permite que Cloud Service Mesh descubra que un servicio está en buen estado o que la capacidad de un servicio cambió, por ejemplo, cuando se crea se crea el Pod de Kubernetes. Según esta información, Cloud Service Mesh actualiza de forma continua la infraestructura de red de las aplicaciones.
Funciones
Las funciones de Cloud Service Mesh las capacidades de red 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 tienes que instalar, configurar o 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 (APIs de xDS) que proyectos populares de código abierto, como Envoy y uso de Istio. Para ver las versiones compatibles de la API, consulta las APIs del plano de control de xDS.
La infraestructura que entrega las herramientas de redes de las aplicaciones capacidades, ya sea Envoy o gRPC según tu caso de uso, también es de código abierto, de estar limitado a una infraestructura de propiedad exclusiva.
Escala
Desde soluciones de redes de aplicaciones únicas hasta una malla de servicios masiva con miles de servicios, Cloud Service Mesh está diseñado para satisfacer tus los requisitos de escalamiento.
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. Tu
no necesita saber nada sobre
Direcciones IP, protocolos y otras complejidades de red.
Balanceo de cargas y conmutación por error global
Cloud Service Mesh usa el balanceo de cargas global de Google y verificaciones de estado para equilibrar de forma óptima el tráfico basado en la ubicación del cliente y del backend, la proximidad del backend, el estado y la capacidad de procesamiento. Para mejorar la disponibilidad del servicio, haces que el tráfico se realice automáticamente conmutación por error hacia backends en buen estado con la capacidad de procesamiento. Puedes personalizar el balanceo de cargas para distribuir el tráfico y satisfacer las necesidades de tu empresa.
Administración del tráfico
Administración avanzada del tráfico, que incluye el enrutamiento y la manipulación de solicitudes (basada en nombre de host, ruta de acceso, encabezados, cookies y más), te permite determinar cómo los flujos de 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 pueden agregarse de forma centralizada Observabilidad de Google Cloud. 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 protegen los 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 admitidos.
¿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 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.
Descubrir cómo Cloud Service Mesh admite entornos que se extienden más allá Google Cloud, consulta los siguientes documentos: