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 2026-06-04 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 administradores de plataformas.

Puedes aumentar la resiliencia y la redundancia de tus servicios si implementas aplicaciones de manera coherente en varios clústeres de GKE, en los que cada clúster se convierte en un dominio de falla adicional. Por ejemplo, la 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 automáticamente a la puerta de enlace de entrada de la 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 entrada 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 finaliza en el Google Cloud balanceador de cargas con su propio certificado TLS administrado por Google
  • Desde el Google Cloud balanceador de cargas al proxy de entrada de la malla con su propio certificado TLS autofirmado
  • Desde el proxy de la puerta de enlace de entrada de la malla a los proxies de sidecar de la carga de trabajo con 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 las funciones más adecuadas de la capa de entrada de la nube y 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, tiene un gran rendimiento 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

Por lo general, la lógica de enrutamiento es sencilla en la capa de entrada de la nube. Sin embargo, puede ser más compleja para los entornos de varios clústeres y varias regiones.

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 controlada por desarrolladores. Ten en cuenta estos factores cuando determines los derechos de acceso administrativo a esta capa y cómo proporcionas ese acceso.

Entrada de la malla

Cuando se combina 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 coincidencias de expresiones regulares flexibles.

La implementación del 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 las puertas de enlace de entrada de la malla de servicios 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 de Google Cloudl balanceador de cargas de aplicaciones externo de puede proporcionar importantes beneficios de rendimiento, confiabilidad o seguridad en la entrada basada en la malla.

Productos y funciones usados

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

  • GKE: 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.
  • 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 de 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 y Google Cloud usan flotas para agrupar y normalizar de forma lógica los clústeres de Kubernetes.

Usar 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 de la administración de clústeres, usa el principio de similitud de espacio de nombres de la flota. Para cada clúster de GKE en una flota, asegúrate de configurar todas las puertas de enlace de entrada de la malla de la misma manera.

Además, implementa de manera coherente los servicios de aplicaciones para que el lector de saldo de servicio 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 los que te permiten usar la gama completa de funciones habilitadas para la flota en GKE 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 nuevo clúster de configuración, 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 maneras 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 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 Gateway, las 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 explica cómo exponer los servicios de aplicaciones 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 Google Cloud componentes del balanceador de cargas de las siguientes dos maneras:

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

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

Cuando usas una Gateway de varios clústeres, puedes habilitar las capacidades adicionales del Google Cloud balanceador de cargas 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 ayudar a 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 se exponen en varios clústeres. En situaciones de varios clústeres, todas esas políticas deben hacer referencia al ServiceImport recurso y al 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 Google Cloud balanceador de cargas a través de GKE Gateway 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 Google Cloud balanceador de cargas detecta esta condición y no envía tráfico al proxy de la malla. En este caso, el tráfico se enrutará a un proxy de malla alternativo en un clúster de GKE o región 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 para desarrollar una arquitectura que cumpla con tus requisitos específicos de seguridad y cumplimiento, confiabilidad y costo.

Security, privacy, and compliance

El diagrama de arquitectura de este documento contiene varios elementos de seguridad. Los elementos más importantes son la forma en que configuras la encriptación y la implementación de certificados. GKE Gateway se integra con 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 entrada 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 GFE no se autentica con él. Esta capa adicional de encriptación se demuestra en la guía de implementación asociada con esta arquitectura de referencia.

Si deseas usar HTTP/2 para la conexión de GFE a la malla, pero no necesitas tu propia encriptación, puedes usar H2C.

Para evitar el manejo inadecuado de certificados, no reutilices certificados públicos. Usa certificados separados para cada balanceador de cargas en la malla de servicios.

Para ayudar a crear entradas DNS externas y certificados TLS, la guía de implementación para esta arquitectura de referencia usa Cloud Endpoints. El uso de Cloud Endpoints te permite crear un subdominio cloud.goog disponible de forma externa. En situaciones 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 cargas de aplicaciones global en tu proveedor de servicios DNS.

Si la malla de servicios que usas exige TLS, todo el tráfico entre los proxies de sidecar y todo el tráfico a la entrada de la malla se encriptan. En el diagrama de arquitectura, se ilustra la encriptación HTTPS del cliente al Google Cloud balanceador de cargas, 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 varios clústeres y varias regiones del perímetro a la malla es que puede usar todas las funciones de la malla de servicios para el balanceo de cargas este-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 entrada de la nube a un clúster de GKE. El sistema selecciona un clúster de GKE según su proximidad al usuario (según 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 clústeres de GKE en una flota, los extremos de servicio se recopilan en un ClusterSet. Si un servicio necesita llamar a otro servicio, puede orientarse a cualquier extremo en buen estado para el segundo servicio. Debido a que los extremos se eligen de forma rotativa, 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 este-oeste en lugar de usar 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 llegar a un extremo de servicio en la misma zona y, luego, en la misma región que el servicio que llama. Por último, la llamada solo se orienta a un extremo en otra región si no está disponible un extremo de servicio en la misma zona o región.

Deployment

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: