Tráfico de entrada para la malla

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

Además, se describe cómo usar Cloud Load Balancing como puerta de enlace para dirigir el tráfico a la malla.

Descripción general

Cuando diseñes la malla de servicios, debes considerar el tráfico que proviene de estas 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 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. Para que el servicio A se comunique con el servicio B, debe ocurrir 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.
Tráfico interno de la malla de servicios que controla el plano de datos de malla de servicios (haz clic para ampliar)
El plano de datos de la malla controla el tráfico interno a 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 extiende 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 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 envía solicitudes salientes mediante un proxy configurado con Traffic Director, no sabe qué pares dirección IP-puerto 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.

Los patrones de la puerta de enlace descritos en este documento te serán de ayuda para resolver este problema: ¿cómo puedes dirigir el tráfico a la malla?

En este documento, se ofrece 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

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:

  • ¿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, esto se logra 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 esta dirección IP y 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?

Elegir una puerta de enlace para la 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.

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 a medida que 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 DSD de Google Cloud Armor)
  • Almacenamiento en caché de Cloud CDN

Elegir una puerta de enlace para la malla destaca las políticas que son relevantes en el perímetro de la malla.

Envía tráfico desde la puerta de enlace a 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. Esto se configura mediante la administración del tráfico y las políticas de balanceo de cargas. 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.

Elegir una puerta de enlace para la malla establece 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 primer nivel y de segundo nivel. 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 para usar una segunda puerta de enlace configurada con Traffic Director se analiza en Implementa 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
Balanceo de cargas de HTTP(S) 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 de 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 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 de HTTP(S) 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 IAP con 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 de 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 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 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 ejecutan en las siguientes ubicaciones:

Máquinas virtuales en Compute Engine
Balanceo de cargas del proxy SSL y del proxy TCP Clientes en la Internet pública Una de las opciones de 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 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) que configura Traffic Director Los clientes deben encontrarse en una ubicación en la que se aplique alguna 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 perímetro de la 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 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 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

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.

La herramienta de línea de comandos de gcloud y las API de Compute Engine

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

Google Cloud Console

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

Entrada de varios clústeres y GKE

Los controladores de red de Anthos y GKE también admiten la implementación de Cloud Load Balancing para la integración nativa con 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 Anthos 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.

Patrones

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 tiene las siguientes características:
      1. 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.
      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 la malla.

El patrón de entrada finaliza una vez que el tráfico llega a un servicio de malla. A continuación, 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.

Si deseas obtener más información que te ayude a elegir una puerta de enlace adecuada, consulta Elige una puerta de enlace para la 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 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 el Balanceo de cargas de HTTP(S) como la 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

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

Si deseas obtener más información que te ayude a elegir una puerta de enlace adecuada, consulta Elige una puerta de enlace para la 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 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 el Balanceo de cargas de HTTP(S) interno como la puerta de enlace para que puedas 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

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 (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 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 con un grupo de servicios de GKE o VM de Compute Engine (un MIG).

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 de HTTP(S).

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

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 con Traffic Director. Consulta Elige una puerta de enlace para la malla si deseas obtener información sobre los backends que admite cada balanceador de cargas. Para obtener información sobre el uso de Traffic Director con una VPC compartida, consulta Configura Traffic Director con una VPC compartida en varios clústeres de GKE.