Openshift – Almacenamiento

persistente
Volúmenes
- Los ficheros en disco de un contenedor son por defecto Efímeros (ephemeral), lo que significa
que se mueren con el contenedor si este deja de existir.
- En kubernetes y por tanto en Openshift existen distintos tipos de volúmenes:

Efímeros: asociados al tiempo de vida del contenedor.

Persistentes: como dice la palabra persisten, es decir no son borrados cuando muere el
contenedor/es con el que están asociados

Proyectados: mapea varios volúmenes existentes en el mismo directorio*

*si son de los siguientes tipos:

Secret

DownwardAPI

ConfigMap

serviceAccountToken
Almacenamiento persistente (PV)

- Kind ‘PersistentVolume’ , denominado usualmente PV

- Recurso de almacenamiento en el cluster Openshift.

- Almacenamiento persistente ofrecido desde múltiples fuentes:

GCE Persistent Disk

AWS Elastic Block Store (EBS)

NFS mounts

Etc
- Los volúmenes persistentes o sus mecanismos de gestión son gestionados por
los administradores del cluster (StorageClass/s para provisionamiento dinámico)
Almacenamiento persistente (PV) – Tipos de acceso

- ReadWriteOnce:

El volumen puede ser montado para lectura y escritura por un solo nodo.
- ReadOnlyMany:

El volumen puede ser montado solo para lectura por N nodos.
- ReadWriteMany:

El volumen puede ser montado para lectura y escritura por N nodos.
Almacenamiento persistente (PV) - interacción

- Obtención de los Pvs:


oc get pv
 Almacenamiento persistente (PV) – politica de eliminación
- Cuando un consumidor ha terminado o ya no necesita hacer uso de un volumen, este
puede eliminar la PVC que realiza la reclamación del recurso del PV, por tanto el PV
puede ser eliminado. Kubernetes ofrece las siguientes estrategias*:

Retain: elimina el PV en el cluster pero el elemento de almacenamiento en la
infraestructura interna no se toca.

Delete: elimina el PV en el cluster y además si el plugin de volumen en uso admite
la operación ‘Delete’, realiza el borrado en origen del elemento de almacenamiento.

Recycle (deprecada): elimina el contenido en el volumen y lo pone a disposición
“limpio” para poder ser utilizada en nuevas PVCs.


*Nota: PV creados con provisionamiento dinámico heredan automáticamente la
política de eliminación esstipulada en la StorageClass empleada.
Almacenamiento persistente (PV) - ejemplo
apiVersion: v1
kind: PersistentVolume
metadata:
name: task-pv-volume
labels:
type: local
spec:
storageClassName: manual
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
hostPath:
path: "/mnt/data"
Solicitudes de almacenamiento persistente (PVC)

- Kind: PersistentVolumeClain, tambien usualmente referenciadas como PVC

- Se trata del recurso del cluster que canaliza el concepto de petición de un

espacio de almacenamiento persistente con atributos específicos.
- Las peticiones de almacenamiento persistente (‘claims’) son satisfechas
mediante el mapeo contra un volumen persistente que satisfaga las
caracteristicas de la solicitud.
- Este proceso de satisfacer las solicitudes de almacenamiento persistente se
denomina enlace o del inglés ‘binding’, y tiene asociado un ciclo de vida dentro
del cluster.
Solicitudes de almacenamiento persistente (PVC) - Interacción

- Obtención del listado de persistent volume claims:


oc get pvc

oc create -f manifest.yaml

oc apply -f manifest.yaml

oc delete -f manifest.yaml
Solicitudes de almacenamiento persistente (PVC) - Ejemplo

apiVersion: "v1"
kind: "PersistentVolumeClaim"
metadata:
name: "claim1"
spec:
accessModes:
- "ReadWriteOnce"
resources:
requests:
storage: "1Gi"
volumeName: "pv0001"
Solicitudes de almacenamiento persistente (PVC) – Ciclo de vida

- Una solicitud de almacenamiento persistente pasa por diferentes etapas antes

de encontrar el volumen persistente sobre el que va a poder alojar su volumen:

Pendiente de enlace (bound pending)

Enlazada (bound)
- Si una solicitud de de almacenamiento conoce el volumen persistente a utilizar,
puede especificarlo en su declaración para enlazarse a el (si este ya existe). Es lo
que se conoce como provisionamiento estático.
- Si no existe un volumen persistente que satisfaga las característica de la solicitud
de volumen persistente, el cluster puede gestionar la creación de un volumen
persistente de forma dinámica empleando para ello el concepto de ‘StorageClass’.
Es lo que se conoce como provisionamiento dinámico.
Clases de almacenamiento (StorageClass)

- Permiten a los administradores del cluster describir/configurar las

clases de almacenamiento que se ofrecen en el cluster.
- Diferentes clases pueden hacer uso de diferentes calidades de
servicio/rendimiento, políticas de backup o políticas arbitrarias
determinadas por los administradores.
- Propiedades de la clase que se usan cuando un PV se provisiona:

Provisionador (provisioner)

Parametros (parameters)

Política de reclamación (reclaimPolicy)
Clases de almacenamiento - Provisionadores
- Cada clase de almacenamiento posee un provisionador que especifica
el plugin que se usa para proporcionar el almacenamiento, estos son
los soportados por defecto en Kubernetes:

Se admite soporte
externo:
https://github.com/
kubernetes-sigs/
sig-storage-lib-
external-provisioner
Provisionamiento dinámico
- Para habilitar el provisionamiento dinámico en el cluster los
administradores han de registrar al menos una StorageClass.
- Los usuarios podrán referenciar el uso del provisionamiento
dinámico por medio de la referencia en sus PVCs al nombre de la
clase de almacenamiento (StorageClass) específica.
- Si se desea el comportamiento de provisión dinámica por defecto en
el cluster los administradores han de habilitar (anotar) una
StorageClass por defecto.
Volume Snapshot y Volume Snapshot Content
- Se pueden entender estos dos conceptos de forma similar a los de
volumen persistente y solicitud de volumen persistente.
- Volume Snapshot: es una solicitud de la realización de un snapshot
por un usuario.
- Volume Snapshot Content: es el contenido asociado a una copia
de un volumen en un punto determinado del tiempo.
- Volume Snapshot Class: permite especificar diferentes atributos
pertenecientes a un VolumeSnapshot.
Consumo de volumenes en un contenedor

apiVersion: "v1"
kind: "Pod"
metadata:
name: "mypod"
labels:
name: "frontendhttp"
spec:
containers:
-
name: "myfrontend"
image: openshift/hello-openshift
ports:
-
containerPort: 80
name: "http-server"
volumeMounts:
-
mountPath: "/var/www/html"
name: "pvol"
volumes:
-
name: "pvol"
persistentVolumeClaim:
claimName: "claim1"
Ejercicio 1
- Modifica el siguiente código fuente para gestionar la capa de persistencia
sobre fichero.

Puedes emplear la solución que prefieras, por ejemplo:

Base de datos “In-memory” ubicada en una localización
configurable por propiedades de la app.

1 entidad por fichero.

Todas las entidades almacenadas como contenido en 1 único
fichero.

Etc.
- El objetivo del ejercicio será modificar la aplicación para utilizar un
volumen persistente donde alojar dicha información.
- La información debe perdurar entre distintos despliegues de la aplicación.

https://github.com/jarey-ds/spring-boot-hibernate-dc
Ejercicio 2
- Re-visita el primer anexo del módulo 1 de teoría de este curso.
- Revisa de nuevo la aproximación del provisionador NFS empleado
para proporcionar las diferentes entidades de cluster necesarias
para coordinar provisionamiento dinámico a través de
StorageClasses.
- Con los conceptos aprendidos trata de identificar todas las gestiones
vistas en teoría que se citan en el paso a paso de la configuración.