Para demostrar la viabilidad del entorno, el diseño se ha planteado aislando completamente los servicios. El objetivo es evitar el clásico punto único de fallo (SPOF) de los sistemas monolíticos y garantizar que el flujo de datos sea unidireccional y auditable.
1. Gestión perimetral (Ingress Controller)
Todo el tráfico externo entra a través del controlador Ingress de Kubernetes. Los contenedores no se exponen directamente a la red mediante NodePorts por motivos de seguridad. El Ingress actúa como proxy inverso y balanceador de capa 7, leyendo la ruta HTTP solicitada para decidir a qué Service interno derivar la petición.
2. Entrega de estáticos (Frontend — Nginx)
Si la petición es a la raíz del dominio, el Ingress enruta el tráfico al pod de Nginx. Se ha elegido Nginx por su bajísimo consumo de recursos al servir HTML y JavaScript. Este pod no mantiene comunicación lógica con la base de datos ni dispone de variables de entorno sensibles. Si el frontend se viera comprometido, el atacante no tendría posibilidad de pivotar hacia los datos.
3. Procesamiento y lógica (Backend — Node.js)
Cuando el cliente envía el formulario web, la petición asíncrona (POST /api/leads) vuelve a entrar por el Ingress, que la redirige exclusivamente al microservicio de Node.js. El backend actúa como la única barrera de validación: filtra el payload, aplica la lógica de negocio y evita inyecciones o peticiones mal formadas.
4. Persistencia segura (PostgreSQL)
Node.js es el único componente autorizado a nivel de red interna para comunicarse con el servicio de PostgreSQL. Utiliza las credenciales cifradas que el operador SealedSecrets inyecta dinámicamente en el pod. Se abre la conexión, se ejecuta la transacción SQL y, al confirmarse la escritura, el backend devuelve el código HTTP correspondiente al usuario.
Este nivel de desacoplamiento permite, por ejemplo, escalar a tres réplicas el contenedor de Nginx ante un pico de tráfico web, sin tener que duplicar innecesariamente la base de datos ni el backend.
Uno de los pilares del diseño ha sido evitar el antipatrón de desplegar todos los recursos en el entorno por defecto (default). Para estructurar el cluster se ha implementado una segmentación estricta mediante Namespaces.
| Namespace | Contenido |
|---|---|
default |
Frontend, Backend, PostgreSQL, pgAdmin |
monitoring |
Prometheus, Grafana, Alertmanager |
argocd |
ArgoCD |
kube-system |
SealedSecrets |
ingress-nginx |
NGINX Ingress Controller |
1. Aislamiento operativo: El Namespace monitoring se dedica exclusivamente al stack de observabilidad (Prometheus y Grafana). Esta separación garantiza que las herramientas de «Día 2» (operaciones) no interfieran con la carga de trabajo del negocio.
2. Reducción del radio de explosión (Blast Radius): Al separar entornos, una caída en cascada o un consumo excesivo de recursos por parte del recolector de métricas no afectará directamente a la disponibilidad del Ingress ni del backend de Node.js.
3. Eficiencia en la depuración y trazabilidad: La segmentación permite aislar el ruido al auditar el sistema o extraer logs de contenedores caídos. Un administrador puede monitorizar exclusivamente los eventos del Namespace de la aplicación sin verse inundado por los logs internos de las herramientas de monitorización.
4. Base para seguridad y cuotas (RBAC): Esta separación sienta las bases para aplicar un Control de Acceso Basado en Roles. Permite, por ejemplo, dar acceso de lectura a un operador técnico sobre el Namespace monitoring sin otorgarle permisos para modificar los pods de la base de datos de los clientes.
Siguiente: 3.3 Flujo GitOps y CI/CD →