Información general sobre las APIs de enrutamiento de servicios de Cloud Service Mesh

Nota: Esta guía solo admite Cloud Service Mesh con APIs de Google Cloud y no admite APIs de Istio. Para obtener más información, consulta la descripción general de Cloud Service Mesh.

Este documento está dirigido a administradores de mallas o plataformas y desarrolladores de servicios que tengan un nivel de familiarización intermedio o avanzado con Cloud Service Mesh y los conceptos de malla de servicios, y que estén implementando Cloud Service Mesh en Compute Engine con instancias de VM. Este documento se aplica a las implementaciones que usan clientes de Envoy y gRPC. Para obtener más información sobre los conceptos de Cloud Service Mesh, consulta la información general.

Cloud Service Mesh ofrece funciones de redes de servicios a tus aplicaciones, como gestión avanzada del tráfico, observabilidad y seguridad. Sin embargo, configurar y operar una malla de servicios es una tarea compleja para los administradores de mallas y los desarrolladores de servicios.

En este documento se describen las APIs de enrutamiento de servicios para configurar Cloud Service Mesh. Estas APIs se han diseñado para simplificar y mejorar tu experiencia general de configuración de la malla.

El modelo de enrutamiento de servicios usa recursos de API llamados Mesh, Gateway y Route. Estos recursos proporcionan una experiencia de configuración relevante en función del contexto cuando defines tu plano de control de redes de servicios.

En este documento se presenta el siguiente modelo de API de enrutamiento de servicios y recursos.

• Meshrecurso
  • Configuración de la gestión y la seguridad del tráfico de servicio a servicio (este-oeste) para proxies sidecar de Envoy y clientes de gRPC sin proxy.

• Gatewayrecurso

  • Gestión del tráfico y configuración de seguridad de los proxies de Envoy que actúan como pasarelas de entrada, lo que permite que los clientes externos se conecten a la malla de servicios (norte-sur).

• Recursos Route con los siguientes tipos:

  • HTTPRoute
  • GRPCRoute
  • TCPRoute
  • TLSRoute

La consola Google Cloud no ofrece asistencia para las APIs de enrutamiento de servicios. Debes implementar estos recursos de API mediante la CLI de Google Cloud o las APIs REST.

Casos prácticos y ventajas

Las APIs de enrutamiento de servicios te permiten configurar Cloud Service Mesh para implementaciones de gRPC sin proxy y de proxy de Envoy. El modelo de API de enrutamiento de servicios ofrece varias ventajas clave.

En el siguiente diagrama, dos servicios de la malla de servicios están conectados por un recurso Mesh. Los dos recursos HTTPRoute configuran el enrutamiento. El administrador de la malla o de la plataforma gestiona el recurso Mesh, y los dos propietarios del servicio crean la configuración de enrutamiento de sus servicios.

Tráfico de servicio a servicio este-oeste en una malla de servicios (haz clic en la imagen para ampliarla)

El diseño de APIs orientado a roles permite una separación clara de las responsabilidades

Las APIs de enrutamiento de servicios te permiten separar las responsabilidades de configuración de la malla en función de los roles de la organización:

• Los administradores de la malla pueden definir la malla lógica, así como la infraestructura de la puerta de enlace de entrada.
• Los propietarios de servicios (desarrolladores de aplicaciones) pueden definir de forma independiente los patrones de acceso de sus servicios. También pueden definir y aplicar políticas de gestión del tráfico a sus servicios.

En el siguiente diagrama, Cloud Load Balancing y un recurso Gateway proporcionan una puerta de enlace de entrada para el tráfico que entra en la malla desde un cliente que no está en la malla. El administrador de la malla configura y gestiona el recurso Gateway, mientras que los propietarios de los servicios configuran y gestionan sus propios servicios y el enrutamiento del tráfico.

Tráfico norte-sur en la malla a través de una puerta de enlace (haz clic en la imagen para ampliarla)

Fiabilidad mejorada con el modelo de autoservicio

Las APIs de enrutamiento de servicios usan recursos por protocolo y por ruta que pueden configurar y poseer propietarios de servicios independientes. Este enfoque tiene varias ventajas.

• Los propietarios de los servicios tienen autonomía para configurar las políticas y la gestión del tráfico de los servicios que poseen.
• Actualizar un recurso Route no afecta a otros recursos Route de la malla. El proceso de actualización es más fiable porque los propietarios de los servicios gestionan configuraciones pequeñas.
• El propietario del servicio responsable del servicio o nombre de host de destino es el propietario de cada recurso Route.
• Los propietarios de los servicios no tienen que depender de los administradores de la malla para actualizar el enrutamiento.

Habilitar una malla de servicios que abarque varios proyectos en entornos de VPC compartida

El modelo de API de enrutamiento de servicios permite a los propietarios de servicios participar en una infraestructura de malla compartida mediante una VPC compartida y otros medios de conectividad, al tiempo que mantienen el control independiente de sus servicios. Por ejemplo, los propietarios de servicios pueden definir los recursos Route en sus propios proyectos. Los administradores de la plataforma pueden definir una Mesh en un proyecto host administrado de forma centralizada y, a continuación, conceder permisos de gestión de identidades y accesos a los propietarios de los servicios para que vinculen sus recursos Route a una Mesh o a una Gateway compartidas. En el siguiente diagrama se muestra un ejemplo con VPC compartida.

Referencia entre proyectos con VPC compartida (haz clic en la imagen para ampliarla)

Las APIs de enrutamiento de servicios también te permiten conectar clientes de la malla de servicios a diferentes redes mediante el emparejamiento entre redes de VPC.

Dirigir el tráfico en función del indicador de nombre de servidor

El recurso TLSRoute te permite enrutar el tráfico cifrado con TLS en función de la indicación de nombre de servidor (SNI) en el handshake TLS. Puede configurar el tráfico TLS para que se dirija a los servicios de backend adecuados configurando la coincidencia de SNI en el recurso TLSRoute. En estas implementaciones, los proxies solo enrutan el tráfico y la sesión TLS se termina en la instancia backend de destino.

El recurso TLSRoute solo se admite con proxies de Envoy que se hayan implementado como proxies sidecar o como gateways.

TLSRoute recurso adjunto a un recurso Mesh

La implementación que se muestra en el siguiente diagrama dirige el tráfico de la malla de servicios en el que la extensión SNI tiene el valor service1 al servicio backend service1. Además, cualquier tráfico de malla de servicios en el que la extensión SNI tenga el valor service2 se enruta al servicio backend service2. El valor de la extensión SNI y el nombre del servicio de backend son independientes entre sí.

Recurso TLSRoute y recurso Mesh (haz clic en la imagen para ampliarla)

TLSRoute recurso adjunto a un recurso Gateway

En la implementación que se muestra en el siguiente diagrama, se dirige el tráfico entrante al recurso Gateway, donde la extensión SNI tiene el valor serviceA, al servicio de backend serviceA. Además, cualquier tráfico entrante a Gateway en el que la extensión SNI tenga el valor serviceB se dirige al servicio backend serviceB. El valor de la extensión SNI y el nombre del servicio de backend son independientes entre sí. El valor de la extensión SNI y el encabezado de las solicitudes HTTP también son independientes.

El recurso Gateway no finaliza la conexión TLS en el proxy Envoy de Gateway. En su lugar, la conexión TLS se termina en el servicio backend correspondiente. El Gateway no puede inspeccionar ninguna información cifrada en la capa TLS, salvo el ClientHello, que contiene una extensión SNI de texto sin formato. Gateway realiza la transferencia directa de TLS en este modo. Ten en cuenta que no se admite el cifrado ClientHello.

Recurso TLSRoute y recurso Gateway (haz clic en la imagen para ampliarla)

Compatibilidad con gRPC principal

Puedes configurar clientes gRPC sin proxy mediante atributos gRPC principales, como la coincidencia por método.

División del tráfico TCP

Puedes implementar la división del tráfico basada en el peso para el tráfico TCP en varios servicios de backend. Puedes configurar patrones como los lanzamientos Canary (azul-verde) cuando actualices tu servicio. La división del tráfico también te permite migrar el tráfico de forma controlada sin tiempo de inactividad.

Intercepción de tráfico

Cuando usas los recursos Mesh y Gateway de la API de enrutamiento de servicios, todo el tráfico se intercepta automáticamente. Para obtener más información, consulta Opciones para configurar máquinas virtuales de Compute Engine con despliegue automático de Envoy.

Arquitectura y recursos

En esta sección se describe el modelo de API de enrutamiento de servicios y sus recursos, y se explica cómo funcionan juntos los recursos de la API de enrutamiento de servicios.

Recurso Mesh

El recurso Mesh representa una instancia de una malla de servicios. Se usa para crear una malla de servicios lógica en tu proyecto. Cada recurso Mesh debe tener un nombre único en el proyecto. Una vez que se ha creado un recurso Mesh, no se puede modificar su nombre.

Recurso de API Meshcon Envoy Sidecar e implementaciones de gRPC sin proxy (haz clic para ampliar)

El recurso Mesh se hace referencia en el recurso Route para añadir rutas de servicios que forman parte de la malla.

El proxy Envoy y los clientes gRPC sin proxy reciben la configuración de Cloud Service Mesh uniéndose a la malla de servicios identificada por el nombre del recurso Mesh. El recurso Mesh admite las siguientes implementaciones del plano de datos:

• Envoy se ejecuta junto a la aplicación como proxies de sidecar
• Clientes gRPC sin proxy
• Combinación de clientes de gRPC sin proxy y sidecar de Envoy

Recurso Route

El recurso Route se usa para configurar el enrutamiento a los servicios. Hay cuatro tipos diferentes de recursos de la API Route. Definen el protocolo utilizado para enrutar el tráfico a un servicio backend.

• HTTPRoute
• GRPCRoute
• TCPRoute
• TLSRoute

La API no contiene una API Route verbatim. Los únicos recursos de API configurables son HTTPRoute, GRPCRoute, TCPRoute y TLSRoute.

El recurso Route hace referencia a uno o varios recursos Mesh y Gateway para añadir las rutas que forman parte de la configuración Mesh o Gateway correspondiente. Un recurso Route puede hacer referencia a recursos Gateway y Mesh.

El recurso Route también hace referencia a uno o varios recursos de servicio de backend. Los servicios se configuran mediante la API de servicio de backend. Crea un recurso de servicio de backend que apunte a uno o varios backends de MIG o NEG.

En el siguiente diagrama se muestran las relaciones entre los recursos Mesh, Gateway y Route, así como el recurso de servicio de backend y sus backends.

Recursos de la API Route (haga clic para ampliar)

Puedes definir otras funciones de gestión del tráfico, como el enrutamiento, las modificaciones de encabezados, los tiempos de espera y la división del tráfico basada en el peso, en los recursos Route. Por ejemplo, en el siguiente diagrama, un recurso HTTPRoute define una división del tráfico del 70 % y el 30 % entre dos servicios backend.

División del tráfico basada en el peso (haz clic en la imagen para ampliarla)

Para simplificar la administración de tu malla de servicios, puedes enumerar todos los Routerecursos adjuntos a un recurso Mesh o Gateway.

Recurso TLSRoute

Usa el recurso TLSRoute para enrutar el tráfico TLS a los servicios backend en función de los nombres de host SNI y del nombre de negociación de protocolo de capa de aplicación (ALPN). TLSRoute implica la transferencia directa de TLS, en la que el proxy de Envoy no finaliza el tráfico TLS.

El recurso TLSRoute hace referencia a uno o varios recursos Mesh y Gateway para añadir las rutas que forman parte de la configuración de malla o de puerta de enlace correspondiente.

El recurso TLSRoute también hace referencia a uno o varios recursos de servicio de backend. Los servicios se configuran mediante el recurso de la API de servicio de backend.

Recurso Gateway

El recurso Gateway se usa para representar proxies de Envoy que actúan como pasarelas de entrada, lo que permite que los clientes externos se conecten a la malla de servicios (tráfico de norte a sur). Este recurso tiene puertos de escucha junto con un parámetro scope. El proxy de Envoy que actúa como pasarela de entrada se vincula a los puertos especificados y a 0.0.0.0, que representa todas las direcciones IP de la máquina virtual local. En el siguiente diagrama se muestran los proxies de Envoy desplegados como un servicio de entrada y configurados por el recurso Gateway. En este ejemplo concreto, los proxies de Envoy están configurados para escuchar en el puerto 80 las conexiones entrantes de los clientes.

El recurso de API Gateway solo admite el plano de datos del proxy Envoy. No admite gRPC sin proxy. gRPCRoutes se admiten en el recurso Gateway, pero el tráfico de gRPC se enruta mediante el proxy Envoy, que actúa como proxy intermedio.

Ingreso de malla de servicios a través de un recurso Gateway (haz clic en la imagen para ampliarla)

Recurso Gateway (haz clic en la imagen para ampliarla)

¿Qué son un Gateway ámbito y una configuración Gateway combinada?

Una instancia de recurso Gateway representa los puertos y la configuración específicos del tráfico recibido en esos puertos. El recurso de la API Gateway tiene un parámetro, scope, que se usa para agrupar y combinar lógicamente la configuración de dos o más recursos Gateway.

Por ejemplo, si quieres que los proxies Gateway escuchen en los puertos 80 y 443 para recibir tráfico HTTP y HTTPS, respectivamente, crea dos recursos Gateway. Configura un recurso Gateway con el puerto 80 para el tráfico HTTP y otro con el puerto 443 para el tráfico HTTPS. Asigna el mismo valor al campo scope de cada uno. Cloud Service Mesh combina dinámicamente las configuraciones individuales de todas las pasarelas que tienen el mismo ámbito. En el plano de datos, los proxies de Envoy que se ejecutan en el modo de puerta de enlace de entrada también deben presentar el mismo parámetro de ámbito a Cloud Service Mesh para recibir la configuración Gateway. Ten en cuenta que especificas el ámbito al crear el recurso Gateway y que especificas el mismo ámbito que el parámetro de bootstrap para los proxies.

Comportamiento de combinación de recursos de Gateway (haz clic para ampliar)

A continuación, se indican los aspectos clave que debes tener en cuenta sobre el recurso Gateway:

• El parámetro de ámbito Gateway es obligatorio. Especifique el ámbito en el recurso Gateway y en la configuración de arranque de los proxies de Envoy, aunque solo haya un Gateway.
• Crear un recurso Gateway no implica desplegar un servicio con un proxy de Envoy. La implementación del proxy Envoy es un paso independiente.
• El recurso Gateway tiene un type que representa el tipo de implementación de entrada. Este campo está reservado para uso futuro. El único valor admitido actualmente es OPEN_MESH, que es el valor predeterminado y no se puede modificar.

Despliegues de malla con protocolos y planos de datos mixtos

Puedes tener una implementación de plano de datos mixta, con el proxy Envoy y gRPC sin proxy en la misma malla. Cuando crees este tipo de implementaciones, ten en cuenta lo siguiente.

• Las implementaciones de sidecar de Envoy admiten todas las rutas (HTTPRoute, GRPCRoute, TCPRoute y TLSRoute).
• Las implementaciones de gRPC sin proxy solo admiten GRPCRoute.
• GRPCRoute se limita a las funciones compatibles solo con las implementaciones de gRPC sin proxy.

Topologías admitidas en entornos de VPC compartida con varios proyectos

Cloud Service Mesh permite añadir recursos Route definidos en otros proyectos a un recurso Mesh o Gateway definido en un proyecto de administración centralizado. Los propietarios de servicios autorizados pueden añadir directamente sus configuraciones de enrutamiento de servicios a Mesh o Gateway.

Referencias entre proyectos de recursos Mesh y Route (haz clic en la imagen para ampliarla)

En un caso habitual entre proyectos, se elige un proyecto (proyecto host o proyecto de administración controlado de forma centralizada) como proyecto de administración de la malla en el que se crea un recurso Mesh. El propietario del proyecto de administración de la malla autoriza a los recursos Route de otros proyectos para que hagan referencia al recurso Mesh, lo que permite que la configuración de enrutamiento de otros proyectos forme parte de la malla. Un plano de datos de malla, ya sea Envoy o gRPC, solicita la configuración del proyecto de administración y recibe una unión de todas las rutas asociadas al Mesh. En el caso de los Gateway, las rutas también se combinan en todos los Gateways que usan el mismo ámbito.

El proyecto de administración Mesh puede ser cualquier proyecto que elijas, y la configuración funciona siempre que los proyectos subyacentes tengan conectividad de red de VPC, ya sea a través de una VPC compartida o del emparejamiento entre redes de VPC.

Permisos y roles de gestión de identidades y accesos

A continuación, se indican los permisos de IAM necesarios para obtener, crear, actualizar, eliminar, enumerar y usar de forma segura los recursos Mesh y Route.

• Los administradores de Mesh deben tener permisos de networkservices.mesh.*.
• Los administradores de la pasarela deben tener permisos de networkservices.gateways.*.
• Los propietarios de servicios deben tener permisos networkservices.grpcRoutes.*, networkservices.httpRoutes.* o networkservices.tcpRoutes.*.

Los administradores de Mesh deben conceder el permiso networkservices.mesh.use a los propietarios de servicios para que puedan adjuntar sus recursos Route al recurso Mesh. El mismo modelo se aplica a los recursos de Gateway.

Para ver todos los permisos de gestión de identidades y accesos de los recursos de Mesh, ve a la página de referencia de permisos de gestión de identidades y accesos y busca meshes.

No se necesitan roles predefinidos adicionales. El rol predefinido Administrador de red de Compute (roles/compute.networkAdmin) tiene permisos de networkservices.* de forma predeterminada. Es posible que tengas que añadir los permisos descritos anteriormente a tus roles personalizados.

Consideraciones y limitaciones

• La consola de Google Cloud no admite las APIs de enrutamiento de servicios.
• Usa la versión 3 de la API xDS o una posterior.
  • Versión mínima de Envoy 1.20.0 (ya que las APIs de enrutamiento de servicios solo se admiten en la versión 3 de xDS)
  • Versión mínima del generador de bootstrap de gRPC v0.14.0
• El recurso TLSRoute solo se admite con proxies de Envoy que se hayan implementado como proxies o gateways sidecar.
• Solo se admiten las VMs de Compute Engine con despliegue automático de Envoy y los pods de GKE con inserción automática de Envoy. No puedes usar el despliegue manual con las APIs de enrutamiento de servicios.
• Las APIs de enrutamiento de servicios no son retrocompatibles con las APIs anteriores.
• Cuando se adjunta un recurso TCPRoute a un recurso Mesh, el puerto que se usa para asociar el tráfico TCP no se puede usar para servir nada más que el tráfico descrito por este TCPRoute.
  • Por ejemplo, tus implementaciones pueden incluir un recurso TCPRoute que coincida con el puerto "8000" y un recurso HttpRoute. Si ambos están asociados al mismo recurso Mesh, el tráfico enrutado por el recurso HTTPRoute no puede usar el puerto 8000, aunque las direcciones IP subyacentes sean diferentes. Esta limitación procede de la implementación del proxy de Envoy, que asigna prioridad a la ruta que coincide con el puerto en primer lugar.
• El recurso Gateway no aprovisiona un balanceador de carga gestionado ni crea dinámicamente un servicio Envoy.
• Los Envoys implementados automáticamente que actúan como pasarelas de entrada no deben tener el argumento serving_ports en la marca --service-proxy.
• Envoy desplegado automáticamente no admite que se proporcione un número de proyecto diferente al de la VM.

Siguientes pasos

• Para obtener información sobre cómo enumerar los recursos de ruta asociados a un recurso Mesh o Gateway, consulta Enumerar recursos de Route.
• Para obtener información sobre las APIs de enrutamiento de servicios, consulta la documentación de las APIs de servicios de red.