Unidad 8.3: Laboratorio de culminación: Construcción del núcleo empresarial de extremo a extremo

Introducción

Cada módulo anterior construyó una parte del entorno de FinCorp de forma aislada y mantuvo esa construcción deliberadamente minimalista. Esta unidad es donde las piezas se convierten en un sistema. Usted desplegará el núcleo de producción en un solo centro de datos virtual: la topología de tres niveles del Módulo 3, los equilibradores públicos de capa 7 y privados de capa 4, el clúster de PostgreSQL y la caché de In-Memory DB en el nivel de datos privado del Módulo 5, un clúster de Managed Kubernetes del Módulo 6, y las pasarelas híbridas de VPN y NAT que gestionan la transición.

El proyecto final no vuelve a enseñar cada construcción; hace referencia a la unidad que la realizó. Lo que añade es aquello que ninguna unidad individual podía mostrar: el orden de ensamblaje y las dependencias entre recursos. El fallo recurrente cuando estas construcciones se encuentran no es un valor de campo incorrecto, sino un orden incorrecto: un equilibrador creado antes de que existan sus destinos, una pasarela creada antes de que se reserve su IP pública, una base de datos a la que se le asigna una dirección que colisiona con DHCP. Si obtiene el orden correcto, la arquitectura de la Unidad 8.2 se vuelve real.

1. El orden de construcción es un grafo de dependencias, no una lista de verificación

La decisión más determinante en una construcción integrada es la secuencia. Varios recursos de IONOS CLOUD no pueden crearse, o no pueden funcionar, hasta que algo más exista primero, y la plataforma no siempre reordena el trabajo por usted. Trate la construcción como un grafo de dependencias y resuélvalo de abajo hacia arriba.

Cuatro reglas de ordenamiento concentran la mayor parte del riesgo, y cada una se estableció en una unidad anterior:

• Reserve las IP públicas primero. Un ALB público necesita al menos una IP de listener, el VPN Gateway y el NAT Gateway seleccionan cada uno desde direcciones reservadas, y la IP de entrada del LoadBalancer de Kubernetes debe reservarse para que la eliminación de un Service no la libere. La IPv4 reservada está vinculada a la región, por lo que debe reservarse en la región del VDC. Esta es la regla detrás de los errores comunes en las unidades 3.1, 3.3 y 3.6.
• El VDC y sus LAN preceden a todo lo demás. La topología de tres LAN de la unidad 3.1 es la base. Los servidores, las bases de datos, los equilibradores y las pasarelas se conectan a LAN que deben existir ya, con la dirección IP reservada para que los servicios gestionados y las pasarelas tengan espacio (el rango de .2 a .9 se mantiene libre, y la capa de datos se ubica en una dirección estática estable).
• Un equilibrador necesita sus destinos primero. El NLB privado de capa 4 de la unidad 3.4 distribuye hacia servidores de la capa de datos que deben estar ya aprovisionados en su LAN privada; un NLB apuntado a destinos que no existen no tiene nada hacia donde enrutar. Lo mismo aplica a los destinos de aplicación detrás del ALB de capa 7.
• La red híbrida precede a las cargas de trabajo que dependen de ella. El NAT Gateway debe existir y la ruta predeterminada de la LAN debe apuntar a él antes de que las cargas de trabajo privadas puedan alcanzar internet para la instalación de paquetes o llamadas de API salientes; el cambio de enrutamiento es el paso que los equipos olvidan.

Estas reglas producen un orden natural: sustrato de red, luego cómputo, luego la capa de datos, luego los equilibradores que la frontean, luego la plataforma de contenedores, y luego el borde híbrido. La guía de abajo sigue exactamente ese orden.

2. La arquitectura integrada que FinCorp está construyendo

El objetivo es la forma de capas canónica de la Unidad 1.2, ahora poblada con los productos específicos elegidos a lo largo del curso. La siguiente tabla asocia cada capa con su producto, la unidad en la que se construyó y la decisión de diseño detrás de la elección, de modo que la explicación pueda hacer referencia en lugar de repetir.

Todo esto se aloja en un solo VDC, en una sola región elegida en la Unidad 1.4 para cumplir con el RGPD y la residencia de BSI. La capa de datos nunca toca una LAN pública; las únicas superficies orientadas a internet son el ALB público y las IPs reservadas de las dos pasarelas.

Recorrido de implementación de DCD

Ensamblará el núcleo completo de FinCorp en el VDC creado en la Unidad 2.1, uniendo las construcciones de los Módulos 3, 5 y 6 en orden de dependencia. En lugar de repetir cada campo, cada paso indica la unidad que documenta la construcción detallada y solo establece lo que la integración añade: lo que debe existir ya, dónde se conecta y la única decisión que lo vincula con sus vecinos. Considere los recorridos por unidad como la referencia a nivel de campo y este como la secuencia de ensamblaje.

Objetivo de construcción: Construir el núcleo empresarial de FinCorp de extremo a extremo en el Data Center Designer, uniendo los recorridos de los módulos.

Requisitos previos: El VDC de FinCorp de la Unidad 2.1 con su región fijada; los privilegios Reserve IP Blocks y Create Kubernetes Clusters; un certificado PEM importado (hoja RSA única más clave coincidente) en el Certificate Manager para el listener HTTPS del ALB; y los detalles de conexión para el par IKEv2 del centro de datos corporativo.

Pasos (en el Data Center Designer):

1. Reservar las IP públicas (hágalo primero). En Menú > Network Services > IP Management, reserve direcciones IPv4 públicas en la región del VDC para: el listener público del ALB, el VPN Gateway, el NAT Gateway y el punto de entrada de Kubernetes. Recibirá direcciones del pool en lugar de elegirlas, y cada una está vinculada a la región. Este único paso inicial elimina el fallo de orden más común entre las Unidades 3.1, 3.3 y 3.6.

2. Construir la topología de tres LAN (como se construyó en la Unidad 3.1). En el VDC de FinCorp, cree la LAN de borde público (la única LAN conectada a Internet Access), la LAN de aplicaciones privada y la LAN de datos privada. Mantenga cada una con la subred predeterminada /24, deje libres las direcciones .2 a .9 para servicios gestionados y pasarelas, y no conecte ninguna LAN privada a internet. Esta segmentación es lo que permite que los equilibradores gestionados y la base de datos permanezcan seguros sin un NSG.

3. Provisionar los servidores de la capa de aplicación (como se construyó en la Unidad 4.1). Coloque los servidores de aplicación sin estado en la LAN de aplicaciones privada como servidores Dedicated Core. Dedicated Core es la elección deliberada para una garantía de rendimiento predecible bajo carga; la capa se mantiene sin estado para que los datos de sesión residan en la caché, no en el servidor, y para que VM Auto Scaling pueda agregar y eliminar réplicas libremente (Unidad 4.3).

4. Provisionar los servidores o puntos de entrada de la capa de datos en la LAN de datos privada. El equilibrador de capa 4 del paso 7 necesita objetivos que ya existan, por lo que los objetivos de la capa de datos deben estar presentes antes de crear el NLB. Asigne direcciones estáticas estables fuera del rango DHCP a las NIC de la capa de datos.

5. Construir el clúster de PostgreSQL (como se construyó en la Unidad 5.3). Bajo Menú > Databases > PostgreSQL, cree un clúster multinodo en la LAN de datos privada. Para el libro mayor de FinCorp, seleccione la replicación Strictly Synchronous con tres o más instancias, establezca una ventana de mantenimiento real fuera de las horas pico y asigne una IP privada que termine entre .3 y .10 para que nunca colisione con DHCP. No hay punto de entrada público ni réplica de solo lectura; esa brecha se cubre en el siguiente paso.

6. Construir la caché de In-Memory DB (como se construyó en la Unidad 5.5). Bajo Menú > Databases > In-Memory DB, cree la caché en la misma LAN de datos privada con una única conexión privada. Esta es la mitad de escalado de lecturas del patrón sin réplica de lectura y el almacén de estado externalizado que hace segura la escalabilidad automática de la capa de aplicación. Dimensione por RAM según el conjunto de trabajo; capture las credenciales en la creación porque no pueden cambiarse después.

7. Construir el NLB privado de capa 4 frente a la capa de datos (como se construyó en la Unidad 3.4). Coloque un Network Load Balancer con ambas interfaces en LAN privadas: el listener en la LAN de aplicaciones, el backend en la LAN de datos. Agregue los servidores de la capa de datos, que ya existen, como objetivos con una regla de reenvío TCP y una comprobación de estado TCP. El NLB no termina TLS, por lo que el certificado permanece en el backend; este es el extremo privado de la ruta por capas.

8. Construir el ALB público de capa 7 en el borde (como se construyó en la Unidad 3.3). Cree primero el grupo de objetivos de servidores de aplicación, luego coloque un Application Load Balancer con su interface norte en Internet Access y su interface sur en la LAN de aplicaciones. Configure el listener HTTPS en la IP pública reservada del paso 1 con el certificado PEM importado, agregue una regla de reenvío basada en ruta que apunte al grupo de objetivos y ordene las reglas específicas por encima de la predeterminada. El ALB termina TLS y da su mitad de borde a la sustitución de la puerta de enlace de API; no tiene lista de permisos ni NSG, por lo que el filtrado permanece en las NIC de destino.

9. Construir el clúster de Managed Kubernetes (como se construyó en la Unidad 6.2). Bajo Menú > Containers > Managed Kubernetes, cree un clúster público con un plano de control respaldado por Frankfurt para mantener los datos del plano de control en Alemania, luego agregue un pool de nodos Dedicated Core. Conecte la LAN del pool de nodos del clúster dentro del mismo VDC. Reserve la IP de entrada del paso 1, despliegue un controlador de entrada dentro del clúster expuesto como un Servicio LoadBalancer único fijado a esa IP, y recuerde que un Servicio LoadBalancer es una IP estática de un solo nodo, no un equilibrador gestionado; la capa 7 real frente al clúster es el ALB del paso 8.

10. Construir el NAT Gateway para salida privada (como se construyó en la Unidad 3.6). Agregue un NAT Gateway, conéctelo a la LAN de aplicaciones privada, asígnele una IP pública reservada del paso 1 y cree una regla SNAT para la subred de aplicaciones. Luego establezca la ruta predeterminada de la LAN privada (0.0.0.0/0) hacia la pasarela; sin este cambio de enrutamiento, la salida nunca ocurre silenciosamente. NAT es solo SNAT, por lo que no proporciona ninguna ruta de entrada. Agregue una regla SNAT UDP para que DNS siga resolviéndose para las VM que usan la ruta predeterminada de NAT.

11. Construir el VPN Gateway y el túnel al centro de datos corporativo (como se construyó en la Unidad 3.6). Cree un VPN Gateway IKEv2 en su IP pública reservada, conéctelo a la LAN privada con una dirección de pasarela en el rango .2 a .9, luego cree un túnel al par corporativo con un PSK fuerte y parámetros de fase 1 y fase 2 coincidentes. Liste las CIDR de la red en la nube y del par como el contrato de enrutamiento estático; no hay BGP. Seleccione la variante de la capa High Availability para que el par activo-pasivo comparta la única IP de la pasarela.

12. Provisionar y validar todo el VDC. Provisione los cambios acumulados. Valide la ruta por capas de extremo a extremo: un cliente alcanza el ALB en su IP pública mediante HTTPS, la capa de aplicación lee a través de la caché y recurre a PostgreSQL ante un fallo, el NLB distribuye las conexiones cifradas a la capa de datos, las cargas de trabajo privadas alcanzan internet solo a través del NAT Gateway, y el centro de datos corporativo alcanza las LAN privadas solo a través del túnel VPN. La capa de datos es inalcanzable desde ningún lugar público.

Errores comunes:

• Construir un consumidor antes de que exista su IP reservada. El listener del ALB, ambas pasarelas y la entrada de Kubernetes esperan todas una dirección reservada; reserve todas en el paso 1, en la región correcta, antes de que algo las consuma.
• Crear el NLB antes de que existan los objetivos de la capa de datos. Un equilibrador apuntado a objetivos ausentes enruta a nada; provisione la capa de datos (paso 4) antes que el NLB (paso 7).
• Apuntar el NAT Gateway a lo incorrecto, o olvidar la ruta predeterminada. NAT es solo SNAT sin ruta de entrada, y la pasarela no hace nada hasta que la ruta predeterminada de la LAN privada se redirija hacia ella. Agregue también la regla SNAT UDP, o DNS se romperá para esas VM.
• Tratar el Servicio LoadBalancer de Kubernetes como la puerta de entrada real del clúster. Es una IP estática de un solo nodo limitada al rendimiento de ese nodo; la entrada de capa 7 de producción es el ALB provisionado por separado, con el controlador de entrada dentro del clúster detrás de él.
• Colocar el plano de control de Kubernetes en un centro de datos de EE. UU. para esta carga de trabajo regulada. Elija el plano de control de Frankfurt para que los datos del plano de control permanezcan en Alemania; los datos del pool de nodos permanecen en la región elegida sin importar.
• Conectar una LAN privada a internet "para probar", o intentar envolver un ALB o NLB gestionado en un Network Security Group. Los equilibradores gestionados no tienen NSG; la seguridad de la capa de datos proviene enteramente de residir en una LAN privada, por lo que una única conexión a internet en la LAN de datos desmonta el argumento de cumplimiento.
• Dar al clúster de PostgreSQL o a la caché una dirección dentro del rango DHCP. Reutilice los tres primeros octetos de la LAN y elija una dirección que DHCP nunca asigne (terminando en .3 a .10); una colisión produce fallos de conexión intermitentes y difíciles de diagnosticar.
• No hacer coincidir los parámetros de fase 1 o fase 2 de VPN entre la pasarela de IONOS CLOUD y el par corporativo, o buscar una opción IKEv1. No hay IKEv1; los parámetros deben coincidir exactamente en ambos extremos o el túnel nunca se establece, y el par HA presenta una única IP compartida al par.

Resumen

El núcleo de FinCorp es ahora un solo VDC que materializa la arquitectura por capas de la Unidad 1.2: un ALB de capa 7 público que termina TLS en el borde, una capa de aplicación Dedicated Core sin estado, un NLB de capa 4 privado, y una capa de datos solo privada compuesta por un clúster de PostgreSQL estrictamente síncrono, precedido por una caché de In-Memory DB, con un clúster de Managed Kubernetes y las pasarelas híbridas de VPN y NAT conectadas. La lección del proyecto final no es ningún valor de campo individual; esos se establecieron en las construcciones por módulo. La lección es que un entorno integrado es un grafo de dependencias, y que construir de abajo hacia arriba (IPs, luego LANs, luego cómputo, luego datos, luego equilibradores, luego contenedores, luego el borde híbrido) es lo que convierte un conjunto de construcciones individuales correctas en una arquitectura de producción coherente y conforme.

Puntos clave:

• El orden de construcción es un grafo de dependencias: reserve primero las IPs públicas, cree las LANs antes de que algo se conecte, aprovisione los destinos antes del equilibrador que los sirve, y redirija la ruta predeterminada antes de esperar la salida a través de NAT.
• La capa de datos nunca toca una LAN pública; la segmentación, no un NSG, es lo que protege a los equilibradores administrados y a la base de datos, porque los equilibradores administrados no tienen NSG.
• El clúster de PostgreSQL no tiene réplica de lectura; la caché de In-Memory DB es la sustitución para el escalado de lectura y el estado externalizado que permite a la capa de aplicación escalar y hacer conmutación por error de forma segura.
• El servicio LoadBalancer del clúster de Kubernetes es una IP estática de un solo nodo, no el punto de entrada de producción; el ALB público más un controlador de entrada dentro del clúster es la verdadera puerta de entrada de capa 7, y un plano de control en Frankfurt mantiene los datos del plano de control en Alemania.
• El proyecto final hace referencia a cada unidad por módulo en lugar de repetirla: los laboratorios por módulo esbeltos existen para que este laboratorio de integración pueda llevar la síntesis.

Lectura adicional

• Unidad 8.2: La arquitectura empresarial de referencia (el diseño que este laboratorio implementa)
• Unidades 3.1, 3.3, 3.4, 3.6: las configuraciones de red y equilibrado de carga integradas aquí
• Unidades 5.3, 5.5: el clúster relacional y la caché en la capa de datos privada
• Unidad 6.2: la configuración del clúster público de Managed Kubernetes
• Unidad 7.1: la implementación de resiliencia y conmutación por error sobre este núcleo