Este documento explica qué es Ingress, por qué existen tres puntos de entrada en nuestro clúster y cómo encaja con el resto de capas (MetalLB, DNS, VPN y cert-manager).
No es un manual de despliegue. Para eso existen los documentos técnicos de cada controlador.
Dentro de Kubernetes, una aplicación vive en pods que pueden moverse entre nodos.
Eso significa que:
Necesitamos un punto de entrada estable que:
👉 Ese rol lo cumple Ingress.
Ingress es una forma declarativa (YAML) de decir:
app.ejemplo.com…”miapp…”Pero Ingress por sí solo no funciona.
Necesita un componente que lo ejecute:
👉 el Ingress Controller.
En nuestro caso, el controller es NGINX Ingress.
Podríamos tener un solo Ingress para todo.
Pero eso mezcla:
Eso es peligroso y difícil de controlar.
Por eso se separó en tres controladores.
| IngressClass | Red asociada | Uso principal |
|---|---|---|
nginx |
br-admin | Paneles y servicios internos de administración |
nginx-srv |
br-servicios | Apps accesibles desde la VPN de servicios |
nginx-inet |
br-admin (publicado por NAT) | Servicios expuestos a Internet |
👉 No hay un “único punto de entrada”: hay entradas separadas y controladas.
En nuestra arquitectura, la cadena típica es:
En resumen:
Para que alguien llegue, hace falta que un nombre apunte a la IP correcta.
La VPN define desde dónde puedes acceder:
nginx (br-admin) y a servicios internos.nginx-srv (br-servicios).En el Ingress público (nginx-inet) se usa normalmente Let’s Encrypt.
En los Ingress internos se puede:
La clave conceptual:
👉 No todos los Ingress son “Internet”. Depende de la red y del DNS.
En este clúster, los controladores Ingress suelen exponerse con IPs fijas (MetalLB).
Esto ayuda a:
Ejemplo mental:
Después de leer esto, alguien que empieza debe quedarse con:
A partir de aquí, cada controlador tiene su documento técnico:
nginx (admin / br-admin)nginx-srv (servicios / br-servicios)nginx-inet (internet / NAT)Estos documentos explican:
Separación por capas: IP (MetalLB) → entrada HTTP (Ingress) → aplicación (Service/pods).