Del perímetro a la malla de varios clústeres: Aplicaciones distribuidas globalmente expuestas a través de la puerta de enlace de GKE y Cloud Service Mesh

Last reviewed 2024-06-30 UTC

En esta arquitectura de referencia, se describen los beneficios de exponer las aplicaciones de forma externa a través de las puertas de enlace de Google Kubernetes Engine (GKE) que se ejecutan en varios clústeres de GKE dentro de una malla de servicios. Esta guía está dirigida a los administradores de la plataforma.

Puedes aumentar la resiliencia y la redundancia de tus servicios si implementas las aplicaciones de manera coherente en varios clústeres de GKE, en los que cada clúster se convierte en un dominio con fallas adicional. Por ejemplo, una infraestructura de procesamiento de un servicio con un objetivo de nivel de servicio (SLO) del 99.9% cuando se implementa en un solo clúster de GKE alcanza un SLO del 99.9999% cuando se implementa en dos clústeres de GKE (1 − (0.001)2). También puedes proporcionar a los usuarios una experiencia en la que las solicitudes entrantes se dirijan de forma automática a la puerta de enlace de entrada de malla menos latente y disponible.

Si te interesan los beneficios de exponer las aplicaciones habilitadas para la malla de servicios que se ejecutan en un solo clúster, consulta Del perímetro a la malla: Exposición de aplicaciones de la malla de servicios a través de GKE Gateway.

Arquitectura

En el siguiente diagrama de arquitectura, se muestra cómo fluyen los datos a través de la entrada de la nube y la de la malla:

Encriptación TLS del cliente, un balanceador de cargas y la malla

En el diagrama anterior, se muestran las siguientes situaciones de flujo de datos:

  • Desde el cliente que termina en el balanceador de cargas Google Cloud con su propio certificado TLS administrado por Google
  • Desde el balanceador de cargas Google Cloud hasta el proxy de entrada de la malla con su propio certificado TLS autofirmado
  • Desde el proxy de puerta de enlace de entrada de la malla a los proxies de sidecar de la carga de trabajo mediante mTLS habilitada para la malla de servicios

Esta arquitectura de referencia contiene las siguientes dos capas de entrada:

  • Entrada de la nube: en esta arquitectura de referencia, debes usar la API de Gateway de Kubernetes (y el controlador de GKE Gateway) para programar la capa de balanceo de cargas de HTTP(S) externa de varios clústeres. El balanceador de cargas verifica los proxies de entrada de la malla en varias regiones y envía solicitudes al clúster en buen estado más cercano. También implementa una política de seguridad de Google Cloud Armor.
  • Entrada de la malla: en 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.

Cuando se usan las capas de entrada juntas, existen roles complementarios para cada capa. Para lograr los siguientes objetivos, Google Cloud optimiza los atributos más adecuados de la capa de entrada de la nube y de la capa de entrada de la malla:

  • Proporciona una latencia baja
  • Aumenta la disponibilidad.
  • Usa las funciones de seguridad de la capa de entrada de la nube.
  • Usa las funciones de seguridad, autorización y observabilidad de la capa de entrada de la malla.

Entrada de la nube

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 los siguientes servicios, se destaca en la ejecución de esos servicios en el perímetro, fuera de la malla:

  • Protección contra DDoS
  • Firewalls de Cloud
  • Autenticación y autorización
  • Encriptación

La lógica de enrutamiento suele ser sencilla en la capa de entrada de la nube. Sin embargo, puede ser más complejo en entornos multirregionales y de varios clústeres.

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 plataforma que tenga un control exclusivo sobre cómo se exponen y protegen las aplicaciones en Internet. Este control hace que esta capa sea menos flexible y dinámica que una infraestructura basada en el desarrollador. Ten en cuenta estos factores cuando determines los derechos de acceso de administrador a esta capa y cómo proporcionar ese acceso.

Entrada de la malla

Cuando se sincroniza con la entrada de la nube, la capa de entrada de la malla proporciona un punto de entrada para que el tráfico ingrese a la malla de servicios. La capa también proporciona mTLS de backend, políticas de autorización y coincidencia flexible de regex.

Implementar el balanceo de cargas de aplicaciones externo fuera de la malla con una capa de entrada de la malla ofrece ventajas significativas, en especial para la administración del tráfico de Internet. Aunque la malla de servicios y las puertas de enlace de entrada 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 deGoogle Cloudpuede proporcionar beneficios significativos de rendimiento, confiabilidad o seguridad en la entrada basada en la malla.

Productos y funciones que se usan

En la siguiente lista, se resumen todos los productos y las funciones de Google Cloud que usa esta arquitectura de referencia:

  • GKE Enterprise: Un servicio de Kubernetes administrado que puedes usar para implementar y operar aplicaciones alojadas en contenedores a gran escala en la infraestructura de Google Para los fines de esta arquitectura de referencia, cada uno de los clústeres de GKE que entregan una aplicación debe estar en la misma flota.
  • Flotas y Gateways de varios clústeres: Servicios que se usan para crear aplicaciones en contenedores a escala empresarial con la infraestructura de Google y GKE Enterprise.
  • Google Cloud Armor: Un servicio que te ayuda a proteger tus aplicaciones y sitios web contra ataques web y de denegación del servicio.
  • Cloud Service Mesh: una malla de servicios completamente administrada basada en Istio y Envoy
  • Balanceador de cargas de aplicaciones: Un balanceador de cargas L7 basado en proxy que te permite ejecutar y escalar tus servicios
  • Administrador de certificados: Un servicio que te permite adquirir y administrar certificados TLS para usar con Cloud Load Balancing.

Flotas

Para administrar implementaciones de varios clústeres, GKE Enterprise Google Cloud y usa flotas a fin de agrupar y normalizar los clústeres de Kubernetes de forma lógica.

El uso de una o más flotas puede ayudarte a mejorar la administración de clústeres individuales a grupos completos de clústeres. Para reducir la fricción en la administración de clústeres, usa el principio de similitud de espacio de nombres. Para cada clúster de GKE de una flota, asegúrate de configurar todas las puertas de enlace de entrada de la malla de la misma manera.

Además, implementa de forma coherente los servicios de la aplicación para que el lector del saldo de servicios en la cuenta del espacio de nombres se relacione con un servicio idéntico en cada clúster de GKE de la flota. Los principios de similitud y confianza que se suponen dentro de una flota son lo que te permiten usar la gama completa de funciones habilitadas para flota en GKE Enterprise y Google Cloud.

Las reglas de enrutamiento este-oeste dentro de la malla de servicios y las políticas de tráfico se controlan en la capa de entrada de la malla. La capa de entrada de la malla se implementa en cada clúster de GKE de la flota. Configura cada puerta de enlace de entrada de la malla de la misma manera y cumple con el principio de similitud de espacio de nombres de la flota.

Aunque hay un solo clúster de configuración para GKE Gateway, debes sincronizar tus opciones de configuración de GKE Gateway en todos los clústeres de GKE de la flota.

Si necesitas nominar un clúster de configuración nuevo, usa ConfigSync. ConfigSync ayuda a garantizar que todas esas configuraciones se sincronicen en todos los clústeres de GKE de la flota y ayuda a evitar la conciliación con una configuración no actual.

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 el tráfico externo, necesitas un balanceador de cargas externo a la malla. Para automatizar la implementación, esta arquitectura de referencia usa Cloud Load Balancing, que se aprovisiona a través de recursos de puerta de enlace de GKE.

Servicios de GKE Gateway y de varios clústeres

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

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

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:

  • Si los servicios de backend están en un solo clúster de GKE o distribuidos en varios clústeres de GKE (en la misma flota).
  • 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 Gateway, este comportamiento se controla mediante la especificación de la GatewayClass adecuada. Cuando se hace referencia a las clases de puerta de enlace, esas clases que se pueden usar en situaciones de varios clústeres tienen un nombre de clase que termina en -mc.

En esta arquitectura de referencia, se analiza cómo exponer los servicios de la aplicación de forma externa a través de un balanceador de cargas de aplicaciones externo. Sin embargo, cuando usas Gateway, también puedes crear un balanceador de cargas de aplicaciones interno regional de varios clústeres.

Para implementar servicios de aplicaciones en situaciones de varios clústeres, puedes definir los componentes del balanceador de cargasGoogle Cloud de las siguientes dos maneras:

Si deseas obtener más información sobre estos dos enfoques para implementar servicios de aplicaciones, consulta Elige tu API de balanceo de cargas de varios clústeres para GKE.

Ingress de varios clústeres se basa en la creación de recursos MultiClusterService. La puerta de enlace de varios clústeres se basa en la creación de recursos ServiceExport y en hacer referencia a los recursos ServiceImport.

Cuando usas una puerta de enlace de varios clústeres, puedes habilitar las capacidades adicionales del balanceador de cargas Google Cloud subyacente mediante la creación de políticas. En la guía de implementación asociada con esta arquitectura de referencia, se muestra cómo configurar una política de seguridad de Google Cloud Armor para proteger los servicios de backend de las secuencias de comandos entre sitios.

Estos recursos de políticas se orientan a los servicios de backend de la flota que están expuestos en varios clústeres. En situaciones de varios clústeres, todas esas políticas deben hacer referencia al recurso ServiceImport y grupo de API.

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

  • Entrada de la nube: En esta arquitectura de referencia, debes configurar el balanceador de cargasGoogle Cloud a través de la puerta de enlace de GKE 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 malla está inactivo o si el clúster, la malla o la región no están disponibles, el balanceador de cargas Google Cloud detecta esta condición y no envía tráfico al proxy de la malla. En este caso, el tráfico se enrutaría a un proxy de malla alternativo en un clúster o una región de GKE diferente.
  • Entrada de la malla: 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.

Consideraciones del diseño

En esta sección, se proporciona orientación para ayudarte a usar esta arquitectura de referencia a fin de desarrollar una arquitectura que cumpla con tus requisitos específicos de seguridad, cumplimiento, confiabilidad y costo.

Security, privacy, and compliance

El diagrama de arquitectura en este documento contiene varios elementos de seguridad. Los elementos más importantes son la forma en que configuras la encriptación y, luego, implementas los certificados. La puerta de enlace de GKE se integra en el Administrador de certificados para estos fines de seguridad.

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). Puedes hacer referencia a un Administrador de certificados CertificateMap en tu definición de puerta de enlace. El siguiente salto se encuentra entre Google Front End (GFE) y el proxy de entrada de la malla. Ese salto 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 entre la puerta de enlace del clúster y la entrada de la malla, puedes usar un certificado autofirmado o público para encriptar el tráfico. Puedes usar un certificado autofirmado o público porque el GFE no se autentica en él. Esta capa adicional de encriptación se demuestra en la guía de implementación asociada con esta arquitectura de referencia.

Para evitar el manejo inadecuado de certificados, no vuelvas a usar los certificados públicos. Usa certificados independientes para cada balanceador de cargas en la malla de servicios.

Para ayudar a crear entradas de DNS externo y certificados TLS, la guía de implementación de esta arquitectura de referencia usa Cloud Endpoints. El uso de Cloud Endpoints te permite crear un subdominio cloud.goog disponible de manera externa. En situaciones de nivel empresarial, usa un nombre de dominio más apropiado y crea un registro A que apunte a la dirección IP del balanceador de cargas de aplicaciones global en tu proveedor de servicios de DNS.

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

Confiabilidad y resiliencia

Una ventaja clave del patrón de perímetro a malla multirregional y de varios clústeres es que puede usar todas las funciones de la malla de servicios para el balanceo de cargas de este a oeste, como el tráfico entre los servicios de aplicaciones.

En esta arquitectura de referencia, se usa una puerta de enlace de GKE de varios clústeres para enrutar el tráfico entrante de la nube a un clúster de GKE. El sistema selecciona un clúster de GKE según su proximidad con el usuario (en función de la latencia) y su disponibilidad y estado. Cuando el tráfico llega a la puerta de enlace de entrada de Istio (la entrada de la malla), se enruta a los backends adecuados a través de la malla de servicios.

Un enfoque alternativo para controlar el tráfico de este a oeste es mediante servicios de varios clústeres para todos los servicios de aplicaciones implementados en los clústeres de GKE. Cuando se usan servicios de varios clústeres en los clústeres de GKE en una flota, los extremos del servicio se recopilan en una ClusterSet. Si un servicio necesita llamar a otro, puede orientarse a cualquier extremo en buen estado para el segundo servicio. Debido a que los extremos se eligen en función de una rotación, el extremo seleccionado podría estar en una zona o región diferente.

Una ventaja clave de usar la malla de servicios para el tráfico de este a oeste en lugar de los servicios de varios clústeres es que la malla de servicios puede usar el balanceo de cargas de localidad. El balanceo de cargas de localidad no es una función de los servicios de varios clústeres, pero puedes configurarlo a través de un DestinationRule.

Una vez configurada, una llamada de un servicio a otro primero intenta alcanzar un extremo de servicio en la misma zona y, luego, intenta en la misma región que el servicio que realiza la llamada. Por último, la llamada solo se orienta a un extremo de otra región si un extremo de servicio en la misma zona o región no está disponible.

Optimización de costos

Cuando se adopta esta arquitectura de varios clústeres de forma amplia en una empresa, Cloud Service Mesh y la puerta de enlace de varios clústeres se incluyen en Google Kubernetes Engine (GKE) Enterprise Edition. Además, GKE Enterprise incluye muchas funciones que te permiten administrar y controlar clústeres de GKE, aplicaciones y otros procesos a gran escala.

Implementación

Para implementar esta arquitectura, consulta Del perímetro a la malla de varios clústeres: Implementa aplicaciones distribuidas de forma global a través de GKE Gateway y Cloud Service Mesh.

¿Qué sigue?

Colaboradores

Autores:

Otros colaboradores: