Tráfico de entrada para tu malla

Una malla de servicios facilita las comunicaciones entre los servicios que se ejecutan en la malla. Pero ¿cómo puedes obtener tráfico en tu malla? Este paso (dirigir el tráfico desde el exterior de la malla hacia esta a través de un punto de entrada) se puede resolver con una puerta de enlace.

En este documento, se describe cómo usar Cloud Load Balancing como una puerta de enlace para obtener tráfico en tu malla.

Resumen

Cuando diseñes tu malla de servicios, debes considerar el tráfico que proviene de estas fuentes:

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

El tráfico que se origina dentro de tu malla viaja en el plano de datos de la malla de servicios para llegar a un backend o un extremo asociado con el servicio de destino. Pero el tráfico que se origina fuera de tu 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 tu malla, Traffic Director configura tus proxies de sidecar. Estos proxies de sidecar forman el plano de datos de tu malla de servicios. Si el servicio A quiere comunicarse con el servicio B, debe ocurrir lo siguiente:

  1. El servicio A realiza una solicitud al servicio B por nombre.
  2. Esta solicitud se intercepta y se redirecciona al proxy de sidecar del servicio A.
  3. El proxy de sidecar envía la solicitud a un extremo asociado con el servicio B.
Tráfico interno de la malla de servicios administrado por el plano de datos de malla de servicios (haz clic para ampliar)
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 tu malla de servicios y no viaja 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 (haz clic para ampliar)
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 está fuera de tu 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 envía solicitudes salientes con un proxy configurado por Traffic Director, no sabe qué pares de puerto y dirección IP usar cuando 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 tu malla.

Los patrones de puerta de enlace descritos en este documento te ayudan a resolver este problema: ¿cómo puedes obtener tráfico en tu malla?

En este documento, se ofrece lo siguiente:

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

Consideraciones para tu puerta de enlace

En esta sección, se proporciona una descripción general de los problemas que debes considerar cuando seleccionas una puerta de enlace:

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

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

Los clientes, ya sea en la Internet pública, en tu entorno local o dentro de Google Cloud, necesitan una forma de acceder a un servicio dentro de tu malla. Por lo general, esto se logra mediante una dirección IP y un puerto enrutables de forma pública o privada que se resuelvan en una puerta de enlace. Los clientes fuera de tu malla usan esta dirección IP y este puerto para enviar solicitudes a los servicios en tu 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 tu malla. Las preguntas principales que debes considerar cuando eliges un balanceador de cargas de Google Cloud que funcione como tu 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?

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

Cómo administrar el tráfico en la puerta de enlace

Debido a que tu puerta de enlace se encuentra en el extremo de tu malla, entre los clientes que están fuera de ella y los servicios que están dentro de ella, la puerta de enlace es un lugar natural para aplicar políticas a medida que el tráfico ingresa a tu malla. Entre estas políticas se incluyen las siguientes:

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

Elegir una puerta de enlace para tu malla destaca las políticas que son relevantes en el extremo de tu malla.

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

Después de que tu puerta de enlace aplica políticas al tráfico entrante, decide a dónde enviar el tráfico. Puedes configurar esto mediante políticas de administración de tráfico y de balanceo de cargas. Por ejemplo, la puerta de enlace puede inspeccionar el encabezado de la solicitud para identificar el servicio de malla que debería recibir el tráfico. Una vez que la puerta de enlace identifica el servicio, distribuye el tráfico a un backend específico según una política de balanceo de cargas.

Elegir una puerta de enlace para tu malla describe los backends a los que una puerta de enlace puede enviar tráfico.

Elige una puerta de enlace para tu malla

Google Cloud ofrece una amplia gama de balanceadores de cargas que pueden actuar como la puerta de enlace de tu malla. En esta sección, se analiza la selección de una puerta de enlace y se comparan las siguientes opciones en las dimensiones relevantes para el patrón de puerta de enlace:

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

Es posible que solo necesites un nivel, es decir, un solo balanceador de cargas que actúe como la puerta de enlace de la malla. Sin embargo, a veces, es adecuado tener varias puertas de enlace. En estas configuraciones, una puerta de enlace maneja el tráfico que ingresa a Google Cloud y una puerta de enlace de segundo nivel maneja el tráfico a medida que ingresa a la malla de servicios. Por ejemplo, es posible que desees aplicar las políticas de seguridad de Google Cloud Armor al tráfico que ingresa a Google Cloud y las políticas avanzadas de administración de tráfico al tráfico que ingresa a la malla. El patrón que consiste en usar una segunda puerta de enlace configurada por Traffic Director se analiza en Implementa una puerta de enlace de segundo nivel en el extremo de tu malla.

En la siguiente tabla, se comparan las capacidades disponibles, en función de la opción de puerta de enlace que selecciones:

Puerta de enlace Ubicación del cliente Protocolos Policies Backends / extremos
Balanceo de cargas HTTP(S) interno Clientes basados en Google Cloud en la misma región que el balanceador de cargas

Clientes en la instalación local 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 de tráfico
Rescisión de TLS mediante certificados autoadministrados
Backends en la misma región de Google Cloud que el balanceador de cargas, que se ejecuta en las siguientes ubicaciones:

Backends de máquinas virtuales en Compute Engine

Instancias de contenedores en las siguientes ubicaciones:
  • Google Kubernetes Engine (GKE)
  • Kubernetes
Balanceo de cargas HTTP(S) Clientes en la Internet pública
  • HTTP/1.1
  • HTTP/2
  • HTTPS
  • Administración del tráfico
  • Cloud CDN (incluidos los backends del depósito de Cloud Storage)
  • Rescisió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 con IAP para la autenticación de usuarios
Backends en cualquier región de Google Cloud, que se ejecutan en las siguientes ubicaciones:

Máquinas virtuales en Compute Engine

Instancias de contenedores en las siguientes ubicaciones:
  • Google Kubernetes Engine (GKE)
  • Kubernetes
Balanceo de cargas TCP/UDP 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 la del balanceador de cargas.

Clientes en la instalación local 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 ejecuta en las siguientes ubicaciones:

Máquinas virtuales en Compute Engine
Balanceo de cargas de red Clientes en la Internet pública Una de las opciones de TCP o UDP Backends en la misma región de Google Cloud que el balanceador de cargas, que se ejecuta en las siguientes ubicaciones:

Máquinas virtuales en Compute Engine
Balanceo de cargas del proxy SSL y balanceo de cargas del proxy TCP Clientes en la Internet pública Una de las opciones de SSL o TCP Rescisión de TLS mediante certificados autoadministrados o administrados de Google (solo proxy SSL)

Políticas de SSL (solo proxy SSL)
Backends en cualquier región de Google Cloud, que se ejecutan en las siguientes ubicaciones:

Máquinas virtuales en Compute Engine

Instancias de contenedores en las siguientes ubicaciones:
  • Google Kubernetes Engine (GKE)
  • Kubernetes
Proxy perimetral (en instancias de VM o de contenedores) configurado por Traffic Director Los clientes deben estar 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 Implementa una puerta de enlace de segundo nivel en el extremo de tu malla en este documento.
  • 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 VM o de contenedor que ejecuta el proxy perimetral.
  • HTTP/1.1
  • HTTP/2
Administración avanzada de tráfico (incluye compatibilidad con regex) Backends en cualquier región de Google Cloud, que se ejecutan en las siguientes ubicaciones:

Máquinas virtuales en Compute Engine

Instancias de contenedores en las siguientes ubicaciones:
  • Google Kubernetes Engine (GKE)
  • Kubernetes

En la página de funciones del balanceador de cargas, se proporciona una comparación detallada de cada función. En las páginas de funciones de Traffic Director, se proporciona una descripción general detallada de las funciones de Traffic Director.

Implementa y configura puertas de enlace

Una última consideración para seleccionar tu puerta de enlace es la experiencia del desarrollador y las herramientas que deseas usar. Google Cloud ofrece varios enfoques para crear y administrar tu puerta de enlace.

Herramienta de línea de comandos de gcloud y API de Compute Engine

Puedes usar la herramienta de línea de comandos de gcloud y las API de Compute Engine para configurar Traffic Director y los productos de balanceo de cargas administrados de Google Cloud. La CLI y las API proporcionan mecanismos para implementar y configurar tus recursos de Google Cloud de forma obligatoria. Puedes crear secuencias de comandos para automatizar tareas repetitivas.

Google Cloud Console

Puedes usar Google Cloud Cloud Console, una interfaz gráfica para configurar Traffic Director y los balanceadores de cargas administrados de Google Cloud. Para configurar el patrón de tu puerta de enlace, es probable que necesites la interfaz de usuario de Cloud Load Balancing y la interfaz de usuario de Traffic Director.

GKE e Ingress for Anthos

Los controladores de red de GKE y Anthos también admiten la implementación de Cloud Load Balancing para la integración nativa con herramientas de redes de contenedores. Proporcionan una interfaz declarativa de estilo Kubernetes para implementar y configurar puertas de enlace. Los controladores de entrada de GKE y entrada de Anthos administran los balanceadores de cargas internos y externos para enviar tráfico a un solo clúster o a varios clústeres de GKE. El recurso de entrada también se puede configurar para apuntar a los servicios configurados por Traffic Director que se implementan en clústeres de GKE.

Patrones de arquitectura de puerta de enlace

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

Patrones

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

  1. Los clientes envían tráfico a un balanceador de cargas administrado por Google Cloud que actúa como tu puerta de enlace.
    • La puerta de enlace aplica políticas.
  2. La puerta de enlace envía el tráfico a un servicio en tu malla.

Un patrón más avanzado involucra 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 tu 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 por Traffic Director.
    • Este proxy perimetral actúa como una puerta de enlace de segundo nivel. Este nivel realiza lo siguiente:
      1. Proporciona una separación clara de los asuntos en los que, por ejemplo, un equipo puede ser responsable del tráfico de entrada a Google Cloud, mientras que otro equipo es responsable del tráfico de entrada a la malla de ese equipo.
      2. 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 tu malla.

El patrón de entrada finaliza una vez que el tráfico llega a un servicio en la malla. El caso común y los patrones avanzados se describen a continuación.

Habilita el tráfico de entrada desde Internet

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

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

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)
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 tu puerta de enlace. La puerta de enlace maneja el tráfico de entrada antes de reenviarlo a un servicio en tu malla.

Por ejemplo, puedes elegir el Balanceo de cargas HTTP(S) como tu puerta de enlace para usar lo siguiente:

  • Una dirección IP Anycast global y enrutable de forma pública, que minimiza la latencia y los costos de recorrido de red
  • Google Cloud Armor y la rescisión de TLS para asegurar el tráfico de tu malla
  • Cloud CDN para entregar contenido web y de video
  • Funciones de administración de tráfico, como el enrutamiento basado en el host y la ruta

Habilita el tráfico de entrada de clientes en la nube privada virtual y las redes locales conectadas

Si tus clientes están dentro de tu red de VPC o en la instalación local 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 tu puerta de enlace.

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

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)
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 tu puerta de enlace. La puerta de enlace maneja el tráfico de entrada antes de reenviarlo a un servicio en tu malla.

Por ejemplo, puedes elegir el Balanceo de cargas HTTP(S) interno como tu puerta de enlace para que puedas usar estas funciones:

  • Una dirección IP de acceso privado
  • La rescisión de TLS para asegurar tu malla
  • Funciones avanzadas de administración de tráfico, como la división del tráfico basada en el peso
  • NEG como backends

Controla el tráfico de entrada mediante una puerta de enlace de segundo nivel en el extremo de tu 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 (haz clic para ampliar)
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 un grupo de proxies) configurado por 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 tu proyecto mediante un grupo de VM de Compute Engine (un MIG) 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 el balanceo de cargas HTTP(S).

  • El proxy perimetral configurado por Traffic Director aplica un segundo conjunto de políticas que podrían no estar disponibles en el balanceador de cargas administrado por Google Cloud. Estas políticas incluyen la administración avanzada de tráfico mediante expresiones regulares aplicadas a encabezados HTTP y la división de tráfico basada en 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 posee su propio proyecto de servicio, los equipos pueden usar este patrón para administrar y aplicar políticas en sus propias mallas. Cada equipo puede exponer una puerta de enlace configurada por Traffic Director a la que se puede acceder en un único par de dirección IP y puerto. Luego, un equipo puede definir y administrar de forma independiente las políticas que se aplican al tráfico de entrada de la malla del equipo.

Ten en cuenta que 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 por Traffic Director. Consulta Elige una puerta de enlace para tu malla a fin de obtener información sobre los backends compatibles con cada balanceador de cargas.