Tráfico de entrada para tu malla

Una malla de servicios facilita la comunicación entre los servicios que se ejecutan en la malla. ¿Cómo se obtiene tráfico en una malla? Puedes usar una pasarela para dirigir el tráfico desde fuera de tu malla hacia ella a través de un punto de entrada.

En este documento se describe cómo usar Cloud Load Balancing como puerta de enlace para dirigir el tráfico a tu malla. También se incluye lo siguiente:

• Consideraciones generales sobre tu pasarela.
• Resumen de las opciones al seleccionar una pasarela para tu malla.
• Recomendaciones de arquitectura que puedes aplicar a tu topología de pasarela.

En este documento, puerta de enlace hace referencia a una solución o un patrón para gestionar el tráfico que se dirige a un servicio de tu malla. Ingress Gateway de Istio es una implementación de este patrón. En este documento, gateway es un término genérico que hace referencia al patrón general, no a la implementación de Istio.

Este documento se aplica a las APIs de Cloud Service Mesh. Después de completar los pasos de configuración preparatorios, consulta la sección sobre cómo implementar con una pasarela de entrada.

Cuando diseñes tu malla de servicios, ten en cuenta el tráfico procedente de las siguientes fuentes:

• Tráfico que se origina dentro de tu malla
• Tráfico que procede de fuera de tu malla

El tráfico que se origina en tu malla se desplaza por el plano de datos de la malla de servicios para llegar a un backend o un endpoint asociado al servicio de destino. Sin embargo, el tráfico que se origina fuera de tu malla debe llegar primero al plano de datos de la malla de servicios.

En el siguiente ejemplo de tráfico que se origina en tu malla, Cloud Service Mesh configura tus proxies sidecar. Estos proxies sidecar forman el plano de datos de tu malla de servicios. Si el servicio A quiere comunicarse con el servicio B, ocurre lo siguiente:

1. El servicio A hace una solicitud al servicio B por su nombre.
2. Esta solicitud se intercepta y se redirige al proxy sidecar del servicio A.
3. A continuación, el proxy sidecar envía la solicitud a un endpoint asociado al servicio B.

En el siguiente ejemplo, el tráfico procede de fuera de la malla de servicios y no se desplaza por el plano de datos de la malla de servicios.

En este ejemplo, el cliente está fuera de tu malla de servicios. Como no participa directamente en la malla, el cliente no sabe qué endpoints pertenecen a los servicios de la malla. Es decir, como el cliente no usa un proxy configurado con Cloud Service Mesh para enviar solicitudes salientes, no sabe qué pares de puerto y dirección IP debe usar al enviar tráfico al servicio A o al servicio B. Sin esa información, el cliente no puede acceder a los servicios de tu malla.

Consideraciones sobre tu pasarela

En esta sección se ofrece una descripción general de los aspectos que debe tener en cuenta al seleccionar una pasarela, entre los que se incluyen los siguientes:

• ¿Cómo pueden los clientes acceder a mi pasarela?
• ¿Qué políticas quiero aplicar al tráfico que llega a mi pasarela?
• ¿Cómo distribuye mi gateway el tráfico a los servicios de mi malla?

Permitir que los clientes accedan a la puerta de enlace de tu malla

Los clientes, ya sea en la red pública de Internet, en tu entorno local o en Google Cloud, necesitan una forma de acceder a un servicio de tu malla. Para acceder a un servicio de tu malla, normalmente se usa una dirección IP y un puerto enrutables de forma pública o privada que se resuelven en una puerta de enlace. Los clientes que no estén en tu malla usan esta dirección IP y este puerto para enviar solicitudes a los servicios de tu malla a través de tu pasarela.

Cloud Load Balancing ofrece varias opciones de balanceo de carga que puedes usar como puerta de enlace a tu malla. Las principales preguntas que debes hacerte al elegir un Google Cloud balanceador de carga para que actúe como tu pasarela son las siguientes:

• ¿Mis clientes están en Internet público, en un entorno local o forman parte de mi red de nube privada virtual (VPC)?
• ¿Qué protocolos de comunicación utilizan mis clientes?

Para obtener una descripción general de las opciones de Cloud Load Balancing en función de la ubicación del cliente y del protocolo de comunicación, consulta la sección Elegir una pasarela para la malla.

Gestionar el tráfico en la pasarela

Como tu pasarela se encuentra en el límite de tu malla (entre los clientes que están fuera de tu malla y los servicios que están dentro), es un lugar natural para aplicar políticas cuando el tráfico entra en tu malla. Estas políticas incluyen lo siguiente:

• Gestión del tráfico (por ejemplo, enrutamiento, redirecciones y transformación de solicitudes)
• Seguridad: por ejemplo, terminación de TLS y protección contra denegación de servicio distribuido (DDoS) de Google Cloud Armor
• Almacenamiento en caché de Cloud CDN

En la sección Elige una pasarela para tu malla se destacan las políticas que son relevantes en el perímetro de tu malla.

Enviar tráfico desde la pasarela a un servicio de tu malla

Una vez que la pasarela aplica las políticas al tráfico entrante, decide a dónde enviarlo. Para configurar esto, se usan políticas de gestión del tráfico y de balanceo de carga. Por ejemplo, la pasarela puede inspeccionar el encabezado de la solicitud para identificar el servicio de la malla que debe recibir el tráfico. Una vez que la pasarela identifica el servicio, distribuye el tráfico a un backend específico según una política de balanceo de carga.

En la sección Elige una pasarela para tu malla se describen los back-ends a los que puede enviar tráfico una pasarela.

Elige una pasarela para tu red de malla

Google Cloud ofrece una amplia gama de balanceadores de carga que pueden actuar como puerta de enlace a tu malla. En esta sección se explica cómo seleccionar una pasarela y se comparan las siguientes opciones en función de las dimensiones relevantes para el patrón de pasarela:

• Balanceador de carga de aplicación interno
• Balanceador de carga de aplicación externo
• Balanceador de carga de red de paso a través interno
• Balanceador de carga de red de paso a través externo
• Balanceador de carga de red de proxy externo

En esta sección, nos referimos a las pasarelas de primer nivel y segundo nivel. Estos términos se usan para describir el uso de una o dos pasarelas para gestionar el tráfico de entrada a tu malla.

Puede que solo necesites un nivel, un único balanceador de carga que actúe como puerta de enlace a la malla. Sin embargo, a veces es conveniente tener varias pasarelas. En estas configuraciones, una pasarela gestiona el tráfico entrante Google Cloudy otra pasarela de segundo nivel gestiona el tráfico que entra en la malla de servicios.

Por ejemplo, puede que quieras aplicar políticas de seguridad de Google Cloud Armor al tráfico entrante y políticas de gestión avanzada del tráfico al tráfico que entra en la malla. Google Cloud El patrón de uso de una segunda pasarela configurada con Cloud Service Mesh se describe en la sección Gestionar el tráfico de entrada con una pasarela de segundo nivel en el perímetro de la malla.

En la siguiente tabla se comparan las funciones disponibles en función de la opción de pasarela que elijas.

Pasarela	Ubicación de cliente	Protocolos	Políticas	Backends o endpoints
Balanceador de carga de aplicación interno	Google Cloud-based clients in the same region as the load balancer. Clientes on-premise cuyas solicitudes llegan a la misma Google Cloud región que el balanceador de carga (por ejemplo, mediante Cloud VPN o Cloud Interconnect).	HTTP/1.1 HTTP/2 HTTPS	Gestión avanzada del tráfico Cancelación de TLS con certificados autogestionados	Backends en la misma Google Cloud región que el balanceador de carga, que se ejecutan en: Backends de instancias de máquina virtual (VM) en Compute Engine Instancias de contenedor en Google Kubernetes Engine (GKE) y Kubernetes
Balanceador de carga de aplicación externo	Clientes en Internet público	HTTP/1.1 HTTP/2 HTTPS	Gestión del tráfico Cloud CDN (incluidos los backends de segmentos de Cloud Storage) Cancelación de TLS con certificados gestionados por Google o autogestionados Políticas de SSL Cloud Armor para prevenir ataques DDoS y ataques web Compatibilidad con Identity-Aware Proxy (IAP) para la autenticación de usuarios	Back-ends de cualquier Google Cloud región, que se ejecuten en: Máquinas virtuales en Compute Engine Instancias de contenedor en GKE y Kubernetes
Balanceador de carga de red de paso a través interno	Clientes basados enGoogle Cloudde cualquier región. Para ello, se necesita acceso global si los clientes se encuentran en una región distinta a la del balanceador de carga. Clientes on-premise cuyas solicitudes llegan a cualquier Google Cloud región (por ejemplo, mediante Cloud VPN o Cloud Interconnect).	TCP		Back-ends en la misma Google Cloud región que el balanceador de carga, que se ejecutan en máquinas virtuales de Compute Engine.
Balanceador de carga de red de paso a través externo	Clientes en Internet público	TCP o UDP		Back-ends en la misma Google Cloud región que el balanceador de carga, que se ejecutan en máquinas virtuales de Compute Engine.
Balanceador de carga de red del proxy externo	Clientes en Internet público	SSL o TCP	Terminación TLS con certificados gestionados por Google o autogestionados (solo proxy SSL) Políticas de SSL (solo proxy SSL)	Back-ends de cualquier Google Cloud región, que se ejecuten en: Máquinas virtuales en Compute Engine Instancias de contenedor en GKE y Kubernetes
Proxy perimetral (en instancias de VM o de contenedor) configurado por Cloud Service Mesh	Los clientes deben encontrarse en una ubicación en la que se cumpla una de las siguientes condiciones: Pueden enviar una solicitud a un balanceador de carga gestionado por a Google Cloud, que, a continuación, envía la solicitud al proxy perimetral. Para obtener más información, consulta Gestionar el tráfico de entrada con una pasarela de segundo nivel en el perímetro de tu malla. Pueden enviar una solicitud a través de un proxy (por ejemplo, un proxy sidecar) que configura Cloud Service Mesh. Pueden enviar una solicitud directamente a la dirección IP y al puerto de una máquina virtual o de una instancia de contenedor que ejecute el proxy perimetral.	HTTP/1.1 HTTP/2	Gestión avanzada del tráfico (incluida la compatibilidad con regex)	Back-ends de cualquier Google Cloud región, que se ejecuten en: Máquinas virtuales en Compute Engine Instancias de contenedor en GKE y Kubernetes

Para ver una comparación detallada de las funciones, consulta la página Funciones de los balanceadores de carga. Para obtener una descripción detallada de las funciones de Cloud Service Mesh, consulta la página Funciones de Cloud Service Mesh.

Desplegar y configurar pasarelas

Un último aspecto que debes tener en cuenta al seleccionar tu pasarela es la experiencia de desarrollo y las herramientas que quieras usar. Google Cloud ofrece varias formas de crear y gestionar tu pasarela.

APIs de Google Cloud CLI y Compute Engine

Para configurar los productos de balanceo de carga gestionados de Google Cloudy Cloud Service Mesh, puedes usar la CLI de Google Cloud y las APIs de Compute Engine. La CLI de gcloud y las APIs proporcionan mecanismos para implementar y configurar tus recursos de forma imperativa. Google Cloud Para automatizar tareas repetitivas, puedes crear secuencias de comandos.

Google Cloud consola

Para configurar Cloud Service Mesh y los balanceadores de carga gestionados de Google Cloud, puedes usar la consola de Google Cloud .

Para configurar tu patrón de pasarela, probablemente necesites la página Cloud Service Mesh y la página Balanceo de carga.

GKE e Ingress de varios clústeres

Los controladores de red de GKE y GKE Enterprise también admiten el despliegue de Cloud Load Balancing para la integración con la red de contenedores. Proporcionan una interfaz declarativa de estilo Kubernetes para desplegar y configurar las pasarelas. Los controladores Ingress de GKE y MultiCluster Ingress gestionan los balanceadores de carga internos y externos para enviar tráfico a un solo clúster o a varios clústeres de GKE. El recurso Ingress también se puede configurar para que apunte a servicios configurados con Cloud Service Mesh que se hayan desplegado en clústeres de GKE.

Patrones de arquitectura de pasarela

En esta sección se describen patrones de alto nivel y se proporcionan diagramas de arquitectura para su pasarela.

El patrón más habitual consiste en usar un balanceador de carga gestionado por Google Cloudcomo pasarela:

1. Los clientes envían tráfico a un balanceador de carga gestionado por Google Cloud, que actúa como tu puerta de enlace.

   • La pasarela aplica las políticas.

2. La pasarela envía el tráfico a un servicio de tu malla.

Un patrón más avanzado implica el uso de pasarelas en dos niveles. Las pasarelas funcionan de la siguiente manera:

1. Los clientes envían tráfico a un balanceador de carga gestionado por Google Cloud, que actúa como puerta de enlace de primer nivel.

   • La pasarela aplica las políticas.

2. La pasarela envía el tráfico a un proxy perimetral (o un grupo de proxies perimetrales) configurado por Cloud Service Mesh. Este proxy perimetral actúa como una pasarela de segundo nivel. En este nivel se hace lo siguiente:

   • Proporciona una separación clara de las responsabilidades en la que, por ejemplo, un equipo se encarga del tráfico de entrada que accede a Google Cloud , mientras que otro equipo se encarga del tráfico de entrada que accede a la malla de ese equipo.

   • Te permite aplicar políticas que puede que no sean compatibles con el balanceador de carga gestionado porGoogle Cloud.

3. La pasarela de segundo nivel envía el tráfico a un servicio de tu malla.

El patrón de entrada finaliza cuando el tráfico llega a un servicio de la malla. En las siguientes secciones se describen tanto el caso habitual como los patrones avanzados.

Habilitar el tráfico de entrada desde Internet

Si tus clientes están fuera Google Cloud y necesitan acceder a Google Cloud a través de Internet público, puedes usar uno de los siguientes balanceadores de carga como pasarela:

• Balanceador de carga de aplicación externo
• Balanceador de carga de red de paso a través externo
• Balanceador de carga de red de proxy externo

En este patrón, el balanceador de carga gestionado por Google Cloudactúa como tu puerta de enlace. La puerta de enlace gestiona el tráfico de entrada antes de reenviarlo a un servicio de tu malla.

Por ejemplo, puedes elegir un balanceador de carga de aplicación externo como puerta de enlace para usar lo siguiente:

• Una dirección IP Anycast global enrutable públicamente, que minimiza la latencia y los costes de recorrido de la red.
• Cloud Armor y terminación TLS para proteger el tráfico de tu malla.
• Cloud CDN para servir contenido web y de vídeo.
• Funciones de gestión del tráfico, como el enrutamiento basado en hosts y en rutas.

Para obtener más información que te ayude a elegir una pasarela adecuada, consulta la sección Elegir una pasarela para tu malla.

Habilitar el tráfico de entrada de clientes en redes VPC y on-premise conectadas

Si tus clientes están dentro de tu red VPC o si están en las instalaciones y pueden acceder a los servicios mediante un método de conectividad privada (como Cloud VPN o Cloud Interconnect), puedes usar uno de los siguientes balanceadores de carga como puerta de enlace: Google Cloud

• Balanceador de carga de aplicación interno
• Balanceador de carga de red de paso a través interno

En este patrón, el balanceador de carga gestionado por Google Cloudactúa como tu puerta de enlace. La puerta de enlace gestiona el tráfico de entrada antes de reenviarlo a un servicio de tu malla.

Por ejemplo, puedes elegir un balanceador de carga de aplicación interno como tu pasarela para poder usar estas funciones:

• Una dirección IP privada
• Cancelación de TLS para proteger tu malla
• Funciones avanzadas de gestión del tráfico, como la división del tráfico basada en el peso
• NEGs como backends

Para obtener más información que te ayude a elegir una pasarela adecuada, consulta la sección Elegir una pasarela para tu malla.

Gestionar el tráfico de entrada con una pasarela de segundo nivel en el perímetro de tu malla

En función de tus necesidades, puedes plantearte usar un patrón más avanzado que añada una puerta de enlace adicional.

Esta pasarela es un proxy perimetral (o un conjunto de proxies) configurado con Cloud Service Mesh que se encuentra detrás del balanceador de carga gestionado por Google Cloud. Puedes alojar esta pasarela de segundo nivel en tu proyecto mediante un pool de VMs de Compute Engine (un grupo de instancias gestionado) o servicios de GKE.

Aunque este patrón es más avanzado, ofrece ventajas adicionales:

• El balanceador de carga gestionado por Google Cloudaplica un conjunto inicial de políticas, por ejemplo, la protección de Cloud Armor si usas un balanceador de carga de aplicación externo.

• El proxy perimetral configurado en Cloud Service Mesh aplica un segundo conjunto de políticas que puede que no estén disponibles en el balanceador de carga gestionado por Google Cloud. Estas políticas incluyen la gestión avanzada del tráfico, que usa expresiones regulares aplicadas a los encabezados HTTP y la división del tráfico basada en el peso.

Este patrón se puede configurar para que refleje la estructura de tu organización. Por ejemplo:

1. Un equipo puede ser responsable de gestionar el tráfico de entrada aGoogle Cloud , mientras que otro equipo es responsable de gestionar el tráfico de entrada a su malla.

2. Si varios equipos ofrecen servicios en una VPC compartida y cada equipo tiene su propio proyecto de servicio, los equipos pueden usar este patrón para gestionar y aplicar políticas en sus propias mallas. Cada equipo puede exponer una pasarela configurada con Cloud Service Mesh a la que se puede acceder mediante un único par de dirección IP y puerto. Un equipo puede definir y gestionar de forma independiente las políticas que se aplican al tráfico de entrada de la malla del equipo.

Este patrón se puede implementar con cualquier balanceador de carga gestionado por Google Cloud, siempre que pueda enviar tráfico a los back-ends que alojan las pasarelas configuradas con Cloud Service Mesh.

Usar las APIs de enrutamiento de servicios para el tráfico de entrada

Las APIs de enrutamiento de servicios proporcionan el recurso Gateway para configurar la gestión del tráfico y la seguridad de los proxies de Envoy que actúan como gateways de entrada, lo que permite que los clientes externos se conecten a la malla de servicios (de norte a sur). Para obtener más información, consulta la descripción general del enrutamiento de servicios y el artículo Configurar una pasarela de entrada.

Siguientes pasos

• Para configurar una pasarela de entrada, consulta el artículo Configuración de Cloud Service Mesh para una pasarela de entrada.
• Para agrupar las VMs y los contenedores que ejecutan tu código como endpoints de tus servicios, consulta Descubrimiento de servicios de Cloud Service Mesh.
• Para usar Cloud Service Mesh con una VPC compartida, consulta Configurar una malla de servicios de varios clústeres.
• Para obtener más información sobre Cloud Service Mesh, consulta la información general sobre Cloud Service Mesh.