Información general sobre Cloud Service Mesh
Este documento está dirigido a administradores de redes y propietarios de servicios que quieran familiarizarse con Cloud Service Mesh y sus funciones. Este es un documento antiguo que se aplica a las configuraciones que usan las APIs de balanceo de carga.
Cloud Service Mesh es un plano de control gestionado para redes de aplicaciones. Cloud Service Mesh te permite ofrecer servicios globales de alta disponibilidad con funciones avanzadas de redes de aplicaciones, como la gestión del tráfico y la observabilidad.
A medida que aumenta el número de servicios y microservicios de tu implementación, normalmente empiezas a encontrarte con problemas comunes de redes de aplicaciones, como los siguientes:
- ¿Cómo puedo hacer que mis servicios sean resilientes?
- ¿Cómo consigo tráfico para mis servicios y cómo se comunican entre sí los servicios?
- ¿Cómo puedo saber qué ocurre cuando mis servicios se comunican entre sí?
- ¿Cómo puedo actualizar mis servicios sin correr el riesgo de que se produzca una interrupción?
- ¿Cómo gestiono la infraestructura que hace posible mi implementación?
Cloud Service Mesh te ayuda a resolver este tipo de problemas en una implementación moderna basada en servicios. Cloud Service Mesh se basa en una infraestructura gestionada por Google Cloudpara que no tengas que gestionar la tuya. Te centras en enviar código de aplicación que resuelva tus problemas empresariales y, al mismo tiempo, dejas que Cloud Service Mesh gestione las complejidades de la red de aplicaciones.
Cloud Service Mesh
Un patrón habitual para resolver los problemas de redes de aplicaciones es usar una malla de servicios. Cloud Service Mesh admite service mesh y otros patrones de despliegue que se ajustan a tus necesidades.
En una malla de servicios típica, se cumple lo siguiente:
- Despliega tus servicios en un clúster de Kubernetes.
- Cada uno de los pods de los servicios tiene un proxy dedicado (normalmente, Envoy) que se ejecuta como un proxy adicional.
- Cada proxy sidecar se comunica con la infraestructura de red (un plano de control) que está instalada en tu clúster. El plano de control informa a los proxies sidecar sobre los servicios, los endpoints y las políticas de tu malla de servicios.
- Cuando un pod envía o recibe una solicitud, esta se dirige al proxy sidecar del pod. El proxy sidecar gestiona la solicitud, por ejemplo, enviándola a su destino.
En los diagramas de este documento y de otros documentos de Cloud Service Mesh, los iconos rosas de seis lados representan los proxies. El plano de control está conectado a cada proxy y proporciona la información que los proxies necesitan para gestionar 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 gestiona la solicitud y la reenvía a Service B.
Este modelo te permite sacar la lógica de red del código de tu aplicación. Puedes centrarte en ofrecer valor empresarial y dejar que tu infraestructura se encargue de la red de aplicaciones.
Diferencias de Cloud Service Mesh
Cloud Service Mesh funciona de forma similar a ese modelo, pero se diferencia en aspectos importantes. Todo empieza con el hecho de que Cloud Service Mesh es un servicio gestionado porGoogle Cloud. No tienes que instalarlo, no se ejecuta en tu clúster y no tienes que 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 sidecar conectados a Cloud Service Mesh. Cloud Service Mesh proporciona la información que necesitan los proxies para enrutar las solicitudes. Por ejemplo, el código de una aplicación en un pod que pertenece a Service A envía una solicitud. El proxy sidecar que se ejecuta junto a este pod gestiona la solicitud y la dirige 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 multiclúster
Con Cloud Service Mesh, obtienes una red de aplicaciones que funciona en 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 de us-central1, entre los dos servicios de europe-west1 y entre los servicios de los dos clústeres.
Tu malla de servicios puede abarcar varios clústeres de Kubernetes en variasGoogle Cloud regiones. Los servicios de un clúster pueden comunicarse con los servicios de otro clúster. Incluso puedes tener servicios que consten de pods en varios clústeres.
Con el balanceo de carga global basado en la proximidad de Cloud Service Mesh, las solicitudes destinadas a Service B se dirigen al pod más cercano que pueda atenderlas. También obtienes una conmutación por error fluida: si un pod deja de funcionar, la solicitud se conmutará automáticamente a otro pod que pueda atenderla, aunque este pod esté en un clúster de Kubernetes diferente.
Máquinas virtuales
Kubernetes es cada vez más popular, pero muchas cargas de trabajo se despliegan en instancias de máquinas virtuales. Cloud Service Mesh también resuelve la red de aplicaciones de estas cargas de trabajo, por lo que tus cargas de trabajo basadas en máquinas virtuales pueden interoperar con tus cargas de trabajo basadas en Kubernetes.
En el siguiente diagrama, el tráfico entra en su despliegue a través del balanceador de carga de aplicaciones externo. Se dirige a Service A en el clúster de Kubernetes de asia-southeast1 y a Service D en una VM de europe-west1.
Google ofrece un mecanismo sencillo para configurar cargas de trabajo basadas en máquinas virtuales con Cloud Service Mesh. Solo tienes que añadir una marca a la plantilla de instancia de VM de Compute Engine y Google se encarga de la configuración de la infraestructura. Esta configuración incluye la instalación y la configuración de los proxies que proporcionan funciones de redes de aplicaciones.
gRPC sin proxy
gRPC es un framework de RPC de código abierto con muchas funciones que puedes usar para escribir microservicios de alto rendimiento. Con Cloud Service Mesh, puedes incorporar funciones de redes de aplicaciones (como el descubrimiento de servicios, el balanceo de carga y la gestión del tráfico) a tus aplicaciones gRPC. Para obtener más información, consulta Malla de servicios de Cloud y gRPC: servicios sin proxy para tu malla de servicios.
En el siguiente diagrama, las aplicaciones gRPC dirigen el tráfico a los servicios basados en clústeres de Kubernetes de una región y a los servicios que se ejecutan en máquinas virtuales de otras regiones. Dos de los servicios incluyen proxies sidecar y los demás no tienen proxy.
Cloud Service Mesh admite servicios gRPC sin proxy. Estos servicios usan una versión reciente de la biblioteca gRPC de código abierto que admite las APIs xDS. Tus aplicaciones gRPC pueden conectarse a Cloud Service Mesh mediante las mismas APIs xDS que usa Envoy.
Una vez que se hayan conectado tus aplicaciones, la biblioteca gRPC se encargará de las funciones de red de las aplicaciones, como la detección de servicios, el balanceo de carga y la gestión del tráfico. Estas funciones se ejecutan de forma nativa en gRPC, por lo que no se necesitan proxies de servicio. Por eso se denominan aplicaciones gRPC sin proxy.
Ingress y pasarelas
En muchos casos prácticos, debe [gestionar el tráfico que procede de clientes que no están configurados por Cloud Service Mesh. Por ejemplo, puede que tengas que introducir tráfico de Internet público en tus microservicios. También puedes configurar un balanceador de carga como proxy inverso que gestione el tráfico de un cliente antes de enviarlo a un destino.
En el siguiente diagrama, un balanceador de carga de aplicaciones externo permite el acceso a clientes externos, con el tráfico dirigido a los servicios de un clúster de Kubernetes. Un balanceador de carga de aplicaciones interno dirige 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 gestionada. Configura un balanceador de carga externo o interno y, a continuación, configúralo para que envíe tráfico a tus microservicios. En el diagrama anterior, los clientes de Internet público acceden a tus servicios a través del balanceador de carga de aplicaciones externo. Los clientes, como los microservicios que residen en tu red de nube privada virtual (VPC), usan un balanceador de carga de aplicaciones interno para acceder a tus servicios.
En algunos casos prácticos, puede que quieras configurar Cloud Service Mesh para configurar una puerta de enlace. Una pasarela es básicamente un proxy inverso, normalmente Envoy, que se ejecuta en una o varias máquinas virtuales, escucha las solicitudes entrantes, las gestiona y las envía a un destino. El destino puede estar en cualquier Google Cloud región o clúster de Google Kubernetes Engine (GKE). Incluso puede ser un destino que no sea deGoogle Cloud , pero al que se pueda acceder desde Google Cloud mediante la conectividad híbrida. Para obtener más información sobre cuándo usar una pasarela, consulta Tráfico de entrada de tu malla.
En el siguiente diagrama, una VM de la región europe-west1 ejecuta un proxy que actúa como puerta de enlace a tres servicios que no ejecutan proxies. El tráfico de un balanceador de carga de aplicación externo y de un balanceador de carga de aplicación interno se dirige a la pasarela y, a continuación, a los tres servicios.
Varios entornos
Tanto si tienes servicios en Google Cloud, en entornos on-premise, en otras nubes o en todos estos entornos, los problemas fundamentales de la red de aplicaciones siguen siendo los mismos. ¿Cómo consigue tráfico para estos servicios? ¿Cómo se comunican entre sí estos servicios?
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 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 proxy de sidecar, mientras que Service D es un servicio gRPC sin proxy.
Cuando usas Cloud Service Mesh, puedes enviar solicitudes a destinos que no estén enGoogle Cloud. De esta forma, puedes usar Cloud Interconnect o Cloud VPN para enrutar de forma privada el tráfico de los servicios de Google Cloud a los servicios o las pasarelas de otros entornos.
Configurar Cloud Service Mesh
La configuración de Cloud Service Mesh consta de dos pasos. Una vez que hayas completado el proceso de configuración, tu infraestructura se encargará de la red de aplicaciones y Cloud Service Mesh mantendrá todo actualizado en función de los cambios que se produzcan en tu implementación.
Desplegar aplicaciones
Primero, debes desplegar el código de tu aplicación en contenedores o máquinas virtuales. Google proporciona mecanismos que te permiten añadir infraestructura de redes de aplicaciones (normalmente, proxies de Envoy) a tus instancias de máquina virtual y pods. Esta infraestructura se configura para comunicarse con Cloud Service Mesh y obtener información sobre tus servicios.
Configurar Cloud Service Mesh
A continuación, configura tus servicios globales y define cómo se debe gestionar el tráfico. Para configurar Cloud Service Mesh, puedes usar la Google Cloud consola (para algunas funciones y configuraciones), la CLI de Google Cloud, la API Traffic Director u otras herramientas, como Terraform.
Una vez que hayas completado estos pasos, Cloud Service Mesh estará listo para configurar tu infraestructura de red de aplicaciones.
La infraestructura gestiona las redes de aplicaciones
Cuando una aplicación envía una solicitud a my-service, la infraestructura de red de tu aplicación (por ejemplo, un proxy sidecar de Envoy) gestiona la solicitud según la información recibida de Cloud Service Mesh. De esta forma, una solicitud de my-service se puede enrutar sin problemas a una instancia de aplicación que pueda recibirla.
Monitorización y actualizaciones continuas
Cloud Service Mesh monitoriza las instancias de aplicación que componen tus servicios. Esta monitorización permite a Cloud Service Mesh detectar si un servicio está en buen estado o si ha cambiado su capacidad (por ejemplo, cuando se crea un nuevo pod de Kubernetes). A partir de esta información, Cloud Service Mesh actualiza continuamente la infraestructura de red de tu aplicación.
Funciones
Las funciones de Cloud Service Mesh ofrecen funciones de red de aplicaciones a tus microservicios. En esta sección se destacan algunos de ellos.
Plano de control totalmente gestionado, comprobación del estado y balanceo de carga
Quieres dedicar tu tiempo a aportar valor a tu empresa, no a gestionar la infraestructura. Cloud Service Mesh es una solución totalmente gestionada, por lo que no tienes que instalar, configurar ni actualizar ninguna infraestructura. Te beneficias de la misma infraestructura que usa Google para las comprobaciones de estado y el balanceo de carga global.
Basado en productos de código abierto
Cloud Service Mesh usa el mismo plano de control (APIs xDS) que proyectos populares de código abierto como Envoy e Istio. Para ver las versiones de la API admitidas, consulta las APIs del plano de control xDS.
La infraestructura que ofrece funciones de redes de aplicaciones (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 propietaria.
Escalar
Cloud Service Mesh se ha diseñado para satisfacer tus necesidades de escalado, desde soluciones de redes de aplicaciones puntuales hasta implementaciones de mallas de servicios masivas con miles de servicios.
Descubrimiento de servicios y seguimiento de tus endpoints y backends
Cuando tu aplicación envía una solicitud a my-service, tu infraestructura gestiona la solicitud sin problemas y la envía al destino correcto. Tu aplicación no necesita saber nada sobre direcciones IP, protocolos u otras complejidades de la red.
Balanceo de carga global y conmutación por error
Cloud Service Mesh usa el balanceo de carga global y las comprobaciones de estado de Google para equilibrar de forma óptima el tráfico en función de la ubicación del cliente y del backend, la proximidad del backend, el estado y la capacidad. Mejora la disponibilidad de tu servicio haciendo que el tráfico conmute por error automáticamente a back-ends en buen estado con capacidad. Puedes personalizar el balanceo de carga para distribuir el tráfico de forma que se adapte a las necesidades de tu empresa.
Gestión del tráfico
La gestión avanzada del tráfico, que incluye el enrutamiento y la manipulación de solicitudes (en función del nombre de host, la ruta, los encabezados, las cookies y más), te permite determinar cómo fluye el tráfico entre tus servicios. También puedes aplicar acciones como reintentos, redirecciones y división del tráfico basada en el peso para las implementaciones canary. Los patrones avanzados, como la inyección de fallos, la proyección de tráfico y la detección de valores atípicos, permiten casos prácticos de DevOps que mejoran tu resiliencia.
Observabilidad
Tu infraestructura de red de aplicaciones recoge información de telemetría, como métricas, registros y trazas, que se puede agregar de forma centralizada en Google Cloud Observability. Una vez que se haya recogido esta información, podrá obtener estadísticas y crear alertas para que se le notifique si algo va mal.
Controles de Servicio de VPC
Puedes usar Controles de Servicio de VPC para reforzar la seguridad de los recursos y servicios de tu aplicación. Puede añadir proyectos a perímetros de servicio que protejan recursos y servicios (como Cloud Service Mesh) de solicitudes que procedan de fuera del perímetro. Para obtener más información sobre Controles de Servicio de VPC, consulta la información general sobre Controles de Servicio de VPC.
Para obtener más información sobre cómo usar Cloud Service Mesh con Controles de Servicio de VPC, consulta la página Productos admitidos.
Siguientes pasos
Este es un documento antiguo que se aplica principalmente a las APIs de balanceo de carga. Te recomendamos que no configures Cloud Service Mesh con las APIs de balanceo de carga.
Para desplegar Cloud Service Mesh, sigue estos pasos:
- En el caso de Compute Engine con máquinas virtuales, usa las APIs de enrutamiento de servicios.
- En Google Kubernetes Engine con pods, usa las APIs Gateway.
Para consultar casos prácticos y patrones de arquitectura de los servicios gRPC sin proxy, consulta la información general sobre los servicios gRPC sin proxy.
Para saber cómo te permite la gestión del tráfico controlar cómo se gestiona el tráfico, consulta la información general sobre la gestión avanzada del tráfico.
Para saber cómo admite Cloud Service Mesh los entornos que van más allá deGoogle Cloud, consulta los siguientes documentos: