En este documento, se describe cómo funcionan las puertas de enlace de varios clústeres en Google Kubernetes Engine (GKE). Las puertas de enlace de varios clústeres son una solución de red potente que te permite administrar el tráfico de los servicios implementados en varios clústeres de GKE.
Este documento está dirigido a arquitectos de nube y especialistas en herramientas de redes que diseñan la red de su organización. Para obtener más información sobre los roles comunes y las tareas de ejemplo a las que hacemos referencia en el contenido de Google Cloud , consulta Roles de usuario y tareas comunes de GKE Enterprise.
Descripción general
La puerta de enlace de varios clústeres se configura con los recursos de la API de Gateway de Kubernetes. El controlador de Gateway de GKE supervisa estos recursos (Gateway, HTTPRoute y TLSRoute) y aprovisiona y mantiene de forma automática la infraestructura de balanceo de cargas deGoogle Cloud necesaria. Esta infraestructura proporciona administración avanzada del tráfico para los servicios implementados en varios clústeres de GKE dentro de una flota. Las puertas de enlace de varios clústeres usan la infraestructura de balanceo de cargas de Google Cloud para proporcionar un único punto de entrada unificado para tus aplicaciones. Este enfoque tiene los siguientes beneficios:
- Simplifica la administración
- Mejora la confiabilidad
- Habilita funciones avanzadas de administración del tráfico
Funciones de administración del tráfico
Las puertas de enlace de varios clústeres te proporcionan capacidades avanzadas para administrar el tráfico en varios clústeres. Puedes implementar estrategias de enrutamiento sofisticadas, como lanzamientos por fases y estrategias azul-verde, para implementar cambios de forma segura. Para obtener un control detallado, puedes usar la coincidencia basada en encabezados para probar los cambios con un pequeño porcentaje de tráfico o dividir el tráfico por peso para cambiar de forma gradual las solicitudes entre diferentes backends de clústeres.
Las puertas de enlace de varios clústeres también te permiten duplicar el tráfico, lo que envía una copia de las solicitudes de los usuarios en vivo a un servicio nuevo para probar el rendimiento sin afectar a los usuarios. Para garantizar la confiabilidad y evitar sobrecargas, las Gateways de varios clústeres admiten la conmutación por error basada en el estado y el balanceo de cargas basado en la capacidad, que distribuye las solicitudes según la capacidad definida de tus servicios.
Para el tráfico TLS que requiere encriptación de extremo a extremo sin finalizar TLS en el balanceador de cargas, las puertas de enlace de varios clústeres admiten el enrutamiento basado en SNI con TLSRoute.
Cómo funciona la puerta de enlace de varios clústeres
Todos los clústeres de GKE que participan en una configuración de puerta de enlace de varios clústeres deben estar registrados en una flota. Una flota proporciona una agrupación lógica de clústeres, lo que permite una administración y comunicación coherentes entre los clústeres. Un clúster de GKE dentro de la flota se designa como el clúster de configuración.
El clúster de configuración actúa como un punto de control centralizado para tu configuración de Gateway de varios clústeres. Implementas todos los recursos de la API de Gateway de varios clústeres, como Gateway, HTTPRoute y TLSRoute, solo en este clúster designado. El controlador de Gateway de GKE observa el servidor de la API de Kubernetes del clúster de configuración para estos recursos.
Para elegir un clúster de configuración, considera un clúster regional o cualquier otro clúster de GKE con alta disponibilidad. Esto ayuda a garantizar que el controlador pueda conciliar de forma continua las actualizaciones de tus recursos de la API de Gateway.
El controlador de Gateway de varios clústeres usa servicios de varios clústeres (MCS) para descubrir y acceder a los servicios de Kubernetes en varios clústeres de GKE dentro de una flota. MCS es una función de GKE que habilita el descubrimiento de servicios y la conectividad entre los servicios que se ejecutan en diferentes clústeres de GKE dentro de una flota.
La MCG usa MCS para descubrir qué Services están disponibles en qué clústeres para enrutar el tráfico externo a los Services. El controlador de MCG usa recursos de la API de MCS para agrupar Pods en un solo Service que se pueda dirigir a varios clústeres y que los abarque.
Según los parámetros de configuración que definiste en los recursos de la API de Gateway, el controlador de GKE Gateway proporciona un balanceador de cargas de aplicaciones interno o externo (para HTTPRoute) o un balanceador de cargas de red de proxy (para TLSRoute). Este balanceador de cargas funciona como el frontend de tu aplicación y distribuye el tráfico directamente a los Pods en buen estado de tu flota, sin importar su ubicación.
En los siguientes pasos de alto nivel, se describe el proceso para implementar una puerta de enlace de varios clústeres:
Define una puerta de enlace: En una configuración de puerta de enlace de varios clústeres, creas un recurso de puerta de enlace que define el punto de entrada para tu tráfico en el clúster de configuración. El recurso Gateway especifica una GatewayClass, que es una plantilla para un tipo particular de balanceador de cargas, como un balanceador de cargas de aplicaciones externo global o un balanceador de cargas de aplicaciones interno regional. En GKE, las siguientes GatewayClasses implementan puertas de enlace de varios clústeres:
gke-l7-global-external-managed-mc: aprovisiona un balanceador de cargas de aplicaciones externo global.gke-l7-regional-external-managed-mc: Aprovisiona un balanceador de cargas de aplicaciones externo regional o un balanceador de cargas de red de proxy externo regional.gke-l7-cross-regional-internal-managed-mc: Aprovisiona un balanceador de cargas de aplicaciones interno entre regiones o un balanceador de cargas de red de proxy interno entre regiones.gke-l7-rilb-mc: Aprovisiona un balanceador de cargas de aplicaciones interno regional o un balanceador de cargas de red de proxy interno regional.gke-l7-gxlb-mc: aprovisiona un balanceador de cargas de aplicaciones clásico.
La puerta de enlace también define cómo el balanceador de cargas escucha el tráfico entrante especificando qué objetos de escucha de red (puertos y protocolos) se deben exponer. Para obtener más información sobre las clases de Gateway que admite GKE, consulta Servicios multiclúster.
Adjunta recursos de ruta a la puerta de enlace: Los recursos de ruta definen cómo el balanceador de cargas enruta el tráfico entrante a servicios de backend específicos:
- HTTPRoute: Define cómo el balanceador de cargas enruta el tráfico HTTP y HTTPS en función de los nombres de host, las rutas de acceso, los encabezados y los parámetros de consulta. Admite la división del tráfico, el redireccionamiento de solicitudes y la duplicación del tráfico.
- TLSRoute: Define cómo el balanceador de cargas enruta el tráfico de TLS encriptado
en función del nombre de host de SNI con la transferencia de TLS (compatible con las
GatewayClasses
gke-l7-regional-external-managed-mc,gke-l7-rilb-mcygke-l7-cross-regional-internal-managed-mc). El balanceador de cargas reenvía el tráfico directamente a los ServiceImports de backend sin desencriptar la carga útil en la puerta de enlace.
Crea un balanceador de cargas: Cuando implementas recursos de Gateway y Route, el controlador de GKE Gateway interpreta estos objetos de la API y, a su vez, configura de forma dinámica la infraestructura de balanceo de cargas de Google Cloud necesaria. Luego, el balanceador de cargas dirige el tráfico a los Pods correctos, sin importar en qué clúster se encuentren. Este proceso proporciona una forma muy eficiente y escalable de enrutar el tráfico.
Flujo de tráfico
En el siguiente diagrama, se ilustra cómo funciona una Gateway de varios clústeres como un balanceador de cargas centralizado para las aplicaciones que se ejecutan en dos clústeres de GKE en diferentes regiones:
El comportamiento del balanceador de cargas se configura según las reglas definidas en tus recursos HTTPRoute o TLSRoute. Cuando el tráfico de los usuarios llega a la dirección IP del balanceador de cargas de Google Cloud aprovisionado (como lo define tu recurso Gateway), el balanceador de cargas, que es un proxy administrado por Google, enruta el tráfico. Este proxy (ya sea un proxy de Google Front End o un proxy regional) dirige el tráfico al extremo del servicio de backend adecuado dentro del clúster de GKE correcto, según los siguientes criterios:
- Verificaciones de estado
- Reglas de división del tráfico
- Capacidad
El tráfico fluye directamente al Pod óptimo en el clúster seleccionado.
¿Qué sigue?
- Obtén más información para implementar una puerta de enlace externa de varios clústeres.
- Obtén más información para implementar una puerta de enlace interna de varios clústeres.
- Obtén más información para implementar una puerta de enlace de transferencia de TLS.
- Obtén más información para habilitar las puertas de enlace de varios clústeres.
- Lee una descripción general de cómo funcionan las puertas de enlace en GKE.