Unidad 3.3: Equilibrio de carga - Capa 7 (Aplicación)

Introducción

Un equilibrador de carga de la capa 7 es el punto en el que la red deja de mover paquetes y comienza a leer solicitudes. Esa es la decisión que esta unidad regula: si su borde necesita comprender HTTP (hosts, rutas, encabezados, métodos) lo suficiente para enrutar según ellos, o si solo necesita distribuir conexiones TCP entre un grupo. El Managed Application Load Balancer (ALB) de IONOS CLOUD es la opción consciente del contenido, y también es donde la plataforma sustituye un producto que no vende, una API administrada, al exponer reglas de enrutamiento en su lugar. Esta unidad comienza con esa decisión de enrutamiento y sus consecuencias en certificados y costos, y termina construyendo el ALB público que da servicio a la capa de aplicaciones de FinCorp en el Data Center Designer, ubicado en la LAN del borde público establecida en la Unidad 3.1.

1. Cuando la capa 7 justifica su lugar

El Managed Application Load Balancer distribuye el tráfico entrante de la capa de aplicación hacia los destinos basándose en políticas definidas por el usuario, operando en la capa 7 del modelo OSI. El Network Load Balancer (NLB), tratado en la Unidad 3.4, opera en la capa 4. La orientación oficial traza la línea de forma clara: si su lógica de equilibrado necesita procesar solicitudes HTTP y sus atributos, utilice el ALB; si el rendimiento de enrutamiento es crítico y la lógica puede permanecer en la capa 4, enrute el tráfico TCP con el NLB.

El ALB justifica su lugar cuando usted enruta según el contenido de la solicitud y no de la conexión. Sus reglas de reenvío admiten enrutamiento basado en ruta, basado en nombre de host, basado en cadena de consulta, basado en encabezados, basado en método, basado en cookies, basado en IP de origen, redirección de URL y respuesta fija o estática. Por lo tanto, un único punto de entrada público puede enviar /api a un grupo de destinos y /static a otro, servir dos nombres de host desde una misma IP, o devolver un 503 fijo durante el mantenimiento, todas decisiones ante las que un equilibrador de capa 4 es ciego. La contrapartida es que cada solicitud se analiza y coincide, razón por la cual el NLB se reserva para casos en los que dicho trabajo es desperdiciado: tráfico cifrado de extremo a extremo que el equilibrador no debe descifrar, o cualquier protocolo no HTTP. La aplicación regulada de FinCorp tiene interfaz HTTP, con un portal de cliente y una superficie de API que comparten un mismo nombre de host y certificado, por lo que la capa 7 es el borde correcto; la capa de base de datos privada permanece en la capa 4. Esta es la forma de borde público en capa 7 y privado en capa 4 descrita en la Unidad 1.2.

Tres límites de la plataforma determinan cómo usted protege y dimensiona el ALB, y los tres son entradas de diseño y no defectos:

• El ALB no tiene listas de permisos de IP ni Network Security Group. Como se estableció en la Unidad 3.2, los NSG y los cortafuegos de NIC se vinculan a las NIC de los servidores solo a nivel de VDC y no se aplican a los equilibradores administrados. Por lo tanto, el filtrado corresponde a los destinos: reglas de cortafuegos en las NIC de los servidores de backend más la lógica de la aplicación, manteniendo la capa de datos inalcanzable por topología.
• El ALB no proporciona NAT de origen para las conexiones con los destinos, por lo que no es una ruta de salida. Las cargas de trabajo privadas acceden a internet a través de la NAT Gateway de la Unidad 3.6.
• IPv6 tiene limitaciones documentadas en el ALB, por lo que debe tratar el listener público como un punto de acceso IPv4 en una dirección IPv4 pública reservada y planificar cualquier exposición IPv6 por separado.

No existe un producto API Gateway de IONOS CLOUD. El sustituto de la plataforma es exactamente el mecanismo que esta unidad construye: las reglas de reenvío del ALB llevan el enrutamiento de contenido grueso (reglas de ruta y host, redirecciones, respuestas fijas) en el borde, y un controlador de entrada dentro del clúster lleva un enrutamiento más granular y consciente de la aplicación dentro de un clúster de Kubernetes detrás de él. Usted compone el comportamiento de API-gateway a partir de un equilibrador administrado más un controlador de entrada dentro del clúster, en lugar de aprovisionar un único producto de pasarela.

2. Los tres componentes obligatorios y el costo de las reglas

Cada ALB requiere al menos un listener, una regla de reenvío y un grupo de destino. Comprender la función de cada componente y su costo respectivo es lo que permite mantener un diseño de capa 7 ágil.

La siguiente tabla resume los tres componentes y sus roles.

El algoritmo de equilibrado predeterminado es Round Robin; los algoritmos disponibles son Round Robin, Least Connections, Random y Source IP. La ponderación por destino (un peso en el rango de 1 a 256) le permite sesgar la distribución, lo cual es el mecanismo para implementar un canary ponderado en la capa 7.

Los componentes se componen jerárquicamente, y es en esa jerarquía donde la disciplina en las reglas resulta fundamental. Un listener contiene reglas de reenvío; una regla de reenvío contiene un conjunto ordenado de reglas HTTP; la solicitud coincide con las reglas en orden y, si ninguna coincide, se aplica una acción predeterminada. Por lo tanto, debe colocar las reglas más específicas al inicio y la regla genérica al final, con una única acción predeterminada clara por listener (generalmente un reenvío al grupo de destino principal o una respuesta fija).

Mantenga el conjunto de reglas ágil por una razón que va más allá de la claridad: las reglas y los listeners constituyen la superficie gestionada del ALB, y un conjunto extenso representa una responsabilidad operativa. Un ALB tiene un límite de 10 listeners y un contrato de 5 ALBs, por lo que el recurso está deliberadamente acotado. La disciplina consiste en expresar el enrutamiento con el menor número de reglas correctas, delegar el enrutamiento de gran granularidad en el ingress dentro del clúster, donde corresponde, y reutilizar grupos de destino entre reglas en lugar de duplicarlos.

3. Terminación de TLS y obtención de certificados

El ALB realiza la descarga de TLS: termina la conexión TLS en el listener para que la conexión con el backend pueda ser HTTP en texto plano. Este es el patrón normal de la capa 7 y es la razón por la que el certificado reside en el ALB, no en los destinos. El ALB también admite SNI, de modo que un listener puede presentar el certificado correcto para varios nombres de host. (Cuando el backend debe conservar el certificado y el balanceador no debe descifrar, se trata del caso de la capa 4 de la Unidad 3.4, no de una configuración del ALB).

Las restricciones de los certificados son específicas y constituyen la parte con mayor probabilidad de causar el fracaso en un primer intento de aprovisionamiento, por lo que debe obtener el certificado de manera deliberada. El ALB requiere exactamente un certificado de hoja (de entidad final) y la clave debe ser RSA. Según la documentación del 2026-06, los certificados de CA intermedios y de raíz pueden incluirse junto con el certificado de hoja en el mismo archivo, por lo que ahora se permite una cadena completa; lo que se rechaza es proporcionar solo certificados de CA, o más de un certificado de hoja. La clave pública del certificado de hoja debe coincidir con la clave privada proporcionada, y la clave privada debe ser una única clave RSA en formato PKCS#1 (RSA PRIVATE KEY) o PKCS#8 (PRIVATE KEY).

Certificate Manager ofrece dos vías, y solo una alimenta el ALB. El ALB consume únicamente certificados importados: usted carga el certificado, la cadena y la clave privada como PEM, y adjunta el recurso resultante al listener. La vía de certificado automático (ACME), que se renueva automáticamente a través de un proveedor como Let's Encrypt y requiere que la zona DNS del dominio esté alojada en IONOS Cloud DNS, lista a CDN como su consumidor aguas abajo, no al ALB. Por lo tanto, no puede depender de la renovación ACME administrada para un listener del ALB; usted importa un certificado PEM y es responsable de su rotación. De ello se deriva una restricción: en un certificado importado, la clave privada se establece en la creación y no puede editarse, por lo que la rotación implica crear un nuevo recurso de certificado y reorientar el listener, no editar la clave en su lugar. Incluya esto en el manual de renovación. Para FinCorp, el portal y la API comparten un mismo nombre de host y un mismo certificado PEM de hoja RSA importado, terminado en el ALB, y la renovación es un intercambio basado en el calendario.

Recorrido de implementación de DCD

Construirá el punto de entrada público de la capa 7 para la capa de aplicaciones de FinCorp: un ALB público en la LAN de borde de la Unidad 3.1, con un listener HTTPS que termina TLS, un grupo de destino que apunta a los servidores de aplicaciones, una regla de reenvío basada en ruta y una comprobación de estado HTTP. Esto materializa el extremo público de la arquitectura por capas y proporciona la mitad de borde para la sustitución de la pasarela de API.

Objetivo de construcción: Construir un balanceador de la capa 7 público con un listener HTTPS, un grupo de destino, una regla de ruta y una comprobación de estado.

Requisitos previos: Una dirección IPv4 pública reservada desde IP Management (un ALB público requiere al menos una IP de listener), la topología de tres LAN y los servidores de aplicaciones de la Unidad 3.1, y un certificado PEM importado en Certificate Manager (hoja RSA única, cadena opcional, clave privada RSA coincidente) para el listener HTTPS.

Pasos (en Data Center Designer):

1. Cree primero el grupo de destino. Vaya a Menú > Network Services > Target Groups y seleccione Create. Asigne un nombre y elija un algoritmo (Round Robin es el valor predeterminado; Least Connections, Random y Source IP son las alternativas).
2. En el grupo de destino, agregue destinos en la pestaña Targets: para cada servidor de aplicaciones, ingrese su IP y el puerto de backend en el que el servicio escucha (el backend puede ser HTTP en texto plano porque el ALB termina TLS). Establezca un peso por destino (de 1 a 256) si desea sesgar la distribución, por ejemplo para un canary ponderado.
3. Agregue la comprobación de estado en la pestaña Connection del grupo de destino. Para una comprobación HTTP, establezca la Path (predeterminada /), el Method y el Match Type (Status Code, o Response Body con una expresión regular opcional o negación). Tenga en cuenta que no se debe configurar una comprobación de estado HTTP si se pretende usar soporte gRPC o WebSocket en este grupo.
4. Coloque el ALB: en el espacio de trabajo del centro de datos, arrastre un Load Balancer de tipo Application al lienzo.
5. Conecte sus interfaces: conecte la interfaz norte a Internet Access (el borde público) y la interfaz sur a la LAN de la capa de aplicaciones que contiene los destinos. Solo los balanceadores de carga públicos requieren una IP pública y conectividad orientada a Internet; un ALB privado no necesita IP pública.
6. Configure el listener como HTTPS: asigne la IP pública reservada como IP del listener, establezca el puerto del listener (443 para HTTPS) y asocie el certificado PEM importado de Certificate Manager para que el ALB termine TLS en este listener.
7. Agregue la regla de reenvío en la pestaña Forwarding rules: nómbrela, confirme el protocolo, establezca la IP y el puerto del listener, y revise el tiempo de espera del cliente (el valor predeterminado documentado es 50000 ms).
8. Agregue las reglas HTTP bajo la regla de reenvío. Agregue una regla Forward que coincida con la ruta específica (por ejemplo /api) y apunte al grupo de destino del paso 1; ordene las reglas más específicas primero. Luego establezca una acción predeterminada (un reenvío al grupo de destino principal, o una respuesta fija Static) para el tráfico que no coincida con ninguna regla específica.
9. Provisione los cambios. El ALB valida el certificado durante el aprovisionamiento, por lo que un certificado que no sea una hoja RSA única coincidente fallará aquí en lugar de hacerlo de forma silenciosa.

Errores comunes:

• No reservar la IP pública primero. Un ALB público necesita al menos una IP de listener de IP Management antes de poder configurar el listener; resérvela antes de la construcción.
• Esperar renovación ACME gestionada en el ALB. El ALB solo consume certificados PEM importados; la ruta Auto Certificate (ACME) alimenta a CDN, no al ALB, por lo que planifique la rotación de certificados como una tarea manual y basada en calendario.
• Olvidar que la clave privada importada es inmutable. La rotación implica un nuevo recurso de certificado y reorientar el listener, nunca una edición de clave in situ.
• Intentar restringir el ALB con una lista de permisos o un NSG. El ALB no tiene ninguno; coloque reglas de firewall en las NIC de destino y confíe en la topología para mantener la capa de datos inalcanzable.
• Dejar el orden de las reglas al azar. Las reglas HTTP coinciden en orden con un valor predeterminado de paso; coloque las reglas específicas por encima de la regla general y establezca exactamente una acción predeterminada clara.
• Configurar una comprobación de estado HTTP en un grupo destinado a gRPC o WebSocket. La documentación prohíbe explícitamente combinarlos; elija la comprobación de estado que coincida con el protocolo del grupo.
• Tratar el ALB como una ruta de salida. No proporciona NAT de origen para los destinos; la salida privada pasa a través de la NAT Gateway de la Unidad 3.6.

Resumen

El Managed Application Load Balancer es el punto de acceso con conocimiento del contenido: selecciónelo cuando la enrutación deba leer hosts, rutas, encabezados o métodos HTTP, y deje la difusión pura de conexiones al NLB de la capa 4. Sus tres componentes (listener, regla de reenvío y grupo de destinos) se componen en un árbol de enrutación ordenado y con valores predeterminados que debe mantener deliberadamente ágil, porque las reglas y los listeners constituyen la superficie acotada y administrada del recurso. TLS se termina en el listener mediante un certificado RSA de hoja en formato PEM importado (la gestión ACME no se aplica aquí), el filtrado debe aplicarse en los destinos y no en un equilibrador que no tiene NSG ni lista de permitidos, y el ALB junto con el ingress dentro del clúster sustituyen a la API gateway que la plataforma no ofrece.

Puntos clave:

• Utilice el ALB cuando la lógica de equilibramiento deba procesar atributos HTTP; utilice el NLB cuando el trabajo pueda mantenerse en la capa 4 o cuando el cifrado de extremo a extremo deba llegar al backend.
• Cada ALB necesita al menos un listener (de 1 a 10 por ALB), una regla de reenvío y un grupo de destinos; un contrato está limitado a 5 ALBs.
• El ALB termina TLS (descarga de TLS) y admite SNI; la conexión con el backend puede ser HTTP en texto plano.
• Los certificados deben ser una única hoja RSA en formato PEM (ahora se permite una cadena completa, pero se rechaza solo CA o múltiples hojas), importados a través de Certificate Manager; el ALB no utiliza la ruta de Auto Certificate de ACME gestionada, y la clave privada importada no puede editarse después de su creación.
• El ALB no tiene listas de permitidos por IP ni NSG, y no proporciona NAT de origen; el filtrado debe aplicarse en los destinos y el tráfico saliente pasa a través de la NAT Gateway.
• La sustitución de la API gateway consiste en reglas de ruta y host del ALB en el punto de acceso, junto con el ingress dentro del clúster, manteniendo la configuración ágil para controlar la superficie de reglas y listeners.

Terminología importante:

• Descarga de TLS (terminación): el ALB descifra TLS en el listener para poder leer y enrutar según la solicitud HTTP, reenviando a los backends a través de HTTP en texto plano; por esta razón, el certificado reside en el ALB.
• Regla de reenvío y regla HTTP: una regla de reenvío vinculada a un listener contiene un conjunto ordenado de reglas HTTP (Forward, Redirect, Static); las solicitudes se comparan en orden y, si no hay coincidencia, se aplica una acción predeterminada.
• Grupo de destinos: un grupo reutilizable de destinos registrados (IP y puerto) con un algoritmo, pesos por destino y una comprobación de estado que el ALB realiza una vez que el grupo está vinculado a una regla de reenvío.

Lectura adicional

• Unidad 3.1: Topología y segmentación de VDC (la LAN de borde y la IP pública reservada en las que depende esta implementación)
• Unidad 3.2: Seguridad de red: Firewall y grupos de seguridad (por qué el filtrado se asocia a las NIC de destino, no al ALB)
• Unidad 3.4: Equilibrio de carga - Capa 4 (red) (el equilibrador privado que completa la estructura por capas)
• Unidad 6.2: Aprovisionamiento de un Cluster público (la mitad de entrada dentro del cluster de la sustitución de la API-gateway)