Ku­be­r­ne­tes Pe­r­si­s­te­nt Volume: tipos y creación

Los Pe­r­si­s­te­nt Volumes (PV) en Ku­be­r­ne­tes de­sem­pe­ñan un papel crucial en la gestión eficiente de los datos en los clústeres de Ku­be­r­ne­tes. Abstraen los datos y permiten un al­ma­ce­na­mie­n­to coherente a lo largo de los ciclos de vida de los pods.

¿Qué es un Ku­be­r­ne­tes Pe­r­si­s­te­nt Volume?

Un Pe­r­si­s­te­nt Volume (PV) en Ku­be­r­ne­tes es un recurso fu­n­da­me­n­tal dentro de la or­que­s­ta­ción de Ku­be­r­ne­tes, diseñado para una gestión eficiente y escalable de datos en clústeres de co­n­te­ne­do­res. El propósito de un PV es pro­po­r­cio­nar un área de al­ma­ce­na­mie­n­to es­ta­n­da­ri­za­da y pe­r­si­s­te­n­te. Un PV puede ser utilizado por di­fe­re­n­tes pods, in­de­pe­n­die­n­te­me­n­te de los recursos de al­ma­ce­na­mie­n­to físico a los que acceda el clúster. Esto crea un nivel más alto de ab­s­tra­c­ción, separando los detalles de al­ma­ce­na­mie­n­to de la lógica de apli­ca­ción.

Los PV existen en forma estática y dinámica. En la forma estática, los recursos de al­ma­ce­na­mie­n­to están pre­de­fi­ni­dos ma­nua­l­me­n­te, mientras que en la forma dinámica los PV se crean au­to­má­ti­ca­me­n­te cuando un pod tiene re­qui­si­tos es­pe­cí­fi­cos de al­ma­ce­na­mie­n­to. Esta fle­xi­bi­li­dad garantiza una gestión eficiente de datos pe­r­si­s­te­n­tes en clústeres de Ku­be­r­ne­tes, lo que hace que las apli­ca­cio­nes sean robustas y es­ca­la­bles.

¿Cuál es la di­fe­re­n­cia entre volumen y volumen pe­r­si­s­te­n­te?

Existen dos tipos básicos de volúmenes de al­ma­ce­na­mie­n­to en Ku­be­r­ne­tes: volúmenes y volúmenes pe­r­si­s­te­n­tes. Un volumen normal está ligado a la vida útil de un único pod. Se declara di­re­c­ta­me­n­te en la co­n­fi­gu­ra­ción del pod y se utiliza pri­n­ci­pa­l­me­n­te para el al­ma­ce­na­mie­n­to temporal de datos durante la ejecución del pod asociado. Cuando el pod se termina, el volumen normal también se libera y todos los datos que contiene se eliminan.

Por el contrario, un Pe­r­si­s­te­nt Volume en Ku­be­r­ne­tes tiene una vida útil más larga y es in­de­pe­n­die­n­te de un pod es­pe­cí­fi­co. Puede ser reclamado y liberado por múltiples pods en di­fe­re­n­tes ciclos de vida. Los volúmenes pe­r­si­s­te­n­tes se declaran por separado de los pods y luego se vinculan a los Pe­r­si­s­te­nt Volume Claims (PVC). La vi­n­cu­la­ción entre un PVC y un PV se realiza de forma dinámica o manual. Los volúmenes pe­r­si­s­te­n­tes son ideales para datos que necesitan persistir más allá de la vida útil de un único pod y pro­po­r­cio­nan una forma de compartir y almacenar datos entre di­fe­re­n­tes pods, incluso si se crean o eliminan pods.

¿Qué tipos de volúmenes pe­r­si­s­te­n­tes existen?

En Ku­be­r­ne­tes existen di­fe­re­n­tes tipos de Pe­r­si­s­te­nt Volumes que re­pre­se­n­tan di­fe­re­n­tes so­lu­cio­nes y te­c­no­lo­gías de al­ma­ce­na­mie­n­to. Estos son algunos de los tipos más comunes de volúmenes pe­r­si­s­te­n­tes:

• hostPath: el tipo HostPath enlaza un volumen pe­r­si­s­te­n­te a una ruta en el nodo anfitrión en el clúster de Ku­be­r­ne­tes. Esto permite el acceso a los recursos de al­ma­ce­na­mie­n­to local del anfitrión y es adecuado para entornos de de­sa­rro­llo y prueba. Sin embargo, debe usarse con pre­cau­ción en entornos de pro­du­c­ción, ya que los datos no se replican entre los nodos.
• emptyDir: este tipo crea un volumen temporal y vacío cada vez que se crea un pod. Es adecuado para datos te­m­po­ra­les o el in­te­r­ca­m­bio de datos entre co­n­te­ne­do­res dentro del mismo pod. Sin embargo, el volumen se elimina cuando el pod se termina.
• GCEPersistentDisk, AWSElasticBlockStore, AzureDisk, AzureFile: estos tipos enlazan un volumen pe­r­si­s­te­n­te a so­lu­cio­nes de al­ma­ce­na­mie­n­to en la nube externas como Google Compute Engine Pe­r­si­s­te­nt Disks, Amazon EBS Volumes o Azure Disks y Azure File Shares. Ofrecen una manera de persistir datos entre pods e incluso entre clústeres y son adecuados para apli­ca­cio­nes im­ple­me­n­ta­das en entornos de nube.
• nfs (Network File System): los PV del tipo NFS se conectan a un recurso co­m­pa­r­ti­do de red pro­po­r­cio­na­do por el Network File System (NFS). Esto permite el uso co­m­pa­r­ti­do de datos entre di­fe­re­n­tes pods y es útil cuando varios pods necesitan acceder a archivos comunes.
• iscsi (Internet Small Computer System Interface): los PV basados en ISCSI se conectan a di­s­po­si­ti­vos de al­ma­ce­na­mie­n­to en bloque di­s­po­ni­bles a través del protocolo ISCSI. Es una forma de utilizar di­s­po­si­ti­vos de al­ma­ce­na­mie­n­to en bloque externos en clústeres de Ku­be­r­ne­tes y ofrece una solución flexible y escalable para datos pe­r­si­s­te­n­tes.
• local: el tipo local permite el acceso directo a los recursos de al­ma­ce­na­mie­n­to físico en el nodo local dentro del clúster de Ku­be­r­ne­tes. Esto es muy útil para apli­ca­cio­nes que dependen del al­ma­ce­na­mie­n­to local rápido. Sin embargo, se debe tener pre­cau­ción, ya que los recursos de al­ma­ce­na­mie­n­to local no se replican entre nodos y los datos pueden perderse si el nodo falla.
• csi (Container Storage Interface): el tipo CSI permite integrar pro­vee­do­res de al­ma­ce­na­mie­n­to externos a través del Container Storage Interface. Los sistemas de or­que­s­ta­ción de co­n­te­ne­do­res como Ku­be­r­ne­tes pueden co­mu­ni­car­se con diversas so­lu­cio­nes de al­ma­ce­na­mie­n­to externas. Esto crea fle­xi­bi­li­dad y permite el uso de una amplia gama de sistemas de al­ma­ce­na­mie­n­to co­m­pa­ti­bles con CSI.
• cephfs: CephFS es un sistema de archivos di­s­tri­bui­do y los volúmenes pe­r­si­s­te­n­tes del tipo CephFS están vi­n­cu­la­dos a este sistema de archivos di­s­tri­bui­do. Este tipo de PV se utiliza para apli­ca­cio­nes que requieren acceso co­m­pa­r­ti­do a archivos y operan en un entorno de al­ma­ce­na­mie­n­to di­s­tri­bui­do, como es el caso de Ceph.
• fc (Fibre Channel): los volúmenes pe­r­si­s­te­n­tes basados en FC están vi­n­cu­la­dos a di­s­po­si­ti­vos de al­ma­ce­na­mie­n­to tipo Fibre Channel. Este tipo permite acceder a so­lu­cio­nes de al­ma­ce­na­mie­n­to similares, pero externas. Es común en entornos donde se utilizan redes Fibre Channel para pro­po­r­cio­nar al­ma­ce­na­mie­n­to basado en bloques.
• rbd (RADOS Block Device): el tipo RBD se conecta a di­s­po­si­ti­vos de al­ma­ce­na­mie­n­to basados en bloques en el clúster Ceph, que funcionan como RADOS Block Devices. Este tipo ofrece la po­si­bi­li­dad de acceder al sistema de al­ma­ce­na­mie­n­to basado en bloques de Ceph, lo que tiene muchas ventajas en entornos de al­ma­ce­na­mie­n­to di­s­tri­bui­dos con alta es­ca­la­bi­li­dad.

Modos de acceso a los Pe­r­si­s­te­nt Volumes en Ku­be­r­ne­tes

En Ku­be­r­ne­tes, los modos de acceso a volúmenes pe­r­si­s­te­n­tes de­te­r­mi­nan cómo los pods pueden acceder a los volúmenes vi­n­cu­la­dos a ellos. Existen tres tipos pri­n­ci­pa­les de modos de acceso:

• ReadWriteOnce (RWO): este modo permite a un único pod montar el volumen pe­r­si­s­te­n­te si­mu­l­tá­nea­me­n­te en modo de lectura y escritura. Es útil para apli­ca­cio­nes que necesitan un control exclusivo de acceso de escritura. Un PV con este modo solo puede ser montado por un pod a la vez.
• ReadOnlyMany (ROX): ReadOnlyMany permite a varios pods montar el volumen pe­r­si­s­te­n­te si­mu­l­tá­nea­me­n­te en modo de solo lectura. Esto es útil para apli­ca­cio­nes que pueden compartir datos de manera conjunta pero con acceso de escritura re­s­tri­n­gi­do. Varios pods pueden acceder a los datos en paralelo, pero solo en modo de lectura.
• ReadWriteMany (RWX): con ReadWriteMany varios pods pueden montar el volumen pe­r­si­s­te­n­te si­mu­l­tá­nea­me­n­te tanto en modo de lectura como de escritura. Este modo se aplica en si­tua­cio­nes donde se necesita una base de datos co­m­pa­r­ti­da y varios pods pueden tener acceso de escritura a los datos.

Al definir el modo de acceso, debes tener en cuenta el tipo de acceso a datos que requiere tu apli­ca­ción y comprobar que el modo se­le­c­cio­na­do admite los modelos de acceso ne­ce­sa­rios.

Ten en cuenta que no todas las clases de al­ma­ce­na­mie­n­to y tipos de volumen admiten los tres modos de acceso. La co­m­pa­ti­bi­li­dad depende de la in­frae­s­tru­c­tu­ra de al­ma­ce­na­mie­n­to su­b­ya­ce­n­te y del tipo de volumen pe­r­si­s­te­n­te es­pe­cí­fi­co. Por lo tanto, es aco­n­se­ja­ble consultar la do­cu­me­n­ta­ción de la clase de al­ma­ce­na­mie­n­to y el tipo de volumen pe­r­si­s­te­n­te re­s­pe­c­ti­vos para ase­gu­rar­se de que se permiten los patrones de acceso deseados.

Ciclo de vida de un Pe­r­si­s­te­nt Volume (PV)

Los ciclos de vida de los Pe­r­si­s­te­nt Volumes en Ku­be­r­ne­tes pueden dividirse en di­fe­re­n­tes fases que re­pre­se­n­tan el proceso de provisión, uso y li­be­ra­ción del al­ma­ce­na­mie­n­to pe­r­si­s­te­n­te en el clúster.

1. Creación (Pro­vi­sio­ni­ng): el ciclo de vida de un PV comienza con su creación o apro­vi­sio­na­mie­n­to. Un ad­m­ni­s­tra­dor del clúster crea un volumen pe­r­si­s­te­n­te y lo configura de manera estática con recursos de al­ma­ce­na­mie­n­to fijos o de manera dinámica uti­li­za­n­do una clase de al­ma­ce­na­mie­n­to (Storage Class) que permite el apro­vi­sio­na­mie­n­to dinámico.
2. Vi­n­cu­la­ción (Binding): un PV se vincula a un PVC (Pe­r­si­s­te­nt Volume Claim) cuando un pod solicita un al­ma­ce­na­mie­n­to que coincide con las es­pe­ci­fi­ca­cio­nes del PV. Este paso asegura que el PV cumpla con los re­qui­si­tos de un pod es­pe­cí­fi­co.
3. Uso por parte del pod: después de completar el proceso de vi­n­cu­la­ción, el pod puede utilizar el PV. El pod puede leer o escribir en el volumen montado, según los modos de acceso es­ta­ble­ci­dos durante la creación del PV.
4. Fi­na­li­za­ción del uso: cuando un pod termina su servicio o se elimina, el PV asociado puede ser re­uti­li­za­do por otro pod. El PV permanece hasta que se elimina ma­nua­l­me­n­te o mediante una clase de al­ma­ce­na­mie­n­to dinámica.
5. Li­be­ra­ción (Release): cuando un pod termina su servicio o se elimina, el PV asociado puede ser re­uti­li­za­do por otro pod. El PV permanece hasta que se elimina ma­nua­l­me­n­te o mediante una clase de al­ma­ce­na­mie­n­to dinámica.
6. Eli­mi­na­ción: por último, también puedes eliminar un PV si ya no es necesario. Esto se puede hacer ma­nua­l­me­n­te o au­to­má­ti­ca­me­n­te si la re­pli­ca­ción de PV está co­n­fi­gu­ra­da por la clase de al­ma­ce­na­mie­n­to.

Crear un Pe­r­si­s­te­nt Volume en Ku­be­r­ne­tes

La creación de un Pe­r­si­s­te­nt Volume en Ku­be­r­ne­tes es un proceso de varias etapas que requiere una co­n­fi­gu­ra­ción cuidadosa.

Paso 1: co­n­fi­gu­ra­ción del Pe­r­si­s­te­nt Volume

El primer paso consiste en abrir un editor de texto y crear un archivo YAML que contenga la co­n­fi­gu­ra­ción del volumen pe­r­si­s­te­n­te. Puedes llamar a este archivo pv.yaml, por ejemplo. A co­n­ti­nua­ción te mostramos un ejemplo sencillo de co­n­fi­gu­ra­ción de un PV:

apiVersion: v1 
kind: PersistentVolume 
metadata: 
    name: my-pv 
spec: 
    capacity: 
        storage: 1Gi 
    volumeMode: Filesystem 
    accessModes: 
        - ReadWriteOnce 
    persistentVolumeReclaimPolicy: Retain 
    storageClassName: manual 
    hostPath: 
        path: "/mnt/data"

• apiVersion: indica la versión API de Ku­be­r­ne­tes. En este caso es v1.
• kind: es el tipo de objeto de Ku­be­r­ne­tes, en este caso Pe­r­si­s­te­n­t­Vo­lu­me.
• metadata: contiene metadatos para el Pe­r­si­s­te­nt Volume, por ejemplo, el nombre del volumen. spec: define la es­pe­ci­fi­ca­ción del volumen.
• capacity: indica la capacidad de al­ma­ce­na­mie­n­to, en este ejemplo 1 GB.
• volumeMode: indica el modo del volumen, ya sea Filesystem o Block. En este ejemplo usamos Filesystem.
• accessModes: define los modos de acceso. Aquí ReadWriteOnce significa acceso exclusivo de lectura y escritura.
• persistentVolumeReclaimPolicy: indica cómo se debe manejar el volumen cuando ya no se necesite. Retain significa que el volumen debe eli­mi­nar­se ma­nua­l­me­n­te.
• storageClassName: asigna una clase de al­ma­ce­na­mie­n­to al Pe­r­si­s­te­nt Volume.
• hostPath: define la ruta en el sistema de archivos del host que se utilizará como al­ma­ce­na­mie­n­to para el Pe­r­si­s­te­nt Volume.

Paso 2: apli­ca­ción de la co­n­fi­gu­ra­ción

Una vez descrito el archivo de co­n­fi­gu­ra­ción PV, puedes activarlo con Kubelet:

kubectl apply -f pv.yaml

Este comando envía el archivo de co­n­fi­gu­ra­ción al clúster de Ku­be­r­ne­tes que crea los recursos que contiene.

Paso 3: apli­ca­ción de la co­n­fi­gu­ra­ción

Para ase­gu­rar­te de que el Pe­r­si­s­te­nt Volume de Ku­be­r­ne­tes se ha creado co­rre­c­ta­me­n­te, puedes utilizar el siguiente comando:

kubectl get pv

Esto listará todos los volúmenes pe­r­si­s­te­n­tes exi­s­te­n­tes en el clúster.

NAME   CAPACITY  ACCESS MODES  RECLAIM POLICY  STATUS  CLAIM  STORAGECLASS  REASON  AGE 
my-pv    1Gi          RWX          Retain     Available           manual             1h

Paso 4: creación de un Pe­r­si­s­te­nt Volume Claim (PVC)

Rellena un archivo YAML que defina la co­n­fi­gu­ra­ción del Pe­r­si­s­te­nt Volume Claim:

apiVersion: v1 
kind: PersistentVolumeClaim 
metadata: 
    name: my-pvc 
spec: 
    accessModes: 
        - ReadWriteOnce 
    resources: 
        requests: 
            storage: 1Gi 
    storageClassName: manual

Aplica el archivo de co­n­fi­gu­ra­ción de PVC al clúster Ku­be­r­ne­tes:

kubectl apply -f pvc.yaml

Comprueba si el Pe­r­si­s­te­nt Volume Claim se ha creado co­rre­c­ta­me­n­te y utiliza el siguiente comando:

kubectl get pvc

El resultado debería ser algo así:

NAME      STATUS   VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE 
my-pvc     Bound    my-pv     1Gi           RWO          manual       1m

Ahora crearemos el ma­ni­fie­s­to YAML pvc-dynamic.yaml para demostrar la provisión dinámica de un Pe­r­si­s­te­nt Volume Claim (PVC) en Ku­be­r­ne­tes. El ma­ni­fie­s­to creará y reclamará au­to­má­ti­ca­me­n­te un nuevo Pe­r­si­s­te­nt Volume en Ku­be­r­ne­tes con un tamaño de 1 gigabyte, re­s­pa­l­da­do por la clase de al­ma­ce­na­mie­n­to standard.

apiVersion: v1 
kind: PersistentVolumeClaim 
metadata: 
    name: pvc-dynamic 
spec: 
    accessModes: 
        - ReadWriteOnce 
    resources: 
        requests: 
            storage: 1Gi 
    storageClassName: standard

Una vez definidas las co­n­fi­gu­ra­cio­nes, activamos el ma­ni­fie­s­to:

kubectl apply -f pvc-dynamic.yaml

Paso 5: conexión del PVC al pod

Para emparejar el PVC con el pod, es necesario es­ta­ble­cer la co­n­fi­gu­ra­ción para el pod que utilizará el al­ma­ce­na­mie­n­to pe­r­si­s­te­n­te.

apiVersion: v1 
kind: Pod 
metadata: 
    name: mypod 
spec: 
    volumes: 
    - name: mypvc-volume 
        persistentVolumeClaim: 
            claimName: my-pvc 
    containers: 
    - name: mycontainer 
        image: myimage 
        volumeMounts: 
        - mountPath: "/app/data" 
            name: mypvc-volume

Aplica la co­n­fi­gu­ra­ción del pod al clúster Ku­be­r­ne­tes para crear el pod:

kubectl apply -f pod.yaml

Si estás empezando con Ku­be­r­ne­tes, en­co­n­tra­rás toda la in­fo­r­ma­ción sobre la in­s­ta­la­ción y co­n­fi­gu­ra­ción de un clúster en el tutorial de Ku­be­r­ne­tes de nuestra guía.