Descripción general de las APIs de enrutamiento de servicios de Traffic Director

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 Traffic Director y de conceptos de la malla de servicios. Este documento se aplica a las implementaciones en las que se usan clientes de Envoy y gRPC. Para obtener más información sobre los conceptos de Traffic Director, consulta la descripción general y la descripción general de los servicios de gRPC sin proxy.

Traffic Director 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 Traffic Director. Estas APIs están diseñadas para simplificar y mejorar la experiencia general de la configuración de malla.

Este modelo de API reemplaza los recursos anteriores de la regla de reenvío, el proxy de destino y el mapa de URL por recursos de la API llamados Mesh, Gateway y Route. Estos recursos proporcionan una experiencia de configuración más relevante para el contexto cuando defines el plano de control de las redes de servicios.

En este documento se presentan los siguientes recursos y el modelo de API de enrutamiento de servicios:

  • Mesh
    • 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.
    • Identifica la malla de servicios y representa el componente responsable de interceptar y enrutar el tráfico, y de aplicar políticas. Además, identifica el puerto de intercepción de tráfico.
  • Gateway
    • 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).
    • Identifica los proxies del medio y representa el componente que escucha en una lista de pares de dirección IP:puerto, enruta el tráfico y aplica políticas.
  • Route
    • Identifica los nombres de host y los puertos que los clientes usan para enrutar el tráfico a los servicios de backend y contiene información compleja de enrutamiento de tráfico. Existen varios tipos diferentes de recursos Route.
    • HTTPRoute
    • GRPCRoute
    • TCPRoute
    • TLSRoute

La consola de Google Cloud no proporciona asistencia para las APIs de enrutamiento de servicio. Debes implementar estos recursos de API con Google Cloud CLI o las APIs de REST. Además, no existe una ruta de migración automatizada desde las APIs más antiguas hasta las APIs de enrutamiento de servicios. Para reemplazar una implementación existente, debes crear una implementación nueva de Traffic Director con las APIs de enrutamiento de servicios y, luego, cerrar la implementación anterior.

Casos de uso y beneficios

Las APIs de enrutamiento de servicios te permiten configurar Traffic Director para implementaciones de proxy 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 de la plataforma administra el recurso Mesh, y los dos propietarios del servicio crean la configuración de enrutamiento para sus servicios.

Tráfico de servicio a servicio de este a oeste en una malla de servicios
Tráfico de servicio a servicio de oeste a servicio en una malla de servicios (haz clic para ampliar)

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 las funciones organizativas:

  • 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.

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

Confiabilidad mejorada con el modelo de servicio automático

En la API anterior de Traffic Director, el mapa de URL define el enrutamiento para la comunicación de servicio a servicio en la malla, así como el tráfico externo que ingresa a la malla a través de un balanceador de cargas administrado. Varios equipos pueden editar un solo recurso de mapa de URL, lo que presenta posibles problemas de confiabilidad y complica el proceso de delegación de la configuración por servicio a los propietarios del servicio.

Las APIs de enrutamiento de servicio presentan recursos por protocolo y por ruta que los propietarios del servicio independientes pueden configurar y poseer. Este enfoque tiene varias ventajas.

  • Los propietarios del servicio ahora 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 recursos Route en la malla. El proceso de actualización también es menos propenso a errores porque los propietarios del servicio administran configuraciones mucho más pequeñas.
  • El propietario del servicio que es responsable del nombre de host o el servicio de destino posee cada recurso Route.
  • Los propietarios del servicio no tienen que depender de los administradores de malla para actualizar el enrutamiento mediante el recurso de mapa de URL centralizado.

Configura solo lo que es relevante

Las APIs de enrutamiento del servicio reemplazan las reglas de reenvío, los proxies de destino y los mapas de URL. Ya no necesitas asignar direcciones IP virtuales desde tu red de nube privada virtual (VPC) para la comunicación de servicio a servicio con proxies de sidecar y gRPC sin proxy.

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 del servicio participar en una infraestructura de malla compartida mediante la 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.

Referencia entre proyectos con VPC compartida
Referencia entre proyectos con VPC compartida (haz clic para ampliar)

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 y recurso Mesh
El recurso TLSRoute y el recurso Mesh (haz clic para ampliar)

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.

Recurso TLSRoute y recurso Gateway
El recurso TLSRoute y el recurso Gateway (haz clic para ampliar)

Compatibilidad integrada con gRPC

Puedes configurar clientes de gRPC sin proxy con atributos de gRPC integrados, como la coincidencia por método, en lugar de traducir a rutas de acceso equivalentes y con el uso de comparadores de rutas de acceso.

División del tráfico para el tráfico de TCP

Ahora 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 servicios, 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. Además, te ayuda a comprender cómo funcionan en conjunto los recursos de la API de enrutamiento de servicios.

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.

Recurso de API de malla con implementaciones de gRPC sin proxy y sidecar de Envoy
Mesh Recurso de API con implementaciones de gRPC sin proxy y sidecar de Envoy (haz clic para ampliar)

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 Traffic Director mediante la unión de la malla de servicios identificada por el nombre del recurso Mesh. El nombre de Mesh, como parámetro de arranque, es compatible con la implementación automatizada de Envoy en Compute Engine y el inyector automático de Envoy en GKE.

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.

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 con el flujo de configuración existente. Las APIs de enrutamiento de servicios no cambian la forma en que se definen los servicios de backend y las verificaciones de estado en la configuración de Traffic Director. Para hacerlo, debes crear un recurso de servicio de backend que apunte a uno o más backends MIG o NEG.

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

Recursos de API Route
Recursos de API Route (haz clic para ampliar)

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.

División de tráfico basada en el peso
División del tráfico basada en el peso (haz clic para ampliar)

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 con el flujo de configuración y las API existentes.

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.

Entrada de la malla de servicios a través de un recurso Gateway.
Entrada de la malla de servicios a través de un recurso Gateway (haz clic para ampliar)
Recurso de puerta de enlace
Recurso Gateway (haz clic para ampliar)

¿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. Traffic Director 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 Traffic Director 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.

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

Las siguientes son consideraciones clave para el recurso Gateway:

  • El parámetro de alcance Gateway es obligatorio. Especifica el permiso en el recurso Gateway y en la configuración de arranque de los proxies de Envoy incluso cuando solo exista un Gateway.
  • 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 un type que representa el tipo de implementación de entrada. Este campo está reservado para uso futuro. El único valor admitido por el momento es OPEN_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 y TLSRoute).
  • 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

Traffic Director admite la adición de 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 agregar directamente su configuración de enrutamiento de servicio a Mesh o Gateway.

Referencia entre proyectos entre los recursos de malla y de ruta
Referencia entre proyectos entre Mesh y Route (haz clic para agrandar)

En una situación típica entre proyectos, debes elegir un proyecto (proyecto host o proyecto de administración controlado de forma central) como el proyecto de administración de la malla en el que creas un recurso Mesh. El propietario del proyecto de administración de la 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 en malla, ya sea Envoy o gRPC, solicita la configuración del proyecto de administración y recibe una unión de todas las rutas conectadas al 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 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 la VPC compartida o el 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 los permisos de networkservices.gateways.*.
  • Los propietarios de servicios deben tener los permisos de networkservices.grpcRoutes.*, networkservices.httpRoutes.* o networkservices.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 Compute Network Admin (roles/compute.networkAdmin) tiene los permisos de networkservices.*. Es posible que debas agregar los permisos descritos anteriormente a tus roles personalizados.

Comparación entre el enrutamiento del servicio y los modelos de API anteriores

En esta sección, se realiza una comparación tema por tema entre los modelos de API de Traffic Director más antiguos y de enrutamiento de servicios.

APIs más antiguas APIs de enrutamiento de servicios
Recursos de la API Regla de reenvío, proxy de destino, mapa de URL y servicio de backend. Servicio de backend, puerta de enlace, malla y ruta.
Direcciones IP y números de puerto de servicios Debes aprovisionar direcciones IP y números de puerto para tus servicios y configurar reglas de reenvío, que deben coincidir con los pares IP:Puerto para todos los casos de uso.

Debes asignar las direcciones IP de forma manual a los nombres de host o debes usar la dirección IP genérica 0.0.0.0.		 No necesitas configurar direcciones IP para casos de uso de Mesh o Gateway. Gateway requiere configurar los números de puerto.
Alcance de la malla de servicios Traffic Director programa todos los proxies adjuntos a la red de VPC, por lo que el alcance de la malla es la red de VPC. Traffic Director no programa proxies basados en la red de VPC.

Para la comunicación de servicio a servicio de este a oeste, los clientes de gRPC sin proxy y Envoy usan el nombre del recurso Mesh.

En los casos de uso de puertas de enlace de entrada de norte a sur, el parámetro scope en la API Gateway permite que se agrupen varios Gateways. con la configuración combinada.
Referencia entre proyectos en entornos de VPC compartida No se admite la referencia entre proyectos. Todos los recursos de la API deben configurarse en el mismo proyecto. Es posible crear recursos Mesh o Gateway en un proyecto administrado de forma central (proyecto host), y los propietarios del servicio pueden crear los recursos Route en proyectos de servicio en el entorno de VPC compartida. Los recursos Route pueden hacer referencia a Mesh o Gateway ubicadas en otros proyectos.
Puerto de intercepción Se debe especificar el parámetro de arranque TRAFFICDIRECTOR_INTERCEPTION_PORT en cada Envoy que se conecta a Traffic Director.

Con la implementación automática de Envoy en la API de Compute Engine y con la inserción automática de sidecar en GKE, este valor se establece de forma predeterminada en 15001.		 El puerto de intercepción se configura en el recurso Mesh y se aplica de forma automática a todos los Envoy que soliciten la configuración para esa Mesh.

El valor continúa siendo 15001 de forma predeterminada si no se especifica.

Inicia los clientes de Envoy y gRPC en Compute Engine y GKE

APIs más antiguas APIs de enrutamiento de servicios
Usa la implementación automática de Envoy en Compute Engine Cuando creas la plantilla de VM, especificas un parámetro de línea de comandos, --service-proxy=enabled, que inicia de forma dinámica el proxy de Envoy con los atributos requeridos. Cuando creas la plantilla de VM, especificas parámetros adicionales. Por ejemplo, --service-proxy=enabled, mesh=[MESH_NAME] (para mallas) o --service-proxy=enabled, scope=[SCOPE_NAME] (para puertas de enlace). Otros atributos obligatorios se inician de forma dinámica. En el caso de los Envoys que funciona como puerta de enlace, asegúrate de que serving_ports no se especifique en el argumento de línea de comandos --service-proxy. 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.
Usa la inserción automática de sidecar en GKE Especifica los atributos de arranque necesarios en el configMap del inyector de sidecar. El mismo flujo de trabajo con los atributos nuevos especificados en el configMap.
Usa la inserción manual de sidecar en GKE Como se explica aquí, el pod de la aplicación debe tener un contenedor de sidecar de Envoy iniciado con los atributos necesarios. El mismo flujo de trabajo con los atributos nuevos.
Usa Compute Engine o GKE para implementar clientes de gRPC La aplicación cliente debe iniciarse con los atributos requeridos. El mismo flujo de trabajo con los atributos nuevos.

Configura los casos de uso de seguridad de la puerta de enlace y de la malla

APIs más antiguas APIs de enrutamiento de servicios
mTLS de servicio a servicio en GKE Sigue las instrucciones que aparecen aquí para las implementaciones basadas en sidecar de Envoy.

Sigue las instrucciones que aparecen aquí para las implementaciones sin proxy basadas en gRPC.		 Se aplican las mismas instrucciones.

La política de TLS del servidor y la política de TLS del cliente deben aplicarse a los recursos de la política de extremo y el servicio de backend, respectivamente. Debido a que ambas APIs son independientes de las APIs de enrutamiento de servicio, el flujo de configuración sigue siendo el mismo que antes.
Protege las implementaciones de proxy intermedio (puerta de enlace de entrada o salida) Sigue las instrucciones que aparecen aquí.

Los recursos de la política de autorización y la política de TLS del servidor se adjuntan al recurso de proxy HTTPS de destino.		 Debes adjuntar la política de TLS del servidor y los recursos de la política de autorización a la puerta de enlace.

Consideraciones y limitaciones

  • La consola de Google Cloud no es compatible con las APIs de enrutamiento de servicios.
  • Usa la versión 3 de la API de xDS o una versión posterior.
    • Versión mínima de Envoy de 1.24.9.
    • 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.
  • Terraform no es compatible con esta versión.
  • Las APIs de enrutamiento de servicio no tienen retrocompatibilidad con las APIs anteriores.
  • Cuando se conecta un recurso TCPRoute a un recurso Mesh, 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 esta TCPRoute.
    • 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 recurso Mesh, el tráfico que enruta el recurso HTTPRoute 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.
  • 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?