Este documento explica el papel de NFS dentro de la arquitectura del clúster.
No es una guía técnica ni un manual de comandos.
Es una explicación de modelo.
En Kubernetes las aplicaciones son móviles.
Un pod puede:
Pero los datos no pueden ser móviles de forma arbitraria.
Si una aplicación guarda información en su propio contenedor y este desaparece:
👉 Los datos se pierden.
Por eso necesitamos almacenamiento persistente.
Y en muchos casos, además:
Kubernetes separa claramente:
La aplicación no sabe dónde están físicamente los discos.
Solo solicita:
"Necesito un volumen de este tipo."
Esa solicitud se gestiona mediante un concepto llamado StorageClass.
La StorageClass no almacena datos.
Define el tipo de almacenamiento que se usará cuando alguien lo pida.
NFS es un sistema de ficheros compartido muy conocido en entornos tradicionales.
Permite que varios sistemas accedan al mismo almacenamiento a través de la red.
En el contexto del clúster, NFS se utiliza cuando queremos:
En términos simples:
👉 NFS convierte una carpeta de un servidor en almacenamiento accesible para el clúster.
El modelo es sencillo:
Aplicación → Solicitud de volumen → StorageClass → Provisionador → Servidor NFS
Cuando una aplicación pide almacenamiento:
Todo ocurre de forma automática y declarativa.
La aplicación no necesita saber nada del servidor NFS.
Se puede levantar un servidor NFS sencillo dentro o fuera del clúster.
Es suficiente para:
Aquí prima la simplicidad.
El servidor NFS suele ser externo:
El clúster solo necesita el provisionador y la definición de la StorageClass.
Esto permite:
NFS no es la única solución posible.
En la arquitectura global también pueden existir:
Cada solución responde a un nivel distinto de complejidad y criticidad.
NFS ocupa el espacio de:
Después de leer este documento debe quedar claro que:
El almacenamiento no es solo un disco.
Es una decisión arquitectónica sobre cómo queremos que vivan y sobrevivan los datos.
Modelo simple hoy. Coherencia arquitectónica mañana.