Volúmenes persistentes y solicitudes de almacenamiento

Los Pods nacen y desaparecen, pero los datos de su aplicación a menudo deben perdurar. Piense en una base de datos o en archivos cargados por los usuarios.

• Cuando un Pod se reinicia o se reprograma, se pierden todos los datos almacenados directamente en el sistema de archivos de su contenedor.
• Esta naturaleza efímera es adecuada para aplicaciones sin estado, pero los datos críticos necesitan una solución duradera.
• Kubernetes proporciona un sistema potente para gestionar almacenamiento persistente que sobrevive al ciclo de vida de los Pods.

Un PersistentVolume (PV) es una unidad de almacenamiento dentro de su clúster de Kubernetes.

• Es un recurso cuyo ámbito es el clúster, lo que significa que no pertenece a ningún namespace específico.
• Los PV los aprovisiona un administrador o se aprovisionan dinámicamente mediante una StorageClass.
• Abstraen los detalles de la tecnología de almacenamiento subyacente (por ejemplo, Google Persistent Disk, AWS EBS o un recurso compartido NFS).

Los PV se definen con detalles como la capacidad, los modos de acceso y el tipo de almacenamiento. Este YAML describe un PV mediante hostPath (para pruebas locales) con 5 gigabytes de almacenamiento.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-local-pv
spec:
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  hostPath:
    path: "/mnt/data"

Nota: hostPath se utiliza normalmente para el desarrollo en un solo nodo y no se recomienda en producción.

Un PersistentVolumeClaim (PVC) es una solicitud de almacenamiento realizada por un usuario o una aplicación dentro de un namespace específico.

• Los Pods no consumen PV directamente; solicitan almacenamiento mediante un PVC.
• Los PVC tienen ámbito de namespace, por lo que se encuentran dentro del área de un proyecto o equipo específico.
• Especifican el tamaño deseado, los modos de acceso y, opcionalmente, una clase de almacenamiento.

Kubernetes vincula automáticamente un PVC con un PV disponible mediante un proceso llamado binding.

• Cuando se crea un PVC, Kubernetes busca un PV que cumpla sus requisitos (tamaño, modos de acceso y clase de almacenamiento).
• Cuando encuentra un PV adecuado, ambos quedan "vinculados" en una relación uno a uno.
• Este vínculo garantiza que el PVC obtenga el almacenamiento específico que solicitó.

Los modos de acceso definen cómo pueden montarse y utilizarse los volúmenes por parte de los Pods. Los PVC solicitan estos modos y los PV los admiten:

• ReadWriteOnce (RWO): El volumen puede montarse con permisos de lectura y escritura en un solo nodo.
• ReadOnlyMany (ROX): El volumen puede montarse como de solo lectura en varios nodos.
• ReadWriteMany (RWX): El volumen puede montarse con permisos de lectura y escritura en varios nodos.

La disponibilidad de estos modos depende del proveedor de almacenamiento específico.

Las Storage Classes ofrecen una forma de describir "clases" de almacenamiento (por ejemplo, "fast-ssd" y "slow-hdd").

• En lugar de crear PV manualmente, una StorageClass puede aprovisionar dinámicamente un PV cuando un PVC lo solicita.
• Esto automatiza la creación de PV según plantillas predefinidas.
• Separa el aprovisionamiento del almacenamiento de su consumo, lo que facilita su uso.

Vamos a crear un PVC que solicite 1 gigabyte de almacenamiento con acceso ReadWriteOnce. Este PVC buscará un PV existente o activará el aprovisionamiento dinámico mediante una StorageClass.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-app-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  storageClassName: standard # Optional: if you have a 'standard' StorageClass

Guarde esto como pvc.yaml y aplíquelo con kubectl apply -f pvc.yaml.

Una vez vinculado un PVC, un Pod puede utilizarlo haciendo referencia al nombre del PVC en su configuración de volúmenes. El Pod no necesita conocer el PV subyacente, solo el PVC.

apiVersion: v1
kind: Pod
metadata:
  name: my-data-pod
spec:
  containers:
    - name: data-container
      image: busybox
      command: ["/bin/sh", "-c", "echo 'Hello from CoddyKit!' > /mnt/data/hello.txt && sleep 3600"]
      volumeMounts:
        - name: persistent-storage
          mountPath: /mnt/data
  volumes:
    - name: persistent-storage
      persistentVolumeClaim:
        claimName: my-app-pvc

Este Pod escribirá un archivo en el volumen persistente montado.

Puede supervisar el estado de sus recursos de almacenamiento persistente mediante kubectl:

• Para ver todos los PV: kubectl get pv
• Para ver todos los PVC de su namespace: kubectl get pvc
• Para obtener información detallada, incluidos el estado y los eventos:
• kubectl describe pv <pv-name>
• kubectl describe pvc <pvc-name>

Asegúrese de que sus PV tengan el estado Bound y que los PVC estén vinculados al PV correcto.

Un usuario quiere implementar una base de datos que necesita 50 GB de almacenamiento persistente. ¿Qué recurso de Kubernetes representa directamente la solicitud de este almacenamiento por parte de la aplicación del usuario?

Hemos visto cómo Kubernetes gestiona el almacenamiento duradero de sus aplicaciones:

• Los PersistentVolumes (PV) son recursos del clúster que representan el almacenamiento real.
• Los PersistentVolumeClaims (PVC) son solicitudes de almacenamiento de los usuarios.
• Kubernetes vincula los PVC con PV adecuados según los requisitos.
• Los modos de acceso definen cómo puede utilizarse el almacenamiento (RWO, ROX y RWX).
• Las Storage Classes permiten el aprovisionamiento dinámico de PV y automatizan la configuración.

Este sistema garantiza que los datos de su aplicación persistan aunque los Pods se creen y desaparezcan, lo que proporciona fiabilidad a las aplicaciones con estado.