Información general sobre Cloud Service Mesh con servicios gRPC sin proxy
En esta guía se ofrece una descripción general de la arquitectura de Cloud Service Mesh con servicios gRPC sin proxy, incluidos casos prácticos y patrones de arquitectura.
El plano de control gestionado de Cloud Service Mesh permite el enrutamiento global, el balanceo de carga y la conmutación por error regional para los casos prácticos de mallas de servicios y balanceo de carga. Esto incluye las implementaciones que incorporan proxies de sidecar y proxies de pasarela. La compatibilidad de Cloud Service Mesh con las aplicaciones de gRPC sin proxy ofrece un modelo de implementación adicional en el que las aplicaciones de gRPC pueden participar en una malla de servicios sin necesidad de un proxy sidecar.
En un ejemplo típico, un cliente de gRPC establece una conexión con un servidor de gRPC que aloja tu lógica de backend. Cloud Service Mesh proporciona a tus clientes gRPC información sobre los servidores con los que deben ponerse en contacto, cómo balancear la carga de las solicitudes a varias instancias de un servidor y qué hacer con las solicitudes si un servidor no está en funcionamiento.
Para obtener una descripción completa de cómo funciona Cloud Service Mesh, consulta la información general sobre Cloud Service Mesh.
Cómo funciona Cloud Service Mesh con aplicaciones gRPC
Cloud Service Mesh configura los clientes gRPC con una versión de gRPC compatible, de forma similar a como se configuran los proxies sidecar, como Envoy. Sin embargo, las aplicaciones de gRPC sin proxy conectadas directamente a Cloud Service Mesh no necesitan proxies sidecar. En su lugar, Cloud Service Mesh usa APIs xDS de código abierto para configurar directamente las aplicaciones gRPC. Estas aplicaciones gRPC actúan como clientes xDS y se conectan al plano de control global de Cloud Service Mesh. Una vez conectadas, las aplicaciones gRPC reciben configuración dinámica del plano de control, lo que permite la detección de endpoints, el balanceo de carga, la conmutación por error regional y las comprobaciones del estado. Este enfoque permite usar patrones de implementación adicionales de Cloud Service Mesh.
En la primera ilustración, se habilita una malla de servicios mediante un proxy sidecar.
Para configurar un proxy adicional, Cloud Service Mesh usa las APIs de xDS. Los clientes se comunican con el servidor a través del proxy sidecar.
En la segunda ilustración, se habilita una malla de servicios sin un proxy sidecar mediante un cliente gRPC sin proxy.
Si solo vas a desplegar servicios gRPC que Cloud Service Mesh configure, puedes crear una malla de servicios sin desplegar ningún proxy. De esta forma, te resultará más fácil incorporar las funciones de malla de servicios a tus aplicaciones gRPC.
Resolución de nombres
La resolución de nombres funciona en las implementaciones sin proxy de las siguientes formas:
- Cuando te conectas a un servicio, defines
xdscomo el esquema de resolución de nombres en el canal del cliente gRPC. El URI de destino tiene el formatoxds:///hostname:port. Si no se especifica el puerto, el valor predeterminado es 80. Por ejemplo, en el URI de destinoxds:///example.hostname. - El cliente gRPC resuelve el
hostname:porten el URI de destino enviando una solicitud de servicio de detección de listeners (LDS) a Cloud Service Mesh. - Cloud Service Mesh busca las reglas de reenvío configuradas que tengan un puerto coincidente. A continuación, busca el mapa de URLs correspondiente a una regla de host que coincida con
hostname:port. Devuelve la configuración de enrutamiento asociada al cliente gRPC.
Las reglas de host que configure en Cloud Service Mesh deben ser únicas en todos los mapas de URLs. Por ejemplo, example.hostname, example.hostname:80 y example.hostname:8080 son reglas diferentes.
Resolución de nombres con diferentes tipos de implementaciones
El esquema de resolución de nombres es diferente en los despliegues sin proxy y en los que usan proxies de Envoy.
El cliente gRPC usa el esquema de resolución de nombres xds para conectarse a un servicio, lo que permite al cliente recibir la configuración del servicio de Cloud Service Mesh. A continuación, el cliente de gRPC se comunica directamente con el servidor de gRPC.
Puedes combinar los patrones de implementación de proxy sidecar y sin proxy para aumentar la flexibilidad. Combinar patrones es especialmente útil cuando tu organización y tu red admiten varios equipos con diferentes requisitos de funciones, necesidades operativas y versiones de gRPC.
En la siguiente ilustración, tanto los clientes de gRPC sin proxy como los clientes de gRPC con un proxy sidecar se comunican con un servidor de gRPC. Los clientes de gRPC con proxies sidecar usan el esquema de resolución de nombres dns.
Casos prácticos
Los siguientes casos prácticos te ayudarán a entender cuándo puedes usar Cloud Service Mesh con aplicaciones de gRPC sin proxy. Tu despliegue puede incluir aplicaciones gRPC sin proxy, aplicaciones gRPC con proxies sidecar o una combinación de ambas.
Eficiencia de recursos en una malla de servicios a gran escala
Si tu malla de servicios incluye cientos o miles de clientes y back-ends, es posible que el consumo total de recursos al ejecutar proxies sidecar empiece a aumentar. Cuando usas aplicaciones gRPC sin proxy, no tienes que introducir proxies sidecar en tu implementación. Un enfoque sin proxy puede dar lugar a mejoras en la eficiencia.
Aplicaciones gRPC de alto rendimiento
En algunos casos prácticos, cada milisegundo de latencia de solicitud y respuesta es importante. En ese caso, es posible que la latencia se reduzca si usas una aplicación gRPC sin proxy en lugar de enviar cada solicitud a través de un proxy sidecar del lado del cliente y, posiblemente, de un proxy sidecar del lado del servidor.
Service mesh para entornos en los que no puedes desplegar proxies adicionales
En algunos entornos, es posible que no puedas ejecutar un proxy sidecar como proceso adicional junto con tu aplicación cliente o servidor. O bien, es posible que no puedas configurar la pila de red de una máquina para interceptar y redirigir solicitudes (por ejemplo, mediante iptables).
En este caso, puedes usar Cloud Service Mesh con aplicaciones de gRPC sin proxy para introducir las funciones de malla de servicios en tus aplicaciones de gRPC.
Malla de servicios heterogénea
Como tanto las aplicaciones gRPC sin proxy como Envoy se comunican con Cloud Service Mesh, tu malla de servicios puede incluir ambos modelos de implementación. Si incluyes ambos modelos, podrás satisfacer las necesidades operativas, de rendimiento y de funciones específicas de diferentes aplicaciones y equipos de desarrollo.
Migrar de una malla de servicios con proxies a una malla sin proxies
Si ya tienes una aplicación gRPC con un proxy sidecar que tiene configurado Cloud Service Mesh, puedes cambiar a una aplicación gRPC sin proxy.
Cuando se implementa un cliente gRPC con un proxy sidecar, usa DNS para resolver el nombre de host al que se conecta. El proxy sidecar intercepta el tráfico para proporcionar funciones de malla de servicios.
Puedes definir si un cliente de gRPC usa la ruta sin proxy o la ruta de proxy sidecar para comunicarse con un servidor de gRPC modificando el esquema de resolución de nombres que utiliza. Los clientes sin proxy usan el esquema de resolución de nombres xds, mientras que los proxies sidecar usan el esquema de resolución de nombres dns. Algunos clientes de gRPC pueden incluso usar la ruta sin proxy cuando se comunican con un servidor de gRPC, pero usar la ruta del proxy sidecar cuando se comunican con otro servidor de gRPC. De esta forma, puedes migrar gradualmente a un despliegue sin proxy.
Para migrar de una malla de servicios con proxies a una malla sin proxies, debes crear un servicio de Cloud Service Mesh que use tu cliente de gRPC sin proxy. Puedes usar las mismas APIs para configurar Cloud Service Mesh en las versiones actuales y nuevas.
Arquitectura y recursos
El modelo de datos de configuración de los servicios gRPC sin proxy amplía el modelo de configuración de Cloud Service Mesh, con algunas adiciones y limitaciones que se describen en esta guía. Algunas de estas limitaciones son temporales, ya que gRPC sin proxy no admite todas las funciones de Envoy, y otras son inherentes al uso de RPCs. Por ejemplo, no se admiten las redirecciones HTTP que usan gRPC. Para entender el modelo de configuración de esta guía, te recomendamos que te familiarices con los conceptos y la configuración de Cloud Service Mesh.
En el siguiente diagrama se muestran los recursos que debe configurar para las aplicaciones gRPC sin proxy.
Comprobaciones del estado
Una comprobación del estado de gRPC puede comprobar el estado de un servicio gRPC que se esté ejecutando en una instancia de máquina virtual (VM) de backend o en un grupo de puntos finales de red (NEG).
Si no se puede usar una comprobación de estado de gRPC porque tu servidor gRPC no implementa el protocolo de comprobación de estado de gRPC, usa una comprobación de estado de TCP. No uses una comprobación de estado de HTTP, HTTPS o HTTP/2.
Para obtener más información, consulta Comprobación del estado de gRPC y Bandera adicional para las comprobaciones del estado de gRPC.
Servicio de backend
El servicio de backend define cómo se comunica un cliente gRPC con un servidor gRPC.
Cuando crees un servicio de backend para gRPC, define el campo de protocolo como GRPC.
También se puede acceder a un servicio de backend configurado con el protocolo
GRPCmediante aplicaciones gRPC a través de un proxy sidecar. En ese caso, el cliente de gRPC no debe usar el esquema de resolución de nombresxds.En todas las implementaciones de Cloud Service Mesh, el esquema de balanceo de carga del servicio de backend debe ser
INTERNAL_SELF_MANAGED.
Backends
Los back-ends alojan las instancias de tu servidor gRPC. Puedes usar grupos de instancias gestionados o no gestionados en Compute Engine y NEGs zonales en Google Kubernetes Engine como back-ends para alojar tus instancias de servidor gRPC.
Siguientes pasos
- Para obtener información sobre las APIs de enrutamiento de servicios y cómo funcionan, consulta la descripción general.
- Para prepararte para configurar Cloud Service Mesh con aplicaciones de gRPC sin proxy, consulta Prepararse para la configuración con Envoy y cargas de trabajo sin proxy.
- Para obtener información sobre las limitaciones que se aplican a los despliegues de gRPC sin proxy, consulta Límites y limitaciones con gRPC sin proxy.