Del perímetro a la malla multiclúster: aplicaciones distribuidas globalmente expuestas a través de GKE Gateway y Cloud Service Mesh

Last reviewed 2024-06-30 UTC

En esta arquitectura de referencia se describen las ventajas de exponer aplicaciones externamente a través de las pasarelas 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 administradores de plataformas.

Puedes aumentar la resiliencia y la redundancia de tus servicios desplegando aplicaciones de forma coherente en varios clústeres de GKE, donde cada clúster se convierte en un dominio de error adicional. Por ejemplo, la infraestructura de computación 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 ofrecer a los usuarios una experiencia en la que las solicitudes entrantes se dirijan automáticamente a la puerta de enlace de entrada de malla con la latencia más baja y que esté disponible.

Si te interesan las ventajas de exponer aplicaciones habilitadas para malla de servicios que se ejecutan en un solo clúster, consulta el artículo Del perímetro a la malla: exponer aplicaciones en una malla de servicios a través de Gateway de GKE.

Arquitectura

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

Cifrado TLS desde el cliente, un balanceador de carga y la malla.

En el diagrama anterior se muestran los siguientes casos de flujo de datos:

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

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

  • Ingress de Cloud: en esta arquitectura de referencia, se usa la API Gateway de Kubernetes (y el controlador Gateway de GKE) para programar la capa de balanceo de carga HTTP(S) externa multiclúster. El balanceador de carga comprueba 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.
  • Ingreso de malla: en la malla, realizas comprobaciones del estado en los backends directamente para poder ejecutar el balanceo de carga y la gestión del tráfico de forma local.

Cuando se usan las capas de entrada juntas, cada capa tiene un rol complementario. Para alcanzar los siguientes objetivos, Google Cloud optimiza las funciones más adecuadas de la capa de entrada de la nube y de la capa de entrada de la malla:

  • Ofrecer una latencia baja.
  • Aumentar la disponibilidad.
  • Usar 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 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 los siguientes servicios, es ideal para ejecutar esos servicios en el perímetro, fuera de la malla:

  • Protección contra DDoS
  • Cortafuegos de Cloud
  • Autenticación y autorización
  • Cifrado

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 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 la plataforma 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 hace que esta capa sea menos flexible y dinámica que una infraestructura controlada por desarrolladores. Ten en cuenta estos factores a la hora de determinar los derechos de acceso de administrador a esta capa y cómo proporcionas ese acceso.

Entrada de malla

Cuando se combina con el acceso de entrada en la nube, la capa de acceso de entrada de la malla proporciona un punto de entrada para que el tráfico acceda a la malla de servicios. La capa también proporciona mTLS de backend, políticas de autorización y concordancia flexible de expresiones regulares.

Implementar el balanceo de carga de aplicaciones externo fuera de la malla con una capa de entrada de malla ofrece ventajas significativas, especialmente para la gestión del tráfico de Internet. Aunque las mallas de servicios y las pasarelas de entrada de Istio proporcionan enrutamiento avanzado y gestión del tráfico en la malla, 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 proporcionar mejoras significativas en el rendimiento, la fiabilidad o la seguridad en comparación con el acceso de entrada basado en malla.

Productos y funciones usados

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

  • GKE Enterprise: un servicio de Kubernetes gestionado que puedes usar para desplegar y operar aplicaciones en contenedores a gran escala con la infraestructura de Google. Para esta arquitectura de referencia, cada uno de los clústeres de GKE que sirven una aplicación debe estar en la misma flota.
  • Flotas y puertas de enlace multiclúster: 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 frente a los ataques web y de denegación de servicio.
  • Cloud Service Mesh: una malla de servicios totalmente gestionada basada en Envoy e Istio
  • Balanceador de carga de aplicaciones: un balanceador de carga de nivel 7 basado en proxy que te permite ejecutar y escalar tus servicios.
  • Certificate Manager: un servicio que te permite adquirir y gestionar certificados TLS para usarlos con Cloud Load Balancing.

Flotas

Para gestionar las implementaciones de varios clústeres, GKE Enterprise y Google Cloud usan flotas para agrupar y normalizar lógicamente los clústeres de Kubernetes.

Usar una o varias flotas puede ayudarte a mejorar la gestión de clústeres individuales a grupos enteros de clústeres. Para reducir los problemas de gestión de clústeres, usa el principio de flota de igualdad de espacios de nombres. En cada clúster de GKE de una flota, asegúrate de configurar todas las pasarelas de entrada de la malla de la misma forma.

Además, despliega los servicios de aplicación de forma coherente para que el lector de saldo de servicio de la cuenta de espacio de nombres se corresponda con un servicio idéntico en cada clúster de GKE de la flota. Los principios de igualdad y confianza que se presuponen en una flota son los que te permiten usar toda la gama de funciones habilitadas para flotas en GKE Enterprise y Google Cloud.

Las reglas de enrutamiento este-oeste de la malla de servicios y las políticas de tráfico se gestionan en la capa de entrada de la malla. La capa de entrada de la malla se despliega en todos los clústeres de GKE de la flota. Configure cada pasarela de entrada de malla de la misma manera, siguiendo el principio de igualdad de espacio de nombres de la flota.

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

Si necesitas proponer un nuevo clúster de configuración, usa ConfigSync. Config Sync ayuda a asegurar que todas estas configuraciones se sincronicen en todos los clústeres de GKE de la flota y evita que se concilien con una configuración no actual.

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 la política 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 el tráfico externo, necesitas un balanceador de carga que sea externo a la malla. Para automatizar el despliegue, esta arquitectura de referencia usa Cloud Load Balancing, que se aprovisiona a través de recursos de GKE Gateway.

Pasarela de GKE y servicios de varios clústeres

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

Cuando despliegas recursos de GKE Gateway en tu clúster de GKE, el controlador de Gateway monitoriza los recursos de la API Gateway. El controlador reconcilia los recursos de Cloud Load Balancing para implementar el comportamiento de red especificado por los recursos de 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:

  • 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 (externo o interno).
  • Las funciones necesarias del balanceador de carga, incluida la capacidad de integrarse con las políticas de seguridad de 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 Gateway, este comportamiento se controla especificando la GatewayClass adecuada. Cuando se hace referencia a las clases de Gateway, las que se pueden usar en escenarios de varios clústeres tienen un nombre de clase que termina en -mc.

En esta arquitectura de referencia se explica cómo exponer servicios de aplicaciones externamente a través de un balanceador de carga de aplicaciones externo. Sin embargo, cuando se usa Gateway, también se puede crear un balanceador de carga de aplicaciones interno regional multiclúster.

Para implementar servicios de aplicaciones en escenarios de varios clústeres, puedes definir los componentes del balanceador de carga de las dos formas siguientes:Google Cloud

Para obtener más información sobre estas dos formas de implementar servicios de aplicaciones, consulta Elegir la API de balanceo de carga multiclúster para GKE.

Ingress de varios clústeres se basa en la creación de recursos MultiClusterService. Multi-cluster Gateway se basa en la creación de recursos ServiceExport y en la referencia a recursos ServiceImport.

Cuando usas una pasarela de varios clústeres, puedes habilitar las funciones adicionales del balanceador de carga subyacente creando políticas. Google Cloud En la guía de despliegue asociada a esta arquitectura de referencia se muestra cómo configurar una política de seguridad de Google Cloud Armor para proteger los servicios de backend frente a secuencias de comandos entre sitios.

Estos recursos de políticas se dirigen a los servicios de backend de la flota que se exponen en varios clústeres. En los casos con varios clústeres, todas estas políticas deben hacer referencia al recurso ServiceImport y al grupo de APIs.

Comprobaciones del estado

Una de las complejidades de usar dos capas de balanceo de carga de capa 7 es la comprobación del estado. Debes configurar cada balanceador de carga para que compruebe el estado de la capa siguiente. La puerta de enlace de GKE comprueba el estado de los proxies de entrada de la malla y la malla, a su vez, comprueba el estado de los backends de la aplicación.

  • Ingreso en la nube: en esta arquitectura de referencia, se configura el Google Cloud balanceador de carga a través de la puerta de enlace de GKE para comprobar el estado de los proxies de ingreso 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 balanceador de carga Google Cloud detecta esta condición y no envía tráfico al proxy de malla. En este caso, el tráfico se dirigiría a un proxy de malla alternativo en otro clúster o región de GKE.
  • 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.

Factores del diseño

En esta sección se ofrecen directrices para ayudarte a usar esta arquitectura de referencia y desarrollar una arquitectura que cumpla tus requisitos específicos de seguridad, cumplimiento, fiabilidad y coste.

Seguridad, privacidad y cumplimiento

El diagrama de arquitectura de este documento contiene varios elementos de seguridad. Los elementos más importantes son cómo configuras el cifrado y cómo implementas los certificados. GKE Gateway se integra con Certificate Manager para estos fines de seguridad.

Los clientes de Internet se autentican con certificados públicos y se conectan al balanceador de carga externo como primer salto en la nube privada virtual (VPC). Puedes hacer referencia a un gestor de certificados CertificateMap en tu definición de pasarela. El siguiente salto se produce entre el frontend de Google (GFE) y el proxy de entrada de la malla. Ese salto está cifrado de forma predeterminada.

El encriptado a nivel de red entre los GFEs y sus backends se aplica automáticamente. 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 del proxy de Envoy).

Cuando habilitas HTTP/2 con cifrado TLS entre la pasarela del clúster y el ingreso de malla, puedes usar un certificado autofirmado o público para cifrar el tráfico. Puedes usar un certificado autofirmado o un certificado público, ya que el GFE no se autentica con él. Esta capa de cifrado adicional se muestra en la guía de implementación asociada a esta arquitectura de referencia.

Para evitar que se haga un uso inadecuado de los certificados, no reutilices los certificados públicos. Usa certificados independientes para cada balanceador de carga de la malla de servicios.

Para ayudarte a crear entradas DNS externas y certificados TLS, la guía de implementación de esta arquitectura de referencia usa Cloud Endpoints. Cloud Endpoints te permite crear un cloud.googsubdominio disponible externamente. En escenarios de nivel empresarial, usa un nombre de dominio más adecuado y crea un registro A que apunte a la dirección IP del balanceador de carga de aplicaciones global en tu proveedor de servicios DNS.

Si la malla de servicios que usas requiere TLS, todo el tráfico entre los proxies sidecar y todo el tráfico a la entrada de la malla se cifrará. El diagrama de arquitectura muestra el cifrado HTTPS desde el cliente hasta el Google Cloud balanceador de carga, desde el balanceador de carga hasta el proxy de entrada de la malla y desde el proxy de entrada hasta el proxy sidecar.

Fiabilidad y resiliencia

Una de las principales ventajas del patrón de borde a malla multiclúster y multirregional es que puede usar todas las funciones de la malla de servicios para el balanceo de carga este-oeste, como el tráfico entre servicios de aplicaciones.

Esta arquitectura de referencia usa una GKE Gateway multiclúster para enrutar el tráfico de entrada de cloud a un clúster de GKE. El sistema selecciona un clúster de GKE en función de su proximidad al usuario (según la latencia), así como de su disponibilidad y estado. Cuando el tráfico llega a la puerta de enlace de entrada de Istio (la entrada de la malla), se dirige a los back-ends correspondientes a través de la malla de servicios.

Otra forma de gestionar el tráfico este-oeste es mediante servicios multiclúster para todos los servicios de aplicaciones desplegados en clústeres de GKE. Cuando se usan servicios multiclúster en clústeres de GKE de una flota, los endpoints de servicio se agrupan en un ClusterSet. Si un servicio necesita llamar a otro, puede dirigirse a cualquier endpoint correcto del segundo servicio. Como los endpoints se eligen de forma rotatoria, el endpoint seleccionado podría estar en una zona o una región diferente.

Una de las principales ventajas de usar una malla de servicios para el tráfico este-oeste en lugar de usar servicios multiclúster es que la malla de servicios puede usar el balanceo de carga de localidad. El balanceo de carga local no es una función de los servicios de varios clústeres, pero puedes configurarlo mediante un DestinationRule.

Una vez configurada, una llamada de un servicio a otro intenta primero acceder a un endpoint de servicio en la misma zona y, después, en la misma región que el servicio que realiza la llamada. Por último, la llamada solo se dirige a un endpoint de otra región si no hay disponible ningún endpoint de servicio en la misma zona o región.

Optimización de costes

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

Implementación

Para desplegar esta arquitectura, consulta Del perímetro a la malla multiclúster: desplegar aplicaciones distribuidas globalmente a través de GKE Gateway y Cloud Service Mesh.

Siguientes pasos

Colaboradores

Autores:

Otros colaboradores: