Tráfico de entrada para la malla

Una malla de servicios facilita las comunicaciones entre los servicios que se ejecutan en la malla. ¿Cómo puedes dirigir el tráfico a la malla? Puedes usar una puerta de enlace para dirigir el tráfico desde el exterior de la malla hacia esta 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 la malla. Además, se incluye lo siguiente:

  • Consideraciones de alto nivel para la puerta de enlace
  • Una descripción general de las opciones durante la selección de una puerta de enlace para la malla
  • Recomendaciones de arquitectura que puedes aplicar a la topología de puerta de enlace

En este documento, se aplica a las APIs de enrutamiento del servicio de Traffic Director. Después de completar los pasos de configuración preparatorios, consulta Configuración de Traffic Director para una puerta de enlace de entrada, que contiene instrucciones para implementar con una puerta de enlace de entrada.

Cuando diseñes la malla de servicios, considera el tráfico que proviene de las siguientes fuentes:

  • El tráfico que se origina dentro de la malla
  • El tráfico que se origina fuera de la malla

El tráfico que se origina dentro de la malla viaja en el plano de datos de la malla de servicios para alcanzar un backend o extremo asociado con el servicio de destino. Sin embargo, el tráfico que se origina fuera de la malla primero debe llegar al plano de datos de la malla de servicios.

En el siguiente ejemplo de tráfico que se origina dentro de la malla, Traffic Director configura los proxies de sidecar. Estos proxies de sidecar forman el plano de datos de la malla de servicios. Si el servicio A quiere comunicarse con el servicio B, ocurre lo siguiente:

  1. El servicio A debe realizar una solicitud al servicio B por nombre.
  2. Esta solicitud se intercepta y redirecciona al proxy de sidecar del servicio A.
  3. Luego, el proxy de sidecar envía la solicitud a un extremo asociado con el servicio B.
El plano de datos de la malla maneja el tráfico interno a la malla de servicios.
El plano de datos de la malla controla el tráfico interno de la malla de servicios (haz clic para ampliar)


En el siguiente ejemplo, el tráfico se origina fuera de la malla de servicios y no se traslada a lo largo del plano de datos de la malla de servicios.

El plano de datos de la malla de servicios no controla el tráfico externo a la malla de servicios.
El plano de datos de la malla de servicios no controla el tráfico externo a la malla de servicios (haz clic para ampliar)

En este ejemplo, el cliente se encuentra fuera de la malla de servicios. Debido a que no participa directamente en la malla, el cliente no sabe qué extremos pertenecen a los servicios dentro de la malla. En otras palabras, debido a que el cliente no usa un proxy configurado por Traffic Director para enviar solicitudes salientes, no sabe qué pares de direcciones IP se deben usar cuando se envía tráfico al Servicio A o al Servicio B. Sin esa información, el cliente no puede acceder a los servicios dentro de la malla.

Consideraciones para la puerta de enlace

En esta sección, se proporciona una descripción general de los problemas que deben tenerse en cuenta cuando seleccionas una puerta de enlace, incluidos los siguientes:

  • ¿Cómo pueden los clientes acceder a la puerta de enlace?
  • ¿Qué políticas quiero aplicar al tráfico que llega a la puerta de enlace?
  • ¿De qué manera la puerta de enlace distribuye el tráfico a los servicios en la malla?

Permite que los clientes lleguen a la puerta de enlace de la malla

Los clientes, ya sea en la Internet pública, en tu entorno local o dentro Google Cloud, necesitan una manera de llegar a un servicio dentro de la malla. Por lo general, se puede acceder a un servicio en la malla mediante una dirección IP y un puerto que se puedan enrutar de forma pública o privada y que se resuelvan en una puerta de enlace. Los clientes fuera de la malla usan la dirección IP y el puerto para enviar solicitudes a servicios en la malla a través de la puerta de enlace.

Cloud Load Balancing proporciona varias opciones de balanceo de cargas que puedes usar como puerta de enlace para la malla. Las preguntas principales que debes considerar cuando eliges un balanceador de cargas de Google Cloud que funcione como la puerta de enlace son las siguientes:

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

Para obtener una descripción general de las opciones de Cloud Load Balancing, según la ubicación del cliente y el protocolo de comunicación, consulta la sección Elige una puerta de enlace para tu malla.

Controla el tráfico en la puerta de enlace

Debido a que la puerta de enlace se encuentra en el perímetro de la malla, entre los clientes que están fuera de ella y los servicios que están dentro, la puerta de enlace es un lugar natural para aplicar políticas cuando el tráfico ingresa a la malla. Estas políticas incluyen lo siguiente:

  • Administración de tráfico (por ejemplo, enrutamiento, redireccionamientos y transformación de solicitudes)
  • Seguridad, por ejemplo, finalización de TLS y protección contra denegación de servicio distribuido (DSD) de Google Cloud Armor
  • Almacenamiento en caché de Cloud CDN

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

Envía tráfico desde la puerta de enlace hacia un servicio en la malla

Después de que la puerta de enlace aplica políticas al tráfico entrante, decide a dónde se debe enviar el tráfico. Para configurar esto, usa las políticas de balanceo de cargas y administración del tráfico. Por ejemplo, la puerta de enlace puede inspeccionar el encabezado de la solicitud para identificar el servicio de malla que debe recibir el tráfico. Después de que la puerta de enlace identifica el servicio, distribuye el tráfico a un backend específico de acuerdo con una política de balanceo de cargas.

En la sección Elige una puerta de enlace para la malla, se describen los backends a los que una puerta de enlace puede enviar tráfico.

Elige una puerta de enlace para la malla

Google Cloud ofrece una amplia gama de balanceadores de cargas que pueden funcionar como puerta de enlace a la malla. En esta sección, se explica cómo seleccionar una puerta de enlace mediante la comparación de las siguientes opciones junto a las dimensiones relevantes para el patrón de puerta de enlace:

En esta sección, hacemos referencia a puertas de enlace de first-level y de first-level. Estos términos se usan a fin de describir el uso de una o dos puerta de enlace para controlar el tráfico de entrada a la malla.

Es posible que necesites un solo nivel, un solo balanceador de cargas que actúe como puerta de enlace a la malla. Sin embargo, a veces conviene tener varias puertas de enlace. En estas opciones de configuración, una puerta de enlace controla el tráfico que llega a Google Cloud, y otra puerta de enlace diferente de segundo nivel controla el tráfico cuando ingresa a la malla de servicios.

Por ejemplo, puede que quieras aplicar políticas de seguridad de Google Cloud Armor al tráfico que ingresa a Google Cloud y políticas avanzadas de administración de tráfico al tráfico que ingresa a la malla. El patrón de usar una segunda puerta de enlace configurada con Traffic Director se analiza en la sección Controla el tráfico de entrada mediante una puerta de enlace de segundo nivel en el perímetro de la malla.

En la siguiente tabla, se comparan las funciones disponibles, según la opción de puerta de enlace que selecciones:

Puerta de enlace Ubicación del cliente Protocolos Políticas Backends y extremos
Balanceador de cargas de aplicaciones interno

Clientes basados en Google Cloud en la misma región que el balanceador de cargas.

Clientes locales cuyas solicitudes llegan a la misma región de Google Cloud que el balanceador de cargas, por ejemplo, mediante Cloud VPN o Cloud Interconnect.

HTTP/1.1

HTTP/2

HTTPS

Administración avanzada del tráfico

Finalización de TLS mediante certificados autoadministrados

Backends en la misma región de Google Cloud que el balanceador de cargas, que se ejecutan en los siguientes lugares:

  • Backends de instancias de máquina virtual (VM) en Compute Engine
  • Instancias de contenedor en Google Kubernetes Engine (GKE) y Kubernetes
Balanceador de cargas de aplicaciones externo Clientes en la Internet pública

HTTP/1.1

HTTP/2

HTTPS

Administración del tráfico

Cloud CDN (incluidos los backend de depósitos de Cloud Storage)

Finalización de TLS mediante certificados autoadministrados o administrados por Google

Políticas de SSL

Google Cloud Armor para DSD y la prevención de ataques web

Compatibilidad de Identity-Aware Proxy (IAP) con la autenticación de usuarios

Backends en cualquier región de Google Cloud, que se ejecutan en lo siguiente:

  • VM en Compute Engine
  • Instancias de contenedor en GKE y Kubernetes
Balanceador de cargas de red de transferencia interno

Clientes basados en Google Cloud en cualquier región. Esto requiere acceso global si los clientes están en una región distinta que el balanceador de cargas.

Clientes locales cuyas solicitudes llegan a cualquier región de Google Cloud (por ejemplo, mediante Cloud VPN o Cloud Interconnect)

TCP Backends en la misma región de Google Cloud que el balanceador de cargas, que se ejecutan en las VM en Compute Engine.
Balanceador de cargas de red de transferencia externo Clientes en la Internet pública TCP o UDP Backends en la misma región de Google Cloud que el balanceador de cargas, que se ejecutan en las VM en Compute Engine.
Balanceador de cargas de red de proxy externo Clientes en la Internet pública SSL o TCP

Finalización de TLS mediante certificados autoadministrados o administrados por Google (solo proxy SSL)

Políticas de SSL (solo proxy SSL)

Backends en cualquier región de Google Cloud, que se ejecutan en lo siguiente:

  • VM en Compute Engine
  • Instancias de contenedor en GKE y Kubernetes
Proxy perimetral
(en instancias de VM o de contenedores) que configura Traffic Director
Los clientes deben encontrarse en una ubicación en la que se aplique una de las siguientes opciones:
  • Pueden enviar una solicitud a un balanceador de cargas administrado por Google Cloud, que luego envía la solicitud al proxy perimetral. Para obtener más información, consulta Controla el tráfico de entrada mediante una puerta de enlace de segundo nivel en el perímetro de la malla.
  • Pueden enviar una solicitud a través de un proxy, por ejemplo, un proxy de sidecar, que configura Traffic Director.
  • Pueden enviar una solicitud directamente a la dirección IP y al puerto de una instancia de contenedor o VM que ejecuta el proxy perimetral.

HTTP/1.1

HTTP/2

Administración avanzada del tráfico (incluida la compatibilidad con regex)

Backends en cualquier región de Google Cloud, que se ejecutan en lo siguiente:

  • VM en Compute Engine
  • Instancias de contenedor en GKE y Kubernetes

Para obtener una comparación detallada de cada función, consulta la página Funciones del balanceador de cargas. Para obtener una descripción general detallada de las funciones de Traffic Director, consulta la página Funciones de Traffic Director.

Implementa y configura puertas de enlace

El último aspecto que se debe tener en cuenta a la hora de seleccionar la puerta de enlace es la experiencia del desarrollador y las herramientas que quieres usar. Google Cloud ofrece varios enfoques para crear y administrar la puerta de enlace.

API de Google Cloud CLI y Compute Engine

Para configurar los productos de balanceo de cargas administrados de Google Cloud y Traffic Director, puedes usar Google Cloud CLI y las API de Compute Engine. La CLI y las API de gcloud proporcionan mecanismos para implementar y configurar los recursos de Google Cloud de manera imperativa. Para automatizar las tareas repetitivas, puedes crear secuencias de comandos.

Consola de Google Cloud

Para configurar Traffic Director y los balanceadores de cargas administrados de Google Cloud, puedes usar la consola de Google Cloud.

Para configurar el patrón de puerta de enlace, es probable que necesites la página Traffic Director y el balanceo de cargas.

Entrada de varios clústeres y GKE

Los controladores de red de GKE y GKE Enterprise también admiten la implementación de Cloud Load Balancing para la integración incorporada en redes de contenedores. Proporcionan una interfaz declarativa del estilo de Kubernetes para implementar y configurar puertas de enlace. Los controladores de Ingress de GKE y de Ingress de varios clústeres administran los balanceadores de cargas internos y externos para el envío de tráfico a un solo clúster o a través de varios clústeres de GKE. El recurso Ingress también se puede configurar para que apunte a los servicios configurados con Traffic Director que se implementan en clústeres de GKE.

Patrones de arquitectura de puerta de enlace

En esta sección, se describen patrones de alto nivel y se proporcionan diagramas de arquitectura para la puerta de enlace.

El patrón más común implica el uso de un balanceador de cargas administrado por Google Cloud como la puerta de enlace:

  1. Los clientes envían tráfico a un balanceador de cargas administrado por Google Cloud que actúa como la puerta de enlace.

    • La puerta de enlace aplica políticas.
  2. La puerta de enlace envía el tráfico a un servicio en la malla.

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

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

    • La puerta de enlace aplica políticas.
  2. La puerta de enlace envía el tráfico a un proxy perimetral (o a un grupo de proxies perimetrales) configurado con Traffic Director. Este proxy perimetral actúa como una puerta de enlace de segundo nivel. Este nivel realiza las siguientes acciones:

    • Proporciona una separación clara de los asuntos en los que, por ejemplo, un equipo puede ser responsable del tráfico de entrada que ingresa a Google Cloud, mientras que otro equipo es responsable del tráfico de entrada que ingresa a la malla de ese equipo.

    • Te permite aplicar políticas que puede que no sean compatibles con el balanceador de cargas administrado por Google Cloud.

  3. La puerta de enlace de segundo nivel envía el tráfico a un servicio en la malla.

El patrón de entrada finaliza una vez que el tráfico llega a un servicio dentro de la malla. En las siguientes secciones, se describen los casos comunes y los patrones avanzados.

Habilita el tráfico de entrada desde Internet

Si tus clientes están fuera de Google Cloud y necesitan llegar a Google Cloud a través de la Internet pública, puedes usar uno de los siguientes balanceadores de cargas como puerta de enlace:

Tráfico de entrada de clientes en la Internet pública a servicios en la malla mediante un balanceador de cargas.
Tráfico de entrada de clientes en la Internet pública a servicios en la malla mediante un balanceador de cargas (haz clic para ampliar)

En este patrón, el balanceador de cargas administrado por Google Cloud funciona como la puerta de enlace. La puerta de enlace maneja el tráfico de entrada antes de reenviarlo a un servicio en la malla.

Por ejemplo, puedes elegir un balanceador de cargas de aplicaciones externo como puerta de enlace para usar lo siguiente:

  • Una dirección IP Anycast global, que se puede enrutar a nivel público, lo que minimiza los costos de recorrido de red y latencia
  • Google Cloud Armor y la finalización de TLS para asegurar el tráfico a la malla
  • Cloud CDN para entregar contenido web y de video
  • Funciones de administración de tráfico, como enrutamiento basado en host y ruta

Si deseas obtener más información a fin de ayudarte a elegir una puerta de enlace adecuada, consulta la sección Elige una puerta de enlace para tu malla.

Habilita el tráfico de entrada de clientes en la VPC y las redes locales conectadas

Si tus clientes están dentro de la red de VPC o son locales y pueden acceder a los servicios de Google Cloud mediante un método de conectividad privado (como Cloud VPN o Cloud Interconnect), puedes usar uno de los siguientes balanceadores de cargas como la puerta de enlace.

Tráfico de entrada de clientes en una red de VPC a servicios en la malla mediante un balanceador de cargas.
Tráfico de entrada de clientes en una red de VPC a servicios en la malla mediante un balanceador de cargas (haz clic para ampliar)

En este patrón, el balanceador de cargas administrado por Google Cloud funciona como la puerta de enlace. La puerta de enlace maneja el tráfico de entrada antes de reenviarlo a un servicio en la malla.

Por ejemplo, puedes elegir un balanceador de cargas de aplicaciones interno como la puerta de enlace para poder usar estas funciones:

  • Una dirección IP que se pueda usar de manera privada
  • La finalización de TLS para asegurar la malla
  • Funciones avanzadas de administración de tráfico, como la división de tráfico según el peso
  • NEG como backends

Si deseas obtener más información a fin de ayudarte a elegir una puerta de enlace adecuada, consulta la sección Elige una puerta de enlace para tu malla.

Controla el tráfico de entrada mediante una puerta de enlace de segundo nivel en el perímetro de la malla

Según tus necesidades, puedes considerar un patrón más avanzado que agregue una puerta de enlace adicional.

Tráfico de entrada de clientes externos a servicios en la malla mediante un balanceador de cargas y un proxy perimetral.
Tráfico de entrada de clientes externos a servicios en la malla mediante un balanceador de cargas y un proxy perimetral (haz clic para ampliar)

Esta puerta de enlace es un proxy perimetral (o grupo de proxies) configurado con Traffic Director que se encuentra detrás del balanceador de cargas administrado por Google Cloud. Puedes alojar esta puerta de enlace de segundo nivel en el proyecto mediante un grupo de VM de Compute Engine (un grupo de instancias administrado) o servicios de GKE.

Si bien este patrón es más avanzado, proporciona beneficios adicionales:

  • El balanceador de cargas administrado por Google Cloud aplica un conjunto inicial de políticas, por ejemplo, la protección de Google Cloud Armor si usas un balanceador de cargas de aplicaciones externo.

  • El proxy perimetral configurado con Traffic Director aplica un segundo conjunto de políticas que pueden no estar disponibles en el balanceador de cargas administrado por Google Cloud. Estas políticas incluyen la administración avanzada del tráfico que usa expresiones regulares aplicadas a los encabezados HTTP y la división de tráfico según el peso.

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

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

  2. Si varios equipos ofrecen servicios en una VPC compartida, y cada uno de los equipos posee su propio proyecto de servicio, pueden usar este patrón para administrar y aplicar políticas en sus propias mallas. Cada equipo puede exponer una puerta de enlace configurada con Traffic Director, a la que se pueda acceder en un solo par de puerto y dirección IP. Luego, un equipo puede definir y administrar de forma independiente las políticas que se aplican en el tráfico de entrada a la malla del equipo.

Este patrón se puede implementar mediante cualquier balanceador de cargas administrado por Google Cloud, siempre que el balanceador de cargas pueda enviar tráfico a los backends que alojan las puertas de enlace configuradas con Traffic Director.

Usa las API de enrutamiento de servicio para el tráfico de entrada

Las API de enrutamiento de servicio proporcionan el recurso Gateway para configurar la administración del tráfico y la seguridad de los 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). Para obtener más información, lee la descripción general del enrutamiento de servicios y cómo configurar una puerta de enlace de entrada.

¿Qué sigue?