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

Introducción

Un equilibrador de carga de capa 7 es el punto donde la red deja de mover paquetes y comienza a leer solicitudes. Esa es la decisión que gobierna esta unidad: si su arista necesita entender HTTP (hosts, rutas, encabezados, métodos) lo suficientemente bien como para enrutar en ellos, o si solo necesita distribuir conexiones TCP en un grupo. El IONOS Managed Application Load Balancer (ALB) es la opción consciente del contenido, y también es donde la plataforma sustituye un producto que no vende, un API Gateway gestionado, exponiendo reglas de enrutamiento en su lugar. Esta unidad comienza en esa decisión de enrutamiento y sus consecuencias de certificado y costo, y termina construyendo el ALB público que se encuentra frente al nivel de aplicación de FinCorp en el Data Center Designer, sentado en el borde público LAN establecido en la Unidad 3.1.

1. Cuando la capa 7 gana su lugar

El Managed Application Load Balancer distribuye el tráfico de capa de aplicación entrante a los objetivos según las políticas definidas por el usuario, operando en la capa 7 del modelo OSI. El Equilibrador de carga de red (NLB), cubierto en la Unidad 3.4, opera en la capa 4. La guía oficial establece una línea clara: si su lógica de equilibrio de carga necesita procesar solicitudes HTTP y sus atributos, use el ALB; si el rendimiento de enrutamiento es crítico y la lógica puede permanecer en la capa 4, enruté el tráfico TCP con el NLB.

El ALB gana su lugar cuando se enruta en función del contenido de la solicitud en lugar de la conexión. Sus reglas de reenvío admiten enrutamiento basado en ruta, hostname, cadena de consulta, encabezado, método, cookie, origen IP, redirección de URL y respuesta fija o estática. Un punto de entrada público puede enviar /api a un grupo de objetivos y /static a otro, servir dos nombres de host desde un IP, o devolver una respuesta fija 503 durante el mantenimiento, todas decisiones a las que un equilibrador de carga de capa 4 es ciego. El intercambio es que cada solicitud se analiza y coincide, lo que explica por qué el NLB se reserva para casos en los que ese trabajo es innecesario: tráfico cifrado de extremo a extremo que el equilibrador no debe descifrar, o cualquier protocolo que no sea HTTP. La aplicación regulada de FinCorp tiene un portal del cliente y una superficie API que comparten un nombre de host y certificado, por lo que la capa 7 es el borde correcto; el nivel de base de datos privada permanece en la capa 4. Esta es la forma pública de capa 7 a capa 4 privada desde la Unidad 1.2.

Tres límites de plataforma dan forma a cómo se segura y dimensiona el ALB, y los tres son entradas de diseño en lugar de defectos:

• El ALB no tiene lista de permitidos de IP y no tiene Grupo de seguridad de red. Como se estableció en la Unidad 3.2, los NSG y los firewalls de NIC se unen a las NIC del servidor en el nivel VDC solo y no se aplican a los equilibradores gestionados. El filtrado, por lo tanto, pertenece a los objetivos: reglas Firewall en las NIC de backend más lógica de aplicación, con el nivel de datos mantenido inaccesible por topología.
• El ALB no proporciona origen NAT para conexiones de objetivos, por lo que no es una ruta de salida. Las cargas de trabajo privadas llegan a Internet a través de la puerta NAT en la Unidad 3.6.
• IPv6 tiene limitaciones documentadas en el ALB, por lo que trate al oyente público como un punto final IPv4 en una dirección IPv4 pública reservada y planifique cualquier exposición IPv6 por separado.

No hay producto IONOS API Gateway. El mecanismo de sustitución de la plataforma es exactamente lo que esta unidad construye: las reglas de reenvío del ALB llevan un enrutamiento de contenido grueso (reglas de ruta y host, redirecciones, respuestas fijas) en el borde, y un controlador de entrada en Cluster lleva un enrutamiento más fino y consciente de la aplicación dentro de un Kubernetes Cluster detrás de él. Usted compone el comportamiento de la puerta API a partir de un equilibrador de carga gestionado más un controlador de entrada en Cluster en lugar de aprovisionar un producto de puerta única.

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

Cada ALB requiere al menos un oyente, una regla de reenvío y un grupo de destino. Comprender qué hace cada uno y qué cuesta cada uno es lo que mantiene un diseño de capa 7 ajustado.

La siguiente tabla resume los tres componentes y sus roles.

El algoritmo de equilibrio de carga predeterminado es Round Robin; los algoritmos disponibles son Round Robin, Menos Conexiones, Aleatorio y Origen IP. El pesado por destino (un peso en el rango 1 a 256) le permite sesgar la distribución, lo que es el mecanismo para un canario ponderado en la capa 7.

Los componentes se componen jerárquicamente, y esa jerarquía es donde importa la disciplina de las reglas. Un oyente 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 cae en una acción predeterminada cuando ninguna coincide. Así que coloca las reglas más específicas primero y la regla de captura de todo lo último, con una acción predeterminada clara por oyente (a menudo un reenvío al grupo de destino principal o una respuesta fija).

Mantenga el conjunto de reglas ajustado por una razón más allá de la claridad: las reglas y los oyentes son la superficie administrada del ALB, y un conjunto desbordado es una responsabilidad operativa. Un ALB tiene un límite de 10 oyentes y un contrato de 5 ALB, por lo que el recurso está deliberadamente limitado. La disciplina es expresar el enrutamiento con las reglas correctas más pocas, empujar el enrutamiento detallado a la entrada en-Cluster donde corresponde, y reutilizar los grupos de destino en las reglas en lugar de duplicarlos.

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

El ALB realiza la descarga de TLS: termina TLS en el listener para que la conexión de backend pueda ser texto plano HTTP. Este es el patrón normal de la capa 7 y es por eso que el certificado vive en el ALB, no en los objetivos. El ALB también admite SNI, por lo que un listener puede presentar el certificado correcto para varios nombres de host. (Cuando el backend debe mantener el certificado y el equilibrador no debe descifrar, ese es el caso de la capa 4 en la Unidad 3.4, no una configuración de ALB).

Las restricciones de certificado son específicas y son la parte más probable de fallar en un primer intento de aprovisionamiento, por lo que la obtención del certificado debe ser deliberada. El ALB requiere exactamente un certificado de hoja (entidad final) y la clave debe ser RSA. A partir de la documentación de 2026-06, los certificados de autoridad de certificación intermedia y raíz pueden incluirse junto con la hoja en el mismo archivo, por lo que ahora se permite una cadena completa; lo que se rechaza es proporcionar solo certificados de autoridad de certificación, o más de una hoja. La clave pública de la hoja debe coincidir con la clave privada suministrada, y la clave privada debe ser una sola clave RSA en formato PKCS#1 (RSA PRIVATE KEY) o PKCS#8 (PRIVATE KEY).

El Certificate Manager ofrece dos caminos, y solo uno alimenta al ALB. El ALB consume solo certificados importados: usted sube el certificado, la cadena y la clave privada como PEM, y adjunta el recurso resultante al listener. El camino 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, enumera CDN como su consumidor descendente, no el ALB. Por lo tanto, no puede confiar en la renovación automática de ACME para un listener de ALB; usted importa un certificado PEM y es dueño de su rotación. Una restricción sigue: en un certificado importado, la clave privada se establece en la creación y no se puede editar, por lo que la rotación significa crear un nuevo recurso de certificado y reenviar el listener, no editar la clave en su lugar. Incorpore eso en el libro de renovación. Para FinCorp, el portal y API comparten un nombre de host y un certificado PEM de hoja RSA importado terminado en el ALB, y la renovación es un intercambio impulsado por el calendario.

Implementación de DCD: Guía paso a paso

Usted construirá el punto de entrada público de la capa 7 para la capa de aplicación de FinCorp: un ALB público en el borde LAN de la Unidad 3.1, con un listener HTTPS que termina TLS, un grupo de destino que apunta a los servidores de aplicación, una regla de reenvío basada en la ruta y una comprobación de salud HTTP. Esto realiza el extremo público de la arquitectura en capas y da a la sustitución de la puerta de enlace API su mitad de borde.

Objetivo de construcción: Construir un equilibrador de carga de capa 7 público con un listener HTTPS, grupo de destino, regla de reenvío y comprobación de salud.

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

Pasos (en el Data Center Designer):

1. Cree el grupo de destino primero. Vaya a Menú > Servicios de red > Grupos de destino y seleccione Crear. Asígnale 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 Destinos: para cada servidor de aplicación, ingrese su IP y el puerto de backend que escucha el servicio (el backend puede ser texto sin formato HTTP porque el ALB termina TLS). Establezca un peso por destino (1 a 256) si desea sesgar la distribución, por ejemplo, para un canario ponderado.
3. Agregue la comprobación de salud en la pestaña Conexión del grupo de destino. Para una comprobación de salud HTTP, establezca la Ruta (predeterminada /), el Método y el Tipo de coincidencia (Código de estado o Cuerpo de respuesta con una expresión regular opcional o negación). Tenga en cuenta que una comprobación de salud HTTP no debe estar configurada si planea utilizar 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 Aplicación al lienzo.
5. Conecte sus interfaces: conecte la interfaz norte a Acceso a Internet (el borde público) y la interfaz sur a la capa de aplicación LAN que contiene los destinos. Solo los equilibradores de carga públicos requieren una IPv4 pública y conectividad de internet; un ALB privado no requiere una IPv4 pública.
6. Configure el listener como HTTPS: asigne la dirección IPv4 pública reservada como la dirección IP del listener, establezca el puerto del listener (443 para HTTPS) y asocie el certificado PEM importado del Certificate Manager para que el ALB termine TLS en este listener.
7. Agregue la regla de reenvío en la pestaña Reglas de reenvío: asígnale un nombre, confirme el protocolo, establezca la dirección 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 debajo de la regla de reenvío. Agregue una regla de reenvío 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 estática) para el tráfico que no coincide con ninguna regla específica.
9. Proporcione los cambios. El ALB valida el certificado durante la provisión, por lo que un certificado que no sea una hoja RSA única coincidente fallará aquí en lugar de silenciar.

Errores comunes:

• No reservar la IPv4 pública primero. Un ALB público necesita al menos un listener IP de IP Management antes de que pueda configurar el listener; reserve antes de la construcción.
• Esperar una renovación de ACME administrada en el ALB. El ALB consume solo certificados PEM importados; el camino de certificado automático (ACME) alimenta CDN, no el ALB, así que planifique la rotación de certificados como una tarea manual y calendarizada.
• Olvidar que la clave privada importada es inmutable. La rotación significa un nuevo recurso de certificado y volver a señalar el listener, nunca una edición de clave en el lugar.
• Intentar bloquear el ALB con una lista de permitidos o NSG. El ALB no tiene ninguno; coloque reglas Firewall en las NIC de destino y confíe en la topología para mantener la capa de datos inaccesible.
• Dejar el orden de las reglas al azar. Las reglas HTTP coinciden en orden con un valor predeterminado de caída; coloque reglas específicas por encima de la regla de coincidencia y establezca exactamente una acción predeterminada clara.
• Configurar una comprobación de salud HTTP en un grupo destinado a gRPC o WebSocket. La documentación prohíbe explícitamente combinarlos; elija la comprobación de salud para coincidir con el protocolo del grupo.
• Tratar al ALB como una ruta de salida. No proporciona origen NAT para los destinos; la salida privada pasa por la puerta de enlace NAT en la Unidad 3.6.

Resumen

El Managed Application Load Balancer es el borde consciente del contenido: elija este cuando el enrutamiento debe leer los hosts, rutas, encabezados o métodos HTTP, y deje la propagación de conexión pura en el NLB de Capa 4. Sus tres componentes (oyente, regla de reenvío, grupo de destino) se componen en un árbol de enrutamiento ordenado y con respaldo predeterminado que usted mantiene deliberadamente delgado, porque las reglas y los oyentes son la superficie limitada y gestionada del recurso. El TLS se termina en el oyente en un certificado PEM de hoja RSA importado (el ACME gestionado no se aplica aquí), el filtrado pertenece a los objetivos en lugar de a un equilibrador que no tiene NSG ni lista de permitidos, y el ALB más el ingreso in-Cluster se unen para reemplazar el API Gateway que la plataforma no vende.

Puntos clave:

• Utilice el ALB cuando la lógica de equilibrio debe procesar atributos HTTP; utilice el NLB cuando el trabajo puede permanecer en la Capa 4 o cuando el cifrado de extremo a extremo debe llegar al backend.
• Cada ALB necesita al menos un oyente (1 a 10 por ALB), una regla de reenvío y un grupo de destino; un contrato está limitado a 5 ALB.
• El ALB termina TLS (descarga de TLS) y admite SNI; la conexión de backend puede ser texto plano HTTP.
• Los certificados deben ser una hoja RSA única en PEM (ahora se permite una cadena completa, se rechaza la CA solo o multi-hoja), importada a través del Certificate Manager; el ALB no consume el camino de certificado Auto ACME gestionado, y la clave privada importada no se puede editar después de la creación.
• El ALB no tiene lista de permitidos IP y no tiene NSG, y no proporciona origen NAT; el filtrado pertenece a los objetivos y la salida va a través de la puerta de enlace NAT.
• El reemplazo de puerta de enlace API es la regla de ruta y host ALB en el borde más el ingreso in-Cluster dentro del Cluster, mantenido delgado para controlar la superficie de regla y oyente.

Terminología importante:

• Descarga de TLS (terminación): el ALB descifra TLS en el oyente para que pueda leer y enrutar en la solicitud HTTP, reenviando a los backends sobre texto plano HTTP; esta es la razón por la que el certificado vive en el ALB.
• Regla de reenvío y regla HTTP: una regla de reenvío vinculada a un oyente mantiene un conjunto ordenado de reglas HTTP (Reenvío, Redirección, Estático); las solicitudes coinciden en orden y caen en una acción predeterminada.
• Grupo de destino: un grupo reutilizable de objetivos registrados (IP más puerto) con un algoritmo, pesos por objetivo y una comprobación de salud 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 (el borde LAN y los públicos reservados IP en los que depende esta construcción)
• Unidad 3.2: Seguridad de red: Firewall y grupos de seguridad (por qué el filtrado se une a las NIC de destino, no al ALB)
• Unidad 3.4: Equilibrio de carga - Capa 4 (Red) (el equilibrador privado que completa la forma en capas)
• Unidad 6.2: Provisionar un Cluster público (la mitad de ingreso en Cluster de la sustitución de la puerta de enlace API)