Descripción general de las APIs de enrutamiento de servicios de Cloud Service Mesh
Este documento está dirigido a los administradores de plataformas o mallas y a los desarrolladores de servicios que tengan un nivel intermedio o avanzado de conocimiento de Cloud Service Mesh y de conceptos de la malla de servicios, y que implementen 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 descripción general.
Cloud Service Mesh proporciona funciones de redes de servicios a tus aplicaciones, incluida la administración avanzada del tráfico, la observabilidad y la seguridad. Sin embargo, configurar y operar una malla de servicios es una tarea compleja para los administradores de malla y los desarrolladores de servicios.
En este documento, se describen las APIs de enrutamiento de servicios para configurar Cloud Service Mesh. Estas APIs están diseñadas para simplificar y mejorar tu experiencia general con la configuración de mallas.
El modelo de enrutamiento de servicios usa recursos de API llamados Mesh
, Gateway
y Route
.
Estos recursos proporcionan una experiencia de configuración más relevante para el contexto cuando defines tu plano de control de redes de servicio.
En este documento se presentan los siguientes recursos y el modelo de API de enrutamiento de servicios:
Mesh
resource- Administración de tráfico de servicio a servicio (de este a oeste) y configuración de seguridad para proxies de sidecar de Envoy y clientes de gRPC sin proxy.
-
- Administración del tráfico y configuración de seguridad para proxies de Envoy que actúan como puertas de enlace de entrada, lo que permite que los clientes externos se conecten a la malla de servicios (de norte a sur).
Recursos
Route
con los siguientes tipos:
La consola de Google Cloud no proporciona asistencia para las APIs de enrutamiento de servicios. Debes implementar estos recursos de API con Google Cloud CLI o las APIs de REST.
Casos de uso y beneficios
Las APIs de enrutamiento de servicios te permiten configurar la malla de servicios de Cloud para implementaciones de proxies de Envoy y de gRPC sin proxy. El modelo de API de enrutamiento de servicios habilita varios beneficios clave.
En el siguiente diagrama, un recurso Mesh
conecta dos servicios de la malla de servicios. Los dos recursos HTTPRoute
configuran el enrutamiento. El administrador de la malla o la plataforma administra el recurso Mesh
, y los dos propietarios de servicios crean la configuración de enrutamiento para sus servicios.
El diseño de una API orientada a los 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 según los roles de la organización:
- Los administradores de malla pueden definir la malla lógica y la infraestructura de la puerta de enlace de entrada.
- Los propietarios de los servicios (desarrolladores de aplicaciones) pueden definir patrones de acceso para sus servicios de manera independiente. También pueden definir y aplicar políticas de administración de tráfico para 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 ingresa a la malla desde un cliente que no está en la malla. El administrador de malla configura y administra el recurso Gateway
, mientras que los propietarios de servicios configuran y administran sus propios servicios y el enrutamiento de tráfico.
Confiabilidad mejorada con el modelo de servicio automático
Las APIs de enrutamiento de servicios usan recursos por protocolo y por ruta, que los propietarios de servicios independientes pueden configurar y poseer. Este enfoque tiene varias ventajas.
- Los propietarios del servicio tienen autonomía sobre cómo desean configurar las políticas y la administración del tráfico para sus servicios.
- La actualización de un recurso
Route
no afecta a otros recursosRoute
en la malla. El proceso de actualización es más confiable porque los propietarios del servicio administran configuraciones pequeñas. - El propietario del servicio que es responsable del nombre de host o el servicio de destino posee cada recurso
Route
. - Los propietarios de servicios no tienen que depender de los administradores de malla para actualizar el enrutamiento.
Habilita 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, a la vez que mantienen un control independiente sobre sus servicios. Por ejemplo, los propietarios de servicios pueden definir los recursos Route
en sus propios proyectos. Los administradores de la plataforma pueden definir un Mesh
en un proyecto host administrado de forma central y, luego, otorgar permisos de IAM a los propietarios de servicio para conectar sus recursos Route
a una Mesh
o Gateway
compartida. En el siguiente diagrama, se muestra un ejemplo con una VPC compartida.
Las APIs de enrutamiento de servicios también te permiten tener clientes de malla de servicios conectados a diferentes redes mediante el intercambio de tráfico entre redes de VPC.
Enrutamiento del tráfico según el indicador de nombre del servidor
El recurso TLSRoute
te permite enrutar el tráfico encriptado con TLS según la indicación del nombre del servidor (SNI) en el protocolo de enlace TLS. Puedes configurar el tráfico de TLS para que se enrute a los servicios de backend correspondientes si configuras la coincidencia de SNI en el recurso TLSRoute
. En estas implementaciones, los proxies solo enrutan el tráfico y la sesión de TLS se finaliza en la instancia de backend de destino.
El recurso TLSRoute
solo es compatible con los proxies de Envoy que se implementan como proxies de sidecar o puertas de enlace.
Recurso TLSRoute
conectado a un recurso Mesh
La implementación que se muestra en el siguiente diagrama enruta el tráfico de la malla de servicios en el que la extensión de SNI tenga el valor service1
al servicio de backend service1
. Además, el tráfico de la malla de servicios en el que la extensión de SNI tenga el valor service2
se enruta al servicio de backend service2
. El valor de la extensión de SNI y el nombre del servicio de backend son independientes entre sí.
Recurso TLSRoute
conectado a un recurso Gateway
La implementación que se muestra en el siguiente diagrama enruta cualquier tráfico entrante al recurso Gateway
en el que la extensión de SNI tenga 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 enruta al servicio de backend serviceB
. El valor de la extensión de SNI y el nombre del servicio de backend son independientes entre sí. El valor de la extensión de SNI y el encabezado en las solicitudes HTTP también son independientes.
El recurso Gateway
no finaliza la conexión TLS en el proxy Envoy de Gateway
. En cambio, la conexión TLS finaliza en el servicio de backend correspondiente. El Gateway
no puede inspeccionar información encriptada en la capa TLS, excepto ver ClientHello
, que contiene una extensión de SNI de texto sin formato. La Gateway
realiza la transferencia de TLS en este modo. Ten en cuenta que ClientHello
encriptado no es compatible.
Compatibilidad con gRPC principal
Puedes configurar clientes de gRPC sin proxy con atributos principales de gRPC, como la coincidencia por método.
División del tráfico para el tráfico de TCP
Puedes implementar la división del tráfico basada en el peso para el tráfico de TCP en varios servicios de backend. Puedes configurar patrones como lanzamientos de versión canary (azul-verde) cuando actualizas 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 del tráfico
Cuando usas los recursos Mesh
y Gateway
de la API de enrutamiento de servicio, todo el tráfico se intercepta de forma automática. Si deseas obtener más información, consulta Opciones para la configuración de VM de Compute Engine con implementación automática de Envoy.
Arquitectura y recursos
En esta sección, se describe el modelo de la API de enrutamiento de servicios y sus recursos, y te ayuda a comprender cómo funcionan los recursos de la API de enrutamiento de servicios en conjunto.
Mesh
recurso
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. Después de crear un recurso Mesh
, su nombre no se puede modificar.
Se hace referencia al recurso Mesh
en el recurso Route
a fin de agregar rutas para los servicios que forman parte de la malla.
Los clientes de proxies de Envoy y gRPC sin proxy reciben la configuración de la malla de servicios de Cloud mediante la unión de la malla de servicios identificada por el nombre del recurso Mesh
. El recurso Mesh
admite las siguientes implementaciones del plano de datos:
- Envoy que se ejecuta junto con la aplicación como proxies de sidecar
- Clientes gRPC sin proxy
- Combinación clientes de gRPC sin proxy y sidecar de Envoy
Route
recurso
El recurso Route
se usa para configurar el enrutamiento a los servicios. Existen cuatro tipos diferentes de recursos de API Route
. Definen el protocolo que se usa para enrutar el tráfico a un servicio de backend.
HTTPRoute
GRPCRoute
TCPRoute
TLSRoute
La API no contiene una API de Route
textual. Los únicos recursos de API que se pueden configurar son HTTPRoute
, GRPCRoute
, TCPRoute
y TLSRoute
.
El recurso Route
hace referencia a uno o más recursos Mesh
y Gateway
para agregar 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 más recursos de servicio de backend. Los servicios se configuran mediante la API del servicio de backend. Solo debes crear un recurso de servicio de backend que apunte a uno o más backends de MIG o NEG.
En el siguiente diagrama, se muestran las relaciones entre los recursos Mesh
, Gateway
y Route
, y el recurso del servicio de backend y sus backends.
Puedes definir otras capacidades de administración de tráfico en los recursos Route
, como el enrutamiento, las modificaciones de encabezado, los tiempos de espera y la división de tráfico basada en el peso.
Por ejemplo, en el siguiente diagrama, un recurso HTTPRoute
define una división de tráfico del 70% / 30% entre dos servicios de backend.
Para simplificar la administración de tu malla de servicios, puedes enumerar todos los recursos Route
adjuntos a un recurso Mesh
o Gateway
.
TLSRoute
recurso
Usa el recurso TLSRoute
para enrutar el tráfico TLS a los servicios de backend según los nombres de host de SNI y el nombre de la negociación del protocolo de capa de aplicación (ALPN). La configuración de TLSRoute
implica la transferencia de TLS, en la que el proxy de Envoy no finaliza el tráfico de TLS.
El recurso TLSRoute
hace referencia a uno o más recursos Mesh
y Gateway
para agregar las rutas que forman parte de la configuración de la malla o puerta de enlace correspondiente.
El recurso TLSRoute
también hace referencia a uno o más recursos de servicio de backend.
Los servicios se configuran mediante el recurso de la API del servicio de backend.
Gateway
recurso
El recurso Gateway
se usa para representar proxies de Envoy que actúan como puertas de enlace 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 una puerta de enlace de entrada se vincula a los puertos especificados y a 0.0.0.0
, que representa todas las direcciones IP en la VM local. En el siguiente diagrama, se muestran los proxies de Envoy implementados como un servicio de entrada y configurados por el recurso Gateway
. En este ejemplo en particular, los proxies de Envoy están configurados para detectar las conexiones entrantes de los clientes en el puerto 80.
El recurso de la API Gateway
solo es compatible con el plano de datos del proxy de Envoy. No admite gRPC sin proxy. gRPCRoutes
son compatibles con el recurso Gateway
, pero el proxy de Envoy enruta el tráfico de gRPC y actúa como un proxy intermedio.
¿Qué son los alcances de Gateway
y las configuraciones de Gateway
combinadas?
Una instancia de recurso Gateway
representa los puertos y la configuración específica del tráfico recibido en esos puertos. El recurso de API Gateway
tiene un parámetro, scope
, que se usa para agrupar y combinar de forma lógica la configuración de dos o más recursos Gateway
.
Por ejemplo, si deseas 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 el otro con el puerto 443 para el tráfico HTTPS. Asigna el mismo valor al campo scope
de cada uno.
La malla de servicios de Cloud combina de forma dinámica las configuraciones individuales de todas las puertas de enlace que tienen el mismo alcance. En el lado del 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 alcance a Cloud Service Mesh para recibir la configuración de Gateway
. Ten en cuenta que especificas el alcance cuando creas el recurso Gateway
y especificas el mismo alcance que el parámetro de arranque para los proxies.
Las siguientes son consideraciones clave para el recurso Gateway
:
- El parámetro de alcance
Gateway
es obligatorio. Especifica el permiso en el recursoGateway
y en la configuración de arranque de los proxies de Envoy incluso cuando solo exista unGateway
. - La creación de un recurso
Gateway
no implementa un servicio con un proxy de Envoy. La implementación del proxy de Envoy es un paso independiente. - El recurso
Gateway
tiene untype
que representa el tipo de implementación de entrada. Este campo está reservado para uso futuro. El único valor admitido por el momento esOPEN_MESH
, que es el valor predeterminado y no se puede modificar.
Implementaciones de malla con protocolos combinados y planos de datos
Puedes tener una implementación de plano de datos combinada con el proxy de Envoy y gRPC sin proxy en la misma malla. Cuando crees esas implementaciones, ten en cuenta lo siguiente.
- Las implementaciones de sidecar de Envoy admiten todas las rutas (
HTTPRoute
,GRPCRoute
,TCPRoute
yTLSRoute
). - Las implementaciones de gRPC sin proxy solo son compatibles con
GRPCRoute
. GRPCRoute
se limita a las funciones que solo admiten implementaciones sin proxy de gRPC.
Topologías compatibles en entornos de VPC compartida de varios proyectos
Cloud Service Mesh admite la adición de recursos Route
que se definen en otros proyectos a un recurso de Mesh
o Gateway
definido en un proyecto de administración centralizado. Los propietarios de servicios autorizados pueden agregar directamente su configuración de enrutamiento de servicio a Mesh
o Gateway
.
En una situación típica de varios proyectos, eliges un proyecto (proyecto host o proyecto de administración controlado de forma central) como el proyecto de administración de malla en el que creas un recurso Mesh
. El propietario del proyecto de administración de malla autoriza a los recursos Route
de otros proyectos a hacer 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 de Envoy o gRPC, solicita la configuración del proyecto de administración y recibe una unión de todas las rutas conectadas a la Mesh
. En el caso de una Gateway
, las rutas también se combinan en todas las Gateways
que usan el mismo alcance.
El proyecto de administración de Mesh
puede ser cualquier proyecto que elijas, y la configuración funciona siempre y cuando los proyectos subyacentes tengan conectividad de red de VPC, ya sea a través de VPC compartida o intercambio de tráfico entre redes de VPC.
Permisos y roles de IAM
Los siguientes son los permisos de IAM que son necesarios para obtener, crear, actualizar, borrar, enumerar y usar de forma segura los recursos Mesh
y Route
.
- Los administradores de malla deben tener permisos de
networkservices.mesh.*
. - Los administradores de puertas de enlace deben tener permisos de
networkservices.gateways.*
. - Los propietarios de servicios deben tener los permisos de
networkservices.grpcRoutes.*
,networkservices.httpRoutes.*
onetworkservices.tcpRoutes.*
.
Los administradores de malla deben otorgar el permiso networkservices.mesh.use
a los propietarios de servicios para que estos puedan adjuntar sus recursos Route
al recurso Mesh
. El mismo modelo se aplica a los recursos Gateway
.
Para ver todos los permisos de IAM para los recursos Mesh
, ve a la página de referencia de permisos de IAM y busca meshes
.
No se requieren roles predefinidos adicionales. De forma predeterminada, el rol predefinido Administrador de red de Compute (roles/compute.networkAdmin
) tiene los permisos de networkservices.*
.
Es posible que debas agregar 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 de xDS o una versión posterior.
- La versión de Envoy debe ser 1.20.0 como mínimo (ya que las APIs de enrutamiento de servicios solo son compatibles con la versión 3 de xDS)
- La versión del generador de arranque de gRPC debe ser v0.14.0 como mínimo
- El recurso
TLSRoute
solo es compatible con los proxies de Envoy que se implementan como proxies de sidecar o puertas de enlace. - Solo se admiten las VM de Compute Engine con implementación automática de Envoy y los Pods de GKE con inserción automática de Envoy. No puedes usar la implementación manual con las APIs de enrutamiento de servicios.
- Las APIs de enrutamiento de servicios no son retrocompatibles con las APIs anteriores.
- Cuando se conecta un recurso
TCPRoute
a un recursoMesh
, el puerto que se usa para hacer coincidir el tráfico de TCP no puede usarse a fin de entregar nada, excepto el tráfico que se describe en estaTCPRoute
.- Por ejemplo, tus implementaciones pueden incluir un recurso
TCPRoute
que coincida con el puerto “8000” y un recurso HttpRoute. Cuando ambos están conectados al mismo recursoMesh
, el tráfico que enruta el recursoHTTPRoute
no puede usar el puerto 8000, incluso cuando las direcciones IP subyacentes son diferentes. Esta limitación proviene de la implementación del proxy de Envoy, que prioriza primero la ruta a la que coincide el puerto.
- Por ejemplo, tus implementaciones pueden incluir un recurso
- El recurso
Gateway
no aprovisiona un balanceador de cargas administrado y no crea un servicio de Envoy de forma dinámica. - Los Envoy que se implementan de forma automática y funcionan como puertas de enlace de entrada no deben tener el argumento
serving_ports
en la marca--service-proxy
. - El Envoy implementado de forma automática no admite la entrega de un número de proyecto diferente del proyecto de la VM.
¿Qué sigue?
- Para obtener información sobre cómo mostrar una lista de recursos de ruta asociados con un recurso
Mesh
oGateway
, consulta Cómo mostrar una lista de recursosRoute
. Esta función está en vista previa. - Para obtener información sobre las APIs de enrutamiento de servicios, lee la documentación de las APIs de servicios de red.