Del perímetro a la malla: exponer aplicaciones en una malla de servicios a través de GKE Gateway

Last reviewed 2023-10-24 UTC

Esta arquitectura de referencia muestra cómo combinar Cloud Service Mesh con Cloud Load Balancing para exponer aplicaciones en una malla de servicios a clientes de Internet.

Cloud Service Mesh es una malla de servicios gestionada basada en Istio que proporciona una capa de comunicación segura, observable y estandarizada para las aplicaciones. Una malla de servicios proporciona una plataforma de comunicaciones integral para los clientes que se comunican en la malla. Sin embargo, sigue siendo un reto conectar clientes que están fuera de la malla con aplicaciones alojadas dentro de la malla.

Puedes exponer una aplicación a los clientes de muchas formas, en función de dónde se encuentre el cliente. Esta arquitectura de referencia está pensada para usuarios avanzados que ejecutan Cloud Service Mesh, pero también funciona con Istio en Google Kubernetes Engine (GKE).

Pasarela de entrada de malla

Istio 0.8 introdujo la pasarela de entrada de la malla. La pasarela proporciona un conjunto específico de proxies cuyos puertos están expuestos al tráfico procedente de fuera de la malla de servicios. Estos proxies de entrada de malla te permiten controlar el comportamiento de exposición de la red por separado del comportamiento de enrutamiento de la aplicación.

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

Para gestionar este tráfico externo, necesitas un balanceador de carga que sea externo a la malla. Esta arquitectura de referencia usa Google Cloud Load Balancing aprovisionado a través de recursos de GKE Gateway para automatizar el despliegue.

Por ejemplo, Google Cloudel ejemplo canónico de esta configuración es un servicio de balanceo de carga externo que despliega un balanceador de carga de red público (L4). Ese balanceador de carga apunta a los NodePorts de un clúster de GKE. Estos NodePorts exponen los pods de la pasarela de entrada de Istio, que enrutan el tráfico a los proxies sidecar de la malla.

Arquitectura

En el siguiente diagrama se muestra esta topología. El balanceo de carga del tráfico privado interno es similar a esta arquitectura, excepto que se implementa un balanceador de carga de red de paso a través interno.

Un balanceador de carga externo dirige los clientes externos a la malla a través de proxies de la pasarela de entrada.

En el diagrama anterior se muestra que el uso del balanceo de carga transparente de nivel 4 con una puerta de enlace de entrada de malla ofrece las siguientes ventajas:

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

GKE Gateway y Services

Puedes proporcionar acceso a las aplicaciones a los clientes que estén fuera del clúster de muchas formas. GKE Gateway es una implementación de la API Gateway de Kubernetes. GKE Gateway evoluciona el recurso Ingress y lo mejora.

Cuando implementas recursos de GKE Gateway en tu clúster de GKE, el controlador de Gateway monitoriza los recursos de la API Gateway y reconcilia los recursos de Cloud Load Balancing para implementar el comportamiento de red especificado por los recursos de GKE Gateway.

Cuando se usa GKE Gateway, el tipo de balanceador de carga que se utiliza para exponer aplicaciones a los clientes depende en gran medida de los siguientes factores:

  • El estado de los clientes (externo o interno).
  • Las funciones necesarias del balanceador de carga, incluida la función de integración con las políticas de seguridad de Google Cloud Armor.
  • Los requisitos de cobertura de la malla de servicios. Las mallas de servicios pueden abarcar varios clústeres de GKE o estar contenidas en un solo clúster.

En GKE Gateway, este comportamiento se controla especificando la GatewayClass adecuada.

Aunque el balanceador de carga predeterminado de Cloud Service Mesh es el balanceador de carga de red, esta arquitectura de referencia se centra en el balanceador de carga de aplicaciones externo (L7). El balanceador de carga de aplicaciones externo se integra con servicios perimetrales como Identity-Aware Proxy y Google Cloud Armor, redirecciones y reescrituras de URLs, así como una red distribuida globalmente de proxies perimetrales. En la siguiente sección se describe la arquitectura y las ventajas de usar dos capas de balanceo de carga HTTP.

Ingreso en la nube e ingreso en la malla

Implementar el balanceo de carga externo de nivel 7 fuera de la malla junto con una capa de entrada de la malla ofrece ventajas significativas, especialmente para el tráfico de Internet. Aunque las pasarelas de entrada de Cloud Service Mesh e Istio proporcionan en la malla funciones avanzadas de enrutamiento y gestión del tráfico, algunas funciones se gestionan mejor en el perímetro de la red. Aprovechar las ventajas de las redes perimetrales de Internet mediante el balanceador de carga de aplicaciones externo deGoogle Cloudpuede ofrecer mejoras significativas en el rendimiento, la fiabilidad o la seguridad en comparación con el acceso de entrada basado en malla. Entre estas ventajas se incluyen las siguientes:

Esta capa externa de balanceo de carga de nivel 7 se denomina entrada de nube porque se basa en balanceadores de carga gestionados en la nube en lugar de en los proxies autohospedados que usa la entrada de malla. La combinación de entrada de nube y entrada de malla usa las funciones complementarias de la infraestructura Google Cloud y la malla. En el siguiente diagrama se muestra cómo puedes combinar el acceso de nube (a través de la puerta de enlace de GKE) y el acceso de malla para que actúen como dos capas de balanceo de carga para el tráfico de Internet.

El tráfico de entrada de Cloud actúa como pasarela para el tráfico externo a la malla a través de la red VPC.

En la topología del diagrama anterior, la capa de entrada en la nube obtiene el tráfico de fuera de la malla de servicios y lo dirige a la capa de entrada en la malla. A continuación, la capa de entrada de la malla dirige el tráfico a los backends de la aplicación alojada en la malla.

Topología de entrada de malla y en la nube

En esta sección se describen los roles complementarios que cumple cada capa de entrada cuando se usan juntas. Estos roles no son reglas concretas, sino directrices que aprovechan las ventajas de cada capa. Es probable que haya variaciones de este patrón, en función de tu caso de uso.

  • Ingreso en la nube: cuando se combina con el ingreso de malla, la capa de ingreso en la nube se usa mejor para la seguridad perimetral y el balanceo de carga global. Como la capa de entrada de la nube está integrada con la protección frente a DDoS, los cortafuegos de la nube, la autenticación y los productos de cifrado en el perímetro, esta capa destaca por ejecutar estos servicios fuera de la malla. La lógica de enrutamiento suele ser sencilla en esta capa, pero puede ser más compleja en entornos multiclúster y multirregión. Debido a la función crítica de los balanceadores de carga orientados a Internet, es probable que el equipo de infraestructura gestione la capa de entrada de la nube, que tiene el 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, lo que podría influir en quién y cómo proporcionas acceso administrativo a esta capa.
  • Ingreso de malla: cuando se combina con el ingreso de nube, la capa de ingreso de malla proporciona un enrutamiento flexible que está cerca de la aplicación. Gracias a esta flexibilidad, el ingreso de malla es mejor que el ingreso de nube para la lógica de enrutamiento compleja y la visibilidad a nivel de aplicación. La separación entre las capas de entrada también facilita que los propietarios de las aplicaciones controlen directamente esta capa sin que afecte a otros equipos. Para proteger las aplicaciones, cuando expongas aplicaciones de malla de servicios a través de un balanceador de carga de nivel 4 en lugar de un balanceador de carga de nivel 7, debes finalizar el protocolo TLS del cliente en la capa de entrada de la malla.

Comprobaciones del estado

Una de las complejidades de usar dos capas de balanceo de carga de capa 7 es la comprobación del estado. Debe configurar cada balanceador de carga para que compruebe el estado de la capa siguiente y así asegurarse de que puede recibir tráfico. La topología del siguiente diagrama muestra cómo la entrada de nube comprueba el estado de los proxies de entrada de la malla y cómo la malla, a su vez, comprueba el estado de los backends de la aplicación.

El ingreso de Cloud comprueba el estado del ingreso de la malla y el ingreso de la malla comprueba el estado de los backends de la aplicación.

La topología anterior tiene las siguientes consideraciones:

  • Entrada en la nube: en esta arquitectura de referencia, se configura el Google Cloud balanceador de carga a través de la puerta de enlace para comprobar el estado de los proxies de entrada de la malla en sus puertos de comprobación del estado expuestos. Si un proxy de malla no funciona o si el clúster, la malla o la región no están disponibles, el Google Cloud balanceador de carga detecta esta situación y no envía tráfico al proxy de malla.
  • Ingreso de malla: en la aplicación de malla, realizas comprobaciones de estado en los backends directamente para poder ejecutar el balanceo de carga y la gestión del tráfico de forma local.

Seguridad

La topología anterior también implica varios elementos de seguridad. Uno de los elementos más importantes es la forma en que configuras el cifrado e implementas los certificados. GKE Gateway se integra con los certificados gestionados por Google. Puedes hacer referencia a un gestor de certificados CertificateMap en tu definición de Gateway. Los clientes de Internet se autentican con los certificados públicos y se conectan al balanceador de carga externo como primer salto en la nube privada virtual (VPC).

El siguiente salto, que se produce entre el frontend de Google (GFE) y el proxy de entrada de la malla, está cifrado de forma predeterminada. El encriptado a nivel de red entre los GFEs y sus backends se aplica automáticamente. Sin embargo, si tus requisitos de seguridad exigen que el propietario de la plataforma conserve la propiedad de las claves de cifrado, puedes habilitar HTTP/2 con cifrado TLS entre la pasarela del clúster (GFE) y el ingreso de la malla (la instancia de proxy de Envoy). Cuando habilitas HTTP/2 con cifrado TLS para esta ruta, puedes usar un certificado público o autofirmado para cifrar el tráfico, ya que el GFE no se autentica con él. Esta capa de cifrado adicional se muestra en la guía de implementación asociada. Para evitar que se haga un uso inadecuado de los certificados, no utilice el certificado público del balanceador de carga público en ningún otro lugar. En su lugar, te recomendamos que uses certificados independientes en la malla de servicios.

Si la malla de servicios exige TLS, todo el tráfico se cifra entre los proxies sidecar y el acceso de la malla. En el siguiente diagrama se ilustra el cifrado HTTPS desde el cliente hasta el balanceador de carga Google Cloud , desde el balanceador de carga hasta el proxy de entrada de la malla y desde el proxy de entrada hasta el proxy sidecar.

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

Optimización de costes

En este documento, se usan los siguientes componentes facturables de Google Cloud:

Implementación

Para desplegar esta arquitectura, consulta Del perímetro a la malla: desplegar aplicaciones en una malla de servicios a través de la pasarela de GKE.

Siguientes pasos