Descripción general de la malla de servicios de GKE de Traffic Director

Este documento está dirigido a los usuarios de Google Kubernetes Engine que deseen implementar una malla de servicios de Traffic Director mediante la API de puerta de enlace de Kubernetes.

Puedes configurar Traffic Director para GKE mediante las API de puerta de enlace de Kubernetes, lo que habilita las comunicaciones de servicio a servicio, la administración del tráfico, el balanceo de cargas global y la aplicación de la política de seguridad para casos de uso de malla de servicios.

API de Kubernetes y API de Google Cloud

Puedes configurar una malla de servicios de Traffic Director mediante dos API diferentes:

En este documento y las guías de configuración asociadas, se proporcionan instrucciones para usar la API de puerta de enlace de Kubernetes a fin de configurar una malla de servicios de Traffic Director.

Te recomendamos que uses las APIs de Kubernetes Gateway en Google Kubernetes Engine y no recomendamos usar ambas APIs para configurar el enrutamiento en la misma malla de servicios en GKE.

La API de enrutamiento de servicio usa los mismos nombres de recursos que los recursos en las API de puerta de enlace de Kubernetes, lo que te facilita el uso de las dos API. Los recursos de Kubernetes que configuras son equivalentes en términos de funciones a los recursos de Google Cloud que representa la API de enrutamiento de servicios para Traffic Director.

En las siguientes secciones, se describen los recursos y la arquitectura que usa la integración de Traffic Director con las API de puerta de enlace de Kubernetes.

API de puerta de enlace

La API de Gateway es una colección de recursos que modelan herramientas de redes de servicio en Kubernetes. La API de Gateway de Kubernetes es un proyecto de código abierto que se enfoca en admitir casos de uso de balanceador de cargas y de entrada a través de una API de enrutamiento genérica. La API de enrutamiento genérica tiene muchas implementaciones. Las definiciones de recursos personalizados (CRD) de Traffic Director se agregan como una extensión a la API de puerta de enlace de código abierto. Las CRD admiten casos prácticos de malla de servicios y usan la misma API de enrutamiento genérico que ingresa la API de Gateway.

La API de Gateway está organizada de forma jerárquica, con un recurso superior de Gateway y un GatewayClass asociado, al que adjuntas rutas. GKE incluye un recurso TDMesh que es un par del recurso Gateway. Puedes adjuntar los mismos tipos Route al recurso TDMesh. El recurso TDMesh es en el que adjuntas las rutas y políticas para las mallas de servicios.

API de puerta de enlace, recurso de puerta de enlace, recurso de malla y rutas
API de puerta de enlace, recurso de puerta de enlace, recurso de malla y rutas (haz clic para ampliar)

Flota

Una flota consiste en uno o más clústeres de GKE que se agrupan de manera lógica. Una flota te permite administrar capacidades y aplica políticas de manera coherente en varios clústeres. Cuando usas una flota, puedes administrar una malla de servicios de Traffic Director que abarque varios clústeres.

Arquitectura

Traffic Director admite la API de Gateway en GKE mediante la programación de los planos de datos de tus clústeres para implementar los comportamientos de herramientas de redes especificados en los recursos de la API de Gateway. Traffic Director es un plano de control administrado por Google que no procesa tráfico del plano de datos. Los proxies de Envoy que se ejecutan como sidecars a tus cargas de trabajo o clientes de gRPC sin proxy procesan el tráfico en el plano de datos. Traffic Director configura proxies de Envoy y clientes de gRPC sin proxy a través de la API de xDSv3.

Traffic Director ofrece una solución de plano de control administrada y disponible a nivel global que es más sólida y escalable que ejecutar controladores en el clúster. Debido a que es una solución global, Traffic Director puede balancear las cargas del tráfico entre las cargas de trabajo distribuidas en varios clústeres de GKE. En la siguiente ilustración, Traffic Director administra el tráfico a los servicios en tres clústeres que se encuentran en una sola flota mediante los recursos de la API de Gateway.

Una malla de servicios de varios clústeres de Traffic Director configurada con la API de puerta de enlace
Una malla de servicios de varios clústeres de Traffic Director configurada mediante la API de puerta de enlace (haz clic para ampliar)

Debes designar un clúster en tu flota como el clúster de configuración. El clúster de configuración es donde se almacenan los recursos de la API de Gateway. Traffic Director solo observa los recursos que están en el clúster de configuración e ignora los que están en otros clústeres de la flota. Consulta Diseño del clúster de configuración en la documentación de GKE para obtener información más detallada sobre el clúster de configuración.

Con los servicios de varios clústeres de GKE, los recursos de la API de puerta de enlace en el clúster de configuración pueden hacer referencia a los servicios de Kubernetes en cualquier clúster de una flota. Consulta Servicios de varios clústeres para obtener más información sobre el descubrimiento de servicios de varios clústeres.

Recursos

Traffic Director es compatible con los proxies de Envoy y gRPC sin proxy en el plano de datos de una malla de servicios. Ambos clientes reciben la configuración de Traffic Director para una malla de servicios en particular si especifican el nombre y el número de proyecto correspondiente del recurso TDMesh en su respectiva configuración de arranque. Las guías de configuración de Traffic Director con las APIs de Kubernetes Gateway proporcionan configuraciones del plano de datos de demostración con Envoy y gRPC sin proxy.

TDMesh recurso

El recurso TDMesh es un recurso personalizado de Traffic Director. Es una extensión de las API de Gateway abierto que admite los casos prácticos de la malla de servicios de Traffic Director. Mediante el recurso TDMesh, creas una instancia de la malla de servicios en la flota. Las rutas conectadas al recurso TDMesh especifican los comportamientos de enrutamiento de servicio a servicio en la malla de servicios.

Route recursos

Se puede conectar un subconjunto de los recursos de ruta de la API de puerta de enlace a un recurso TDMesh para especificar el enrutamiento a nivel de servicio dentro de la malla de servicios. Traffic Director admite los siguientes recursos Route:

  • HTTPRoute
  • TCPRoute
  • TDGRPCRoute (recurso personalizado de Traffic Director)

Por ejemplo, puedes crear un HTTPRoute para especificar que las solicitudes HTTP dirigidas al host payments.svc.internal se enruten al servicio de Kubernetes service-payments. Cuando conectas el recurso HTTPRoute a un recurso TDMesh al que se suscriben las instancias del plano de datos, las solicitudes HTTP que envían las cargas de trabajo dentro de la malla se enrutan según corresponda.

Esta versión aumenta los recursos Route genéricos en la API de Gateway con un tipo de ruta nuevo, TDGRPCRoute. El tipo de ruta nuevo proporciona una experiencia de primera clase para enrutar solicitudes de gRPC, mediante la coincidencia con primitivas de gRPC nativas, como definiciones de métodos y servicios.

Usa los recursos de la API de puerta de enlace en GKE para configurar Traffic Director
Usa los recursos de la API de puerta de enlace en GKE para configurar Traffic Director (haz clic para ampliar)

Limitaciones

  • Traffic Director configura los siguientes comportamientos predeterminados para todos los servicios de Kubernetes en la malla de servicios. No puedes cambiar estos comportamientos.
    • Las verificaciones de estado de TCP se configuran en los puertos de servicio a los que hacen referencia cualquier recurso Route de la API de puerta de enlace.
    • Se configura un tiempo de espera predeterminado de 30 segundos para todas las solicitudes entrantes a servicios.
    • La afinidad de sesión está inhabilitada.
  • El inyector automático de Envoy solo admite una malla por flota.
  • Las funciones de seguridad de Traffic Director no se pueden habilitar mediante la API de puerta de enlace.
  • Debes configurar los recursos TDMesh y Route en GKE solo con la API de puerta de enlace. No puedes usar la consola de Google Cloud, la CLI de gcloud ni las API de REST.
  • Todos los clústeres deben estar en un solo proyecto. No se admite una malla de servicios que abarque varios clústeres en varios proyectos.
  • No puedes configurar ni ver una malla de servicios de GKE mediante la consola de Google Cloud.
  • No se admite la observabilidad del plano de control con Cloud Logging ni Cloud Monitoring.

¿Qué sigue?