Volúmenes

En Kubernetes, un volumen es una forma de proporcionar almacenamiento persistente a los pods y sus contenedores. Los volúmenes permiten que los datos persistan más allá de la vida de un pod individual (ya que los pods son efímeros y sus datos locales se pierden cuando son eliminados).

📦 Tipos de volúmenes en Kubernetes

Kubernetes soporta distintos tipos de volúmenes dependiendo del caso de uso y del proveedor de infraestructura.

1. emptyDir:

   • Crea un volumen vacío cuando el pod se inicializa.

   • Se borra cuando el pod muere.

   • Útil para almacenamiento temporal (caches, etc.).

2. hostPath:

   • Monta una carpeta del nodo físico (host) dentro del contenedor.

   • No es recomendable para producción, pero útil para pruebas locales.

3. nfs:

   • Monta un volumen compartido a través de un servidor NFS externo.

4. persistentVolumeClaim (PVC):

   • Solicita almacenamiento persistente a través de un PersistentVolume.

   • Es la forma estándar de montar almacenamiento duradero en Kubernetes.

5. configMap / secret:

   • Permiten montar configuraciones o secretos como archivos dentro de los pods.

6. cloud-specific (AWS EBS, GCE Persistent Disk, Azure Disk):

   • Volúmenes gestionados por proveedores cloud que pueden ser montados como almacenamiento persistente.

---

✅ Ejemplos

📝 Pod con volumen emptyDir

apiVersion: v1
kind: Pod
metadata:
  name: mypod-emptydir
spec:
  containers:
  - name: app
    image: httpd
    volumeMounts:
    - mountPath: /usr/local/apache2/htdocs  # Aquí se montará el volumen
      name: web-content
  volumes:
  - name: web-content
    emptyDir: {}   # Volumen tipo "directorio vacío"

• Cuando el pod se crea, Kubernetes genera un directorio temporal en el nodo donde corre el pod.

• Ese directorio está disponible en /usr/local/apache2/htdocs/ dentro del contenedor de httpd.

• Los datos se mantienen mientras el pod esté vivo, pero se eliminan cuando el pod muere o se borra.

Para almacenamiento temporal de archivos o cachés.

Para compartir datos entre múltiples contenedores dentro del mismo pod.

Como espacio de trabajo para procesos batch o temporales.

📝 Pod con hostPath

apiVersion: v1
kind: Pod
metadata:
  name: mypod-hostpath
spec:
  containers:
  - name: app
    image: httpd
    volumeMounts:
    - mountPath: /usr/local/apache2/htdocs   # Dentro del contenedor
      name: web-content
  volumes:
  - name: web-content
    hostPath:
      path: /data/httpd                  # Ruta en el nodo físico
      type: DirectoryOrCreate            # Crea el directorio si no existe

• El contenedor de httpd montará el directorio /data/nginx del host físico en /usr/local/apache2/htdocs/ dentro del contenedor.

• Todo lo que escribas o leas dentro de /usr/local/apache2/htdocs/ se reflejará en /data/httpddel nodo.

• Si el directorio /data/httpdno existe, Kubernetes lo creará automáticamente porque usamos type: DirectoryOrCreate.

Es útil para entornos de desarrollo o pruebas locales.

En producción, no es recomendable, ya que acopla los pods a un nodo específico.

hostPath puede ser peligroso si no se controla bien, ya que accede directamente al sistema de archivos del host.

📝 Pod con volumen nfs

apiVersion: v1
kind: Pod
metadata:
  name: mypod-nfs
spec:
  containers:
  - name: app
    image: httpd
    volumeMounts:
    - mountPath: /usr/local/apache2/htdocs  # Ruta dentro del contenedor
      name: nfs-volumen
  volumes:
  - name: nfs-volumen
    nfs:
      server: 192.168.1.100       # IP del servidor NFS
      path: /exports/web-content  # Ruta compartida en el NFS

• El pod monta el directorio remoto /exports/web-content de un servidor NFS con IP 192.168.1.100.

• Todo lo que el contenedor httpd lea o escriba en /usr/local/apache2/htdocs/ se guardará en el servidor NFS.

• Este volumen puede ser compartido por varios pods al mismo tiempo, lo que lo hace útil para entornos donde múltiples aplicaciones necesitan acceder al mismo almacenamiento.

Servir archivos estáticos desde un punto común.

Compartir configuraciones, datos o resultados entre diferentes pods.

Montar un almacenamiento distribuido simple para apps legacy.

🗂️ Relación entre PersistentVolume (PV) y PersistentVolumeClaim (PVC)

• PersistentVolume (PV):
  Es el recurso que representa un bloque de almacenamiento real en el clúster, como un disco EBS, un disco local o un volumen NFS.

• PersistentVolumeClaim (PVC):
  Es una petición de almacenamiento por parte de un pod o aplicación. El PVC "reclama" un PV disponible según el tamaño y las características que necesita.

📝 1️⃣ PersistentVolume (PV)

Manifiesto PV NFS -> nfs-pv.yaml

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  nfs:
    path: /mnt/nfs_share
    server: <IP_DEL_SERVIDOR_NFS>

Manifiesto PVC que usa PV anterior -> nfs-pvc.yaml

📝 2️⃣ PersistentVolumeClaim (PVC)

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mypvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

📝 3️⃣ Pod que usa el PVC

apiVersion: v1
kind: Pod
metadata:
  name: mypod-pvc
spec:
  containers:
  - name: app
    image: httpd
    volumeMounts:
    - mountPath: /usr/local/apache2/htdocs
      name: volumen-persistente
  volumes:
  - name: volumen-persistente
    persistentVolumeClaim:
      claimName: mypvc

• El PV define el volumen físico (en este caso /data/mypv en el host).

• El PVC es la solicitud que hace el Pod para "reclamar" ese volumen.

• El Pod monta ese PVC en /usr/local/apache2/htdocs/ y todo lo que escriba allí será persistente, incluso si el pod es eliminado y recreado.

Este ejemplo usa hostPath para el PV (solo recomendable para entornos de pruebas o dev).

En producción lo ideal es que el PV sea de un tipo como: nfs, awsElasticBlockStore, gcePersistentDisk, cephfs, etc.

StorageClass

✅ StorageClasses permiten almacenamiento dinámico en Kubernetes.
✅ Diferentes provisioners ofrecen distintas opciones de almacenamiento.
✅ Facilitan la gestión automática de volúmenes sin intervención manual.