Descripción general de Cloud Service Mesh con servicios de gRPC sin proxy
En esta guía, se brinda una descripción general de la arquitectura de Cloud Service Mesh con servicios de gRPC sin proxy, incluidos los casos de uso y los patrones de arquitectura.
El plano de control administrado de Cloud Service Mesh permite el enrutamiento global, el balanceo de cargas y la conmutación por error regional para los casos de uso del balanceo de cargas y la malla de servicios. Esto incluye implementaciones que incorporan proxies de sidecar y de puerta de enlace. La compatibilidad de Cloud Service Mesh para 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 de 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 brinda a tus clientes de gRPC información sobre con qué servidores contactar, cómo balancear las cargas de solicitudes varias instancias de un servidor, y qué hacer con las solicitudes si un servidor no está en ejecución.
Para obtener una descripción general completa del funcionamiento de Cloud Service Mesh, consulta la Descripción general de Cloud Service Mesh.
Cómo funciona Cloud Service Mesh con aplicaciones de gRPC
Cloud Service Mesh configura clientes gRPC con un versión de gRPC compatible, de manera similar a cómo se configuran los proxies de sidecar, como Envoy. Sin embargo, las aplicaciones de gRPC sin proxy conectadas directamente con Cloud Service Mesh no necesitan proxies de sidecar. En cambio, Cloud Service Mesh usa APIs de xDS de código abierto para configurar aplicaciones de gRPC directamente. Estas aplicaciones de gRPC actúan como clientes de xDS, que se conectan al plano de control global de Cloud Service Mesh. Después de que se conecten, las aplicaciones de gRPC reciben la configuración dinámica del plano de control, lo que habilita el descubrimiento de extremos, el balanceo de cargas, la conmutación por error regional y las verificaciones de estado. Este enfoque habilita patrones de implementación adicionales de Cloud Service Mesh.
En la primera ilustración, se habilita una malla de servicios mediante un proxy de sidecar.
Para configurar un proxy de sidecar, Cloud Service Mesh usa las APIs de xDS. Los clientes se comunican con el servidor a través del proxy de sidecar.
En la segunda ilustración, se habilita una malla de servicios sin un proxy de sidecar mediante un cliente de gRPC sin proxy.
Si solo implementas servicios de gRPC que configura Cloud Service Mesh, puedes crear una malla de servicios sin implementar ningún proxy. Esto hace que llevar funciones de la malla de servicios a las aplicaciones de gRPC sea más fácil.
Resolución de nombres
La resolución de nombres funciona para implementaciones sin proxy de las siguientes maneras:
- Debes establecer
xdscomo el esquema de resolución de nombres en el canal del cliente de gRPC cuando te conectas a un servicio. El URI de destino tiene el formatoxds:///hostname:port. Cuando no se especifica el puerto, el valor predeterminado es 80, por ejemplo, en el URI de destinoxds:///example.hostname. - El cliente de gRPC resuelve el
hostname:porten el URI de destino mediante el envío de una solicitud de servicio de detección de objetos de escucha (LDS) a la malla de servicios en la nube. - Cloud Service Mesh busca las reglas de reenvío configuradas que tienen
un puerto coincidente. Luego, busca el mapa de URL correspondiente para una regla de host que coincide con
hostname:port. Muestra la configuración de enrutamiento asociada con el cliente de gRPC.
Las reglas de host que configures en Cloud Service Mesh deben ser únicas
todos los mapas de URL. Por ejemplo, example.hostname, example.hostname:80 y example.hostname:8080 son reglas diferentes.
Resolución de nombres con tipos de implementación diferentes
El esquema de resolución de nombres es diferente para las implementaciones sin proxy y las que usan proxies de Envoy.
El cliente de gRPC usa el esquema de resolución de nombres de xds para conectarse a un servicio, lo que le permite al cliente recibir la configuración del servicio de Cloud Service Mesh. Luego, el cliente de gRPC se comunica directamente con el servidor de gRPC.
Puedes combinar patrones de implementación de archivo de sidecar y sin proxy para aumentar la flexibilidad. Esto es muy útil cuando la organización y la red admiten varios equipos con diferentes requisitos de funciones, necesidades operativas y versiones de gRPC.
En la siguiente ilustración, los clientes de gRPC sin proxy y los clientes de gRPC con un proxy de sidecar se comunican con un servidor de gRPC. Los clientes de gRPC con proxies de sidecar usan el esquema de resolución de nombres de dns.
Casos de uso
Los siguientes casos de uso te ayudan a comprender cuándo es posible que desees usar Cloud Service Mesh con aplicaciones de gRPC sin proxy. Tu implementación puede incluir aplicaciones de gRPC sin proxy, aplicaciones de gRPC con proxies de 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 backends, es posible que aumente el consumo total de recursos por la ejecución de proxies de sidecar. Cuando usas aplicaciones de gRPC sin proxy, no necesitas ingresar proxies de sidecar a la implementación. Un enfoque sin proxy puede generar mejoras en la eficiencia.
Aplicaciones de gRPC de alto rendimiento
En algunos casos de uso, cada milisegundo de latencia de solicitud y respuesta es importante. En ese caso, tal vez encuentres una latencia reducida cuando uses una aplicación de gRPC sin proxy, en lugar de pasar cada solicitud a través de un proxy de sidecar del lado del cliente y, posiblemente, un proxy de sidecar del lado del servidor.
Malla de servicios para entornos en los que no puedes implementar proxies de sidecar
En algunos entornos, es posible que no puedas ejecutar un proxy de sidecar como proceso adicional junto con el cliente o la aplicación de servidor. O es posible que no puedas configurar la pila de redes de una máquina para la intercepción y el redireccionamiento de solicitudes, por ejemplo, mediante iptables.
En este caso, puedes usar
Cloud Service Mesh con aplicaciones de gRPC sin proxy para introducir servicios
de malla de tus aplicaciones de gRPC.
Malla de servicios heterogénea
Debido a que las aplicaciones de gRPC sin proxy y Envoy se comunican con la malla de servicios de Cloud, la malla de servicios puede incluir ambos modelos de implementación. La inclusión de ambos modelos te permite satisfacer las necesidades particulares operativas, de rendimiento y de características de diferentes aplicaciones y equipos de desarrollo.
Migra desde una malla de servicios con proxies a una sin proxies
Si ya tienes una aplicación de gRPC con un proxy de sidecar configurado por la malla de servicios de Cloud, puedes pasar a una aplicación de gRPC sin proxy.
Cuando se implementa un cliente de gRPC con un proxy de sidecar, usa DNS para resolver el nombre de host al que se conecta. El proxy de sidecar intercepta el tráfico para proporcionar las capacidades de la malla de servicios.
Puedes definir si un cliente de gRPC usa la ruta sin proxy o la ruta del archivo adicional para comunicarse con un servidor gRPC si modificas el esquema de resolución de nombres que usa. Los clientes sin proxy usan el esquema de resolución de nombres de xds, mientras que los proxies de sidecar usan el esquema de resolución de nombres de dns. Algunos clientes de gRPC incluso pueden usar la ruta sin proxy cuando se comunican con un servidor de gRPC, pero usan la ruta del proxy de sidecar cuando se comunican con otro servidor de gRPC. Esto te permite migrar de forma gradual a una implementación sin proxy.
Para migrar de una malla de servicios con proxies a una sin proxies, crea un servicio de Cloud Service Mesh nuevo que tu cliente de gRPC sin proxy use. Puedes usar las mismas APIs para configurar Cloud Service Mesh versiones nuevas.
Arquitectura y recursos
El modelo de datos de configuración para servicios de gRPC sin proxy extiende el Modelo de configuración de Cloud Service Mesh, con algunas incorporaciones 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 RPC. Por ejemplo, los redireccionamientos HTTP que usan gRPC no son compatibles. Para ayudarte a comprender el modelo de configuración en esta guía, recomendarte que te familiarices con Cloud Service Mesh conceptos y la configuración.
En el siguiente diagrama, se muestran los recursos que debes configurar para las aplicaciones de gRPC sin proxy.
Verificaciones de estado
Una verificación de estado de gRPC puede comprobar el estado de un servicio de gRPC que se ejecuta en una instancia de máquina virtual (VM) de backend o en un grupo de extremos de red (NEG).
Si una verificación de estado de gRPC no se puede usar porque el servidor de gRPC no implementar el protocolo de verificación de estado de gRPC usa una verificación de estado de TCP. No uses una verificación de estado HTTP, HTTPS o HTTP/2.
Si deseas obtener más información, consulta Verificación de estado de gRPC y Marca adicional para verificaciones de estado de gRPC.
Servicio de backend
El servicio de backend define la manera en que un cliente de gRPC se comunica con un servidor de gRPC.
Cuando crees un servicio de backend para gRPC, configura el campo de protocolo en GRPC.
Las aplicaciones de gRPC también pueden acceder a un servicio de backend configurado con el protocolo de
GRPCa través de un proxy de sidecar. En ese caso, el cliente de gRPC no debe usar el esquema de resolución de nombres dexds.En todas las implementaciones de Cloud Service Mesh, el esquema de balanceo de cargas del servicio de backend debe ser
INTERNAL_SELF_MANAGED.
Backends
Los backends alojan tus instancias de servidor de gRPC. Puedes usar grupos de instancias administrados o no administrados en Compute Engine y NEG zonales en Google Kubernetes Engine como backends para alojar las instancias del servidor de gRPC.
¿Qué sigue?
- Para obtener información sobre las API de enrutamiento de servicio y cómo funcionan, consulta la descripción general.
- Si quieres prepararte para configurar Cloud Service Mesh con aplicaciones de gRPC sin proxy, consulta Prepárate para la configuración con Envoy y las cargas de trabajo sin proxy.
- Para obtener información sobre las limitaciones que se aplican a las implementaciones de gRPC sin proxy, consulta Límites y limitaciones con gRPC sin proxy.