Arquitectura de referencia del balanceo de cargas de capa 7

Esta arquitectura de referencia proporciona una solución de balanceo de cargas de capa 7 administrada por el cliente en Google Distributed Cloud (GDC) aislado. Si implementan controladores de código abierto populares, como HAProxy Kubernetes Ingress o NGINX Gateway Fabric, en un clúster estándar de GDC, los clientes pueden enrutar sin problemas el tráfico de L7 a entornos híbridos. Esta arquitectura usa la finalización de TLS (Ingress/HTTPRoute) para enrutar el tráfico según la indicación de nombre del servidor (SNI) a los Pods en contenedores integrados y a las aplicaciones alojadas en máquinas virtuales externas.

Características y funciones

  • Enrutamiento avanzado de capa 7: Admite el enrutamiento basado en el host, el enrutamiento basado en la ruta de acceso y la administración avanzada del tráfico, como la coincidencia basada en encabezados y la ponderación del tráfico.
  • Administración centralizada de TLS: Proporciona administración y finalización centralizadas de TLS.
  • Compatibilidad con entornos híbridos: Enruta sin problemas el tráfico de L7 a los Pods en contenedores integrados y a las aplicaciones alojadas en máquinas virtuales externas.
  • Opciones de controlador flexibles: Ofrece una opción entre el moderno NGINX Gateway Fabric (con la API de Gateway) o el controlador de Ingress de HAProxy bien establecido.
  • Preparación para entornos aislados: Se integra en Harbor Registry para almacenar y entregar imágenes de proxy y de aplicaciones en entornos privados y desconectados.
  • División de tráfico compleja: Habilita estrategias avanzadas de distribución de tráfico para la entrega de aplicaciones modernas.

Principios de arquitectura

  • Patrón de balanceo de cargas de dos niveles: Esta arquitectura combina el balanceador de cargas de L4 integrado de GDC (como punto de entrada) con una puerta de enlace de L7 administrada por el cliente implementada en Kubernetes.
  • Separación orientada a roles: Sigue un diseño que separa las responsabilidades entre los proveedores de infraestructura, los operadores de clústeres y los desarrolladores a través de recursos específicos (como GatewayClass, Gateway y HTTPRoute o Ingress).
  • Transición a estándares modernos: La arquitectura prioriza la API de Gateway para las funciones de enrutamiento modernas, a la vez que mantiene la compatibilidad con la API de Ingress heredada cuando se requiere estabilidad para controladores específicos.
  • Flexibilidad administrada por el cliente: Con la implementación de controladores autoadministrados, los clientes obtienen control sobre las funciones y la configuración de L7 que no proporciona de forma nativa el balanceador de L4 administrado por GDC.
  • Abstracción de la ubicación de la carga de trabajo: La arquitectura trata las cargas de trabajo en contenedores y basadas en VM de manera coherente a través de abstracciones de Service de Kubernetes (estándar o sin interfaz gráfica).

Arquitectura conceptual

Diagrama de arquitectura conceptual para el balanceo de cargas de capa 7 en GDC aislado.

Arquitectura lógica

La arquitectura lógica consta de varios componentes funcionales que trabajan en conjunto para enrutar el tráfico externo a backends internos o externos:

  1. Punto de entrada de Ingress/puerta de enlace: Un cliente inicia solicitudes HTTPS que primero llegan al balanceador de cargas de L4 de GDC. Este balanceador integrado funciona como punto de entrada y distribuye el tráfico TCP/443 al balanceador de cargas L7.
  2. Plano de control: Los controladores de Ingress o Gateway (operadores de HAProxy o NGINX) supervisan los recursos de Kubernetes, como Ingress, Gateway y HTTPRoute.
  3. Plano de datos: En función de los recursos observados, los controladores actualizan de forma dinámica los proxies subyacentes que realizan el enrutamiento de tráfico real según las reglas de enrutamiento de host basadas en SNI y la finalización de TLS.
  4. Servicios de backend:
    • Pods en contenedores: Se administran como Deployments estándar y se exponen con Services de Kubernetes normales.
    • VMs externas: Se integran en el clúster con un Service de Kubernetes sin interfaz gráfica y un extremo personalizado (o EndpointSlice) que contiene la IP directa de la VM.
  5. Administración de artefactos: Todas las imágenes de los proxies y las aplicaciones se entregan desde un registro de Harbor local para garantizar la funcionalidad en un entorno aislado.

Conceptos y tecnologías básicos

La arquitectura usa un patrón de balanceo de cargas de dos niveles, que combina el balanceador de cargas L4 integrado de GDC con una puerta de enlace L7 administrada por el cliente implementada en Kubernetes. Entre los componentes clave, se incluyen los siguientes:

  • Cliente: Es una entidad que inicia solicitudes HTTPS para interactuar con las aplicaciones.
  • Clúster estándar de GDC: GDC proporciona una forma integrada de crear clústeres Vanilla de Kubernetes. En esta solución, el clúster alojará el LB de L7 y sus controladores, junto con las cargas de trabajo y el servicio sin interfaz gráfica para las VMs externas
  • Balanceador de cargas de L4 de GDC: Es el balanceador de cargas de L4 integrado que funciona como punto de entrada y distribuye el tráfico de TCP/443 directamente a los Pods de Kubernetes que ejecutan los controladores de Ingress o Gateway.
  • Controladores de Ingress y Gateway: Son operadores de HAProxy o NGINX que se ejecutan en el clúster estándar. En el caso de Nginx, supervisan los recursos de la API de Gateway (como Gateway y HTTPRoute) y actualizan de forma dinámica los proxies subyacentes. En el caso de HAProxy, supervisan los recursos Ingress y actualizan de forma dinámica los proxies subyacentes.
    • Controlador de Ingress de HAProxy: Es un controlador de Ingress para Kubernetes que usa HAProxy como proxy inverso y balanceador de cargas de capa 7, y que también controla la finalización de TLS.
    • Nginx Gateway Fabric: Es una implementación de la API de Gateway que usa NGINX como plano de datos.
  • Ingress y Gateway (con HTTPRoute): Son recursos estandarizados de Kubernetes que definen el puerto de escucha físico (443) y las reglas de enrutamiento de host basadas en SNI con finalización de TLS.
  • Carga de trabajo alojada en contenedores (Pods): Es un Deployment de Kubernetes estándar expuesto de forma interna con un Service de Kubernetes normal.
  • Carga de trabajo basada en VM (externa): Es una carga de trabajo alojada en una VM externa en la red del proyecto, expuesta al proxy con un Service de Kubernetes sin interfaz gráfica y un extremo personalizado que contiene la IP directa de la VM.
  • Registro de Harbor: Es un registro de contenedores privado que se usa para almacenar y entregar las imágenes de proxy y de aplicación en el entorno aislado.

APIs de Ingress frente a las de Gateway

El panorama de las redes de Kubernetes está en transición de la API de Ingress heredada a la API de Gateway moderna. Comprender las diferencias entre estas dos opciones es fundamental para seleccionar la arquitectura adecuada para tus cargas de trabajo.

  • API de Ingress: Históricamente, Ingress ha sido el estándar para administrar el acceso externo a los servicios HTTP. Proporciona enrutamiento basado en el host y en la ruta de acceso, pero su diseño es relativamente básico y carece de compatibilidad integrada con la administración avanzada del tráfico (por ejemplo, la coincidencia basada en encabezados o la ponderación del tráfico) sin depender de anotaciones específicas del proveedor. Es importante destacar que la comunidad de Kubernetes ahora considera que la API de Ingress tiene funciones congeladas (limitaciones de Ingress y evolución de las redes de Kubernetes).

  • API de Gateway: A menudo, se la conoce como la V2 de Ingress. La API de Gateway es una colección de definiciones de recursos personalizados (CRD) que proporcionan un modelo más sólido y extensible para las redes de servicios. Está diseñada para estar orientada a roles, lo que separa las responsabilidades entre los proveedores de infraestructura (GatewayClass), los operadores de clústeres (Gateway) y los desarrolladores (HTTPRoute/TLSRoute) (API de Gateway en GKE). Esta separación permite un control más detallado y una mejor compatibilidad con múltiples instancias.

En esta solución de GDC aislado, elegimos de forma intencional diferentes APIs para los dos controladores destacados:

  • NGINX (API de Gateway): Para la implementación de NGINX, usamos NGINX Gateway Fabric, que es una implementación madura y nativa de la API de Gateway. Aprovechar la API de Gateway para NGINX permite que los clientes se beneficien de los estándares modernos y las capacidades de enrutamiento avanzadas (como HTTPRoute) que están integradas en la API.
  • HAProxy (API de Ingress): Aunque la API de Gateway es la dirección estratégica, seleccionamos la API de Ingress para HAProxy en esta guía. Esto se debe a que la integración de la API de Gateway de HAProxy no se considera madura. Con el controlador de Ingress de HAProxy bien establecido, garantizamos una solución de L7 estable y confiable para los clientes que prefieren HAProxy, a la vez que proporcionamos una ruta hacia las capacidades modernas de L7.

Suposiciones y restricciones

Suposiciones

  • Preparación de la infraestructura: La implementación supone la disponibilidad de clústeres estándar de GDC aislado 1.15.x.
  • Registro local: Se supone que un registro de Harbor local está configurado correctamente para almacenar y entregar imágenes de proxy y de aplicación en el entorno aislado.
  • Punto de entrada nativo: Se supone que el tráfico llega primero al balanceador de cargas de L4 de GDC integrado, que luego distribuye el tráfico a los proxies de L7.

Limitaciones

  • Solución administrada por el cliente: No hay un servicio de L7 administrado y respaldado por un ANS en GDC. El cliente administra por completo esta implementación.
  • Solo clústeres de Standard: Los clústeres de usuario compartidos están fuera del alcance debido a los privilegios altos que se requieren para la implementación de Ingress y Gateway Controller.
  • Madurez de la API: Mientras que NGINX usa la API de Gateway moderna, HAProxy está restringido a la API de Ingress porque su integración con la API de Gateway aún no se considera madura.
  • Mantenimiento aislado: Todas las imágenes de contenedor se deben promocionar y administrar de forma manual dentro del registro local de Harbor.
  • Ediciones de la comunidad: La arquitectura está diseñada para las ediciones de la comunidad de código abierto de Nginx y HAProxy. Es posible que las ediciones Enterprise funcionen, pero no se probaron de forma explícita.
  • Propiedad operativa: Los clientes deben administrar su propio escalamiento, alta disponibilidad y aplicación de parches para los controladores de terceros.
  • Límite de asistencia: La Atención al Cliente de Google solo abarca la infraestructura subyacente de GDC. Los problemas con el software de HAProxy o NGINX en sí son responsabilidad del cliente o del proveedor.
  • Obsolescencia de la API: La comunidad de Kubernetes congela las funciones de la API de Ingress (usada para HAProxy), lo que puede limitar las capacidades de enrutamiento futuras.

Licencias

  • Ediciones de la comunidad: La arquitectura está diseñada para ediciones de la comunidad de código abierto (por lo general, Apache 2.0 o similar), que son de uso gratuito, pero administradas por el cliente.
  • Adquisición empresarial: La adquisición y la administración de licencias comerciales, como NGINX Plus o HAProxy Enterprise, son responsabilidad exclusiva del cliente.

Materiales adicionales