Del perímetro a la malla: Exposición de aplicaciones de la malla de servicios a través de Ingress de GKE

Last reviewed 2023-10-24 UTC

En esta arquitectura de referencia, se muestra cómo combinar Anthos Service Mesh con Cloud Load Balancing para exponer aplicaciones en una malla de servicios a los clientes de Internet.

Anthos Service Mesh es una malla de servicios administrada, basada en Istio, que proporciona una capa de comunicación estandarizada, observable y más segura para aplicaciones. Una malla de servicios proporciona una plataforma de comunicación integral para clientes que se comunican en la malla. Sin embargo, conectar los clientes que están fuera de la malla a las aplicaciones alojadas en ella sigue siendo un desafío.

Puedes exponer una aplicación a los clientes de muchas maneras, según la ubicación en que estos se encuentren. Esta arquitectura de referencia está dirigida a profesionales avanzados que ejecutan Anthos Service Mesh, pero también funciona para Istio en Google Kubernetes Engine (GKE).

Puerta de enlace de entrada de la malla

En Istio 0.8, se agregó la puerta de enlace de entrada de la malla. La puerta de enlace proporciona un conjunto exclusivo de proxies cuyos puertos están expuestos al tráfico que proviene del exterior de la malla de servicios. Gracias a estos proxies de entrada de la malla, puedes controlar por separado el comportamiento de exposición de red y el comportamiento de enrutamiento de la aplicación.

Los proxies también te permiten aplicar enrutamiento y políticas al tráfico externo a la malla antes de que llegue a un proxy de sidecar de la aplicación. La entrada de la malla define el tratamiento del tráfico cuando llega a un nodo en la malla, pero los componentes externos deben definir cómo llega el tráfico primero a la malla.

Para administrar este tráfico externo, necesitas un balanceador de cargas externo a la malla. En esta arquitectura de referencia, se usa Google Cloud Load Balancing aprovisionado a través de recursos de puerta de enlace de GKE para automatizar la implementación.

Para Google Cloud, el ejemplo canónico de esta configuración es un servicio de balanceo de cargas externo que implementa un balanceador de cargas de red público (L4). Ese balanceador de cargas apunta a los NodePorts de un clúster de GKE. Estos NodePorts exponen los Pods de puerta de enlace de entrada de Istio, que enrutan el tráfico a los proxies de sidecar de la malla descendente.

Arquitectura

En el siguiente diagrama, se ilustra esta topología. El balanceo de cargas para el tráfico privado interno se parece a esta arquitectura, excepto que implementas un balanceador de cargas de red de transferencia interno en su lugar.

Un balanceador de cargas externo enruta los clientes externos a la malla a través de proxies de puerta de enlace de entrada.

En el diagrama anterior, se muestra que el uso del balanceo de cargas transparente de L4 con una puerta de enlace de entrada de la malla ofrece las siguientes ventajas:

  • La configuración simplifica la implementación del balanceador de cargas.
  • El balanceador de cargas proporciona una dirección IP virtual estable (VIP), verificación de estado y distribución de tráfico confiable cuando se producen cambios en el clúster, interrupciones del nodo o interrupciones de procesos.
  • Todas las reglas de enrutamiento, la terminación de TLS y la política de tráfico se manejan en una sola ubicación en la puerta de enlace de entrada de la malla.

Servicios y puerta de enlace de GKE

Puedes proporcionar acceso a las aplicaciones a los clientes que se encuentran fuera del clúster de muchas maneras. GKE Gateway es una implementación de la API de Gateway de Kubernetes. La puerta de enlace de GKE evoluciona el recurso Ingress y lo mejora.

A medida que implementas recursos de la puerta de enlace de GKE en tu clúster de GKE, el controlador de la puerta de enlace observa los recursos de la API de la puerta de enlace y concilia los recursos de Cloud Load Balancing para implementar el comportamiento de red especificado por los recursos de la puerta de enlace de GKE.

Cuando usas la puerta de enlace de GKE, el tipo de balanceador de cargas que usas para exponer aplicaciones a los clientes depende en gran medida de los siguientes factores:

  • El estado de los clientes (externos o internos).
  • Las capacidades necesarias del balanceador de cargas, incluida la capacidad de integrarse a las políticas de seguridad de Google Cloud Armor.
  • Los requisitos de intervalo de la malla de servicios. Las mallas de servicios pueden abarcar varios clústeres de GKE o pueden estar incluidas en un solo clúster.

En GKE Gateway, este comportamiento se controla mediante la especificación de la GatewayClass adecuada.

Aunque el balanceador de cargas predeterminado para Anthos Service Mesh es el balanceador de cargas de red, esta arquitectura de referencia se enfoca en el balanceador de cargas de aplicaciones externo (L7). El balanceador de cargas de aplicaciones externo proporciona integración en servicios perimetrales, como Identity-Aware Proxy y Google Cloud Armor, redireccionamientos y reescrituras de URL, así como una red distribuida global de proxies perimetrales. En la siguiente sección, se describe la arquitectura y las ventajas de usar dos capas de balanceo de cargas de HTTP.

Entrada de la nube y entrada de la malla

La implementación del balanceo de cargas de L7 externo fuera de la malla, junto con una capa de entrada de la malla, ofrece ventajas significativas, en especial para el tráfico de Internet. Aunque las puertas de enlace de entrada de Anthos Service Mesh y de Istio proporcionan enrutamiento avanzado y administración del tráfico en la malla, algunas funciones se entregan mejor en el perímetro de la red. Aprovechar las herramientas de redes del perímetro de Internet a través del balanceador de cargas de aplicaciones externo de Google Cloud puede proporcionar importantes beneficios de rendimiento, confiabilidad o seguridad en la entrada basada en la malla. Los beneficios son los siguientes:

Esta capa externa de balanceo de cargas de L7 se denomina entrada de la nube porque se compila en balanceadores de cargas administrados en la nube, y no en los proxies autoadministrados que usa la entrada de la malla. En la combinación de la entrada de la nube y de la malla, se usan funciones complementarias de la infraestructura de Google Cloud y la malla. En el siguiente diagrama, se muestra cómo puedes combinar la entrada de la nube (a través de la puerta de enlace de GKE) y la entrada de la malla a fin de que funcionen como dos capas de balanceo de cargas para el tráfico de Internet.

La entrada de la nube actúa como puerta de enlace para el tráfico externo que ingresa a la malla a través de la red de VPC.

En la topología del diagrama anterior, la capa de entrada de la nube origina el tráfico desde el exterior de la malla de servicios y lo dirige a la capa de entrada de la malla. Luego, la capa de entrada de la malla dirige el tráfico a los backends de aplicaciones alojadas en la malla.

Topología de la entrada de la nube y de la malla

En esta sección, se describen las funciones complementarias que cada capa de entrada cumple cuando se usan juntas. Estas funciones no son reglas concretas, sino lineamientos en los que se usan las ventajas de cada capa. Es probable que haya variaciones de este patrón, según tu caso de uso.

  • Cloud Ingress: Cuando se combina con la entrada de la malla, es más conveniente usar la capa de entrada de la nube para la seguridad perimetral y el balanceo de cargas global. Debido a que la capa de entrada de la nube está integrada en la protección contra DSD, los firewalls en la nube, la autenticación y los productos de encriptación en el perímetro, esta capa tiene un gran rendimiento en la ejecución de estos servicios fuera de la malla. La lógica de enrutamiento suele ser sencilla en esta capa, pero la lógica puede ser más compleja para entornos de varios clústeres y multirregionales. Debido a la función crítica de los balanceadores de cargas orientados a Internet, es probable que la capa de entrada de la nube se administre mediante un equipo de infraestructura que tenga un control exclusivo sobre cómo se exponen y protegen las aplicaciones en Internet. Este control también hace que esta capa sea menos flexible y dinámica que una infraestructura controlada por desarrolladores, una consideración que puede afectar a quién y cómo se proporciona acceso administrativo a esta capa.
  • Mesh Ingress: Cuando se combina con la entrada de la nube, la capa de entrada de la malla proporciona enrutamiento flexible cerca de la aplicación. Debido a esta flexibilidad, la entrada de la malla es mejor que la de la nube para una lógica de enrutamiento compleja y la visibilidad a nivel de la aplicación. La separación entre las capas de entrada también facilita a los propietarios de la aplicación el control directo de esta capa sin afectar a otros equipos. Para ayudar a proteger las aplicaciones cuando expones aplicaciones de la malla de servicios a través de un balanceador de cargas de L4 en lugar de un balanceador de cargas de L7, debes finalizar la TLS del cliente en la capa de entrada de la malla dentro de la malla.

Verificaciones de estado

Una dificultad del uso de dos capas de balanceo de cargas de L7 es la verificación de estado. Debes configurar cada balanceador de cargas para verificar el estado de la siguiente capa a fin de garantizar que pueda recibir tráfico. En la topología del siguiente diagrama, se muestra cómo la entrada de la nube verifica el estado de los proxies de entrada de la malla, y la malla, a su vez, verifica el estado de los backends de la aplicación.

La entrada de la nube verifica el estado de la entrada de la malla, y la entrada de la malla verifica el estado de los backends de la aplicación.

La topología anterior tiene las siguientes consideraciones:

  • Entrada de la nube: En esta arquitectura de referencia, debes configurar el balanceador de cargas de Google Cloud a través de la puerta de entrada para verificar el estado de los proxies de entrada de la malla en sus puertos de verificación de estado expuestos. Si un proxy de la malla no funciona o si el clúster, la malla o la región no están disponibles, el balanceador de cargas de Google Cloud detecta esta condición y no envía tráfico al proxy de la malla.
  • Mesh Ingress: En la aplicación de la malla, debes realizar verificaciones de estado directamente en los backends, de modo que puedas ejecutar el balanceo de cargas y la administración de tráfico de forma local.

Seguridad

En la topología anterior, también se incluyen varios elementos de seguridad. Uno de los elementos más importantes es la forma en que configuras la encriptación y la implementación de certificados. GKE Gateway se integra a certificados administrados por Google. Puedes hacer referencia a un Administrador de certificados CertificateMap en tu definición de puerta de enlace. Los clientes de Internet se autentican con los certificados públicos y se conectan al balanceador de cargas externo como el primer salto en la nube privada virtual (VPC).

El siguiente salto, que está entre Google Front End (GFE) y el proxy de entrada de la malla, está encriptado de forma predeterminada. La encriptación a nivel de la red entre GFE y sus backends se aplica de forma automática. Sin embargo, si tus requisitos de seguridad determinan que el propietario de la plataforma retiene la propiedad de las claves de encriptación, puedes habilitar HTTP/2 con encriptación TLS entre la puerta de entrada del clúster (GFE) y la entrada de la malla (la instancia del proxy de envoy). Cuando habilitas HTTP/2 con encriptación TLS para esta ruta, puedes usar un certificado autofirmado o público a fin de encriptar el tráfico, ya que GFE no se autentica con él. Esta capa adicional de encriptación se demuestra en la guía de implementación asociada. A fin de evitar el manejo inadecuado de certificados, no uses el certificado público para el balanceador de cargas público en otro lugar. En cambio, te recomendamos que uses otros certificados en la malla de servicios.

Si la malla de servicios exige TLS, todo el tráfico se encripta entre proxies de sidecar y la entrada de la malla. En el siguiente diagrama, se ilustra la encriptación HTTPS del cliente al balanceador de cargas de Google Cloud, del balanceador de cargas al proxy de entrada de la malla y del proxy de entrada al proxy de sidecar.

La seguridad se implementa mediante certificados administrados ubicados fuera de la malla y certificados internos dentro de la malla.

Optimización de costos

En este documento, usarás los siguientes componentes facturables de Google Cloud:

Deployment

Para implementar esta arquitectura, consulta Del perímetro a la malla: Implementa aplicaciones de la malla de servicios a través de la puerta de entrada de GKE.

¿Qué sigue?