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, puerta de enlace hace referencia a una solución o un patrón para controlar el tráfico que se dirige a un servicio en la malla. La puerta de enlace de Ingress de Istio es una implementación de este patrón. En este documento, puerta de enlace 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 los pasos de configuración preparatoria, consulta la sección 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, Cloud Service Mesh 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:
- El servicio A debe realizar una solicitud al servicio B por nombre.
- Esta solicitud se intercepta y redirecciona al proxy de sidecar del servicio A.
- Luego, el proxy de sidecar envía la solicitud a un extremo asociado con el servicio B.
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.
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 Cloud Service Mesh 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:
- Balanceador de cargas de aplicaciones interno
- Balanceador de cargas de aplicaciones externo
- Balanceador de cargas de red de transferencia interno
- Balanceador de cargas de red de transferencia externo
- Balanceador de cargas de red del proxy externo
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 de usar una segunda puerta de enlace configurada con Cloud Service Mesh 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:
|
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:
|
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:
|
Proxy perimetral (en instancias de VM o de contenedores) que configura Cloud Service Mesh |
Los clientes deben encontrarse en una ubicación en la que se aplique alguna de las siguientes opciones:
|
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:
|
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 Cloud Service Mesh, consulta la página Funciones de Cloud Service Mesh.
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 Cloud Service Mesh, puedes usar Google Cloud CLI y las APIs 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 Cloud Service Mesh 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 Cloud Service Mesh 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 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 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 Cloud Service Mesh 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:
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.
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:
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.
La puerta de enlace envía el tráfico a un proxy perimetral (o a un grupo de proxies perimetrales) configurado por la malla de servicios de Cloud. 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.
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:
- Balanceador de cargas de aplicaciones externo
- Balanceador de cargas de red de transferencia externo
- Balanceador de cargas de red del proxy externo
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 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
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.
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 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
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.
Esta puerta de enlace es un proxy perimetral (o grupo de proxies) configurado con Cloud Service Mesh 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 por Cloud Service Mesh 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:
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.
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 Cloud Service Mesh, 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 Cloud Service Mesh.
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?
- Para configurar una puerta de enlace de entrada, consulta Configuración de Cloud Service Mesh para una puerta de enlace de entrada.
- Para agrupar las VMs y los contenedores que ejecutan tu código como extremos de tus servicios, consulta Descubrimiento de servicios de Cloud Service Mesh.
- Para usar Cloud Service Mesh con una VPC compartida, consulta Configura una malla de servicios de varios clústeres.
- Para obtener más información sobre Cloud Service Mesh, consulta la descripción general de Cloud Service Mesh.