Ediciones ENI Editorial | líder en informática
Persistencia de los datos
Objetivos del capítulo y requisitos previos
Este capítulo presenta la persistencia de datos en Kubernetes. De hecho, el contenido de un contenedor no está destinado a perdurar. Este mecanismo se encarga de almacenar información cuando sea necesario (bases de datos, servidores de archivos, etc.).
El capítulo se abordará desde dos puntos de vista:
-
El del usuario que utiliza volúmenes persistentes.
-
El del administrador que implementa este mecanismo.
Persistencia de los datos
1. Origen de la necesidad
Más atrás en este libro, se ha analizado el ciclo de vida de los contenedores en Kubernetes. Un aspecto importante que debe recordar es que un contenedor tiene una vida útil relativamente corta y, tal y como está, no es posible almacenar datos.
Para satisfacer esta necesidad, Kubernetes puede habilitar espacios de almacenamiento externos al clúster. Este mecanismo se basa en la noción de volumen de datos persistente (Persistent Volume).
2. Utilización de un volumen persistente externo
El uso de un volumen persistente se realiza dentro de la declaración de un pod. Una primera solución podría ser pasar por un servicio externo, como con un punto de montaje NFS.
Esta declaración de persistencia de datos se definirá en dos partes:
-
Una referencia a nivel del pod en el campo volumes.
La referencia a un volumen NFS a nivel de pod se presenta de la siguiente manera:
spec:
volumes:
- name: nfs
nfs:
# URL for the NFS server
server: 192.168.0.1
path: / El montaje a nivel del contenedor se presenta de la siguiente manera:
spec:
containers:
- name: mailhog
image: mailhog/mailhog
# Mount the NFS volume in the container
volumeMounts:
- name: nfs
mountPath: /maildir 3. Volúmenes persistentes
a. Estructura del volumen persistente
Además de llamar a servicios externos, es posible hacer referencia a objetos de tipo volumen persistente (Persistent Volume). Estos últimos tienen la siguiente estructura:
-
Una versión y un tipo (apiVersion y kind).
-
Metadatos (campo metadata).
-
el tipo de acceso,
-
la capacidad de almacenamiento,
-
la clase de volumen persistente (establecida en manual para el ejemplo),
-
las características de almacenamiento.
A continuación, se muestra un ejemplo de almacenamiento llamado pv-mailhog, que se basa en un directorio de la máquina host. Este volumen tiene una capacidad declarada de 10 MB:
apiVersion:...Clases de almacenamiento
1. Origen de la necesidad
La sección anterior ha permitido abordar el trabajo necesario para implementar un volumen persistente:
-
Una declaración para indicar que hay espacio en disco disponible.
-
Una declaración para poder monopolizar un espacio en disco.
-
Una acción manual para posicionar los permisos en los directorios.
Afortunadamente para el administrador, este trabajo de declaración no es necesario. Es posible utilizar un administrador de volumen persistente automático: los objetos StorageClass (o su acceso directo sc).
Estos objetos serán los encargados de interceptar las peticiones de volumen persistente (PersistentVolumeClaim) y realizar automáticamente las siguientes acciones:
-
Crear el objeto PersistentVolume.
-
Asignar permisos ad-hoc.
Otro aspecto importante es que un clúster de Kubernetes puede usar varias clases de almacenamiento, que ofrecen varios niveles de servicios, como:
-
una clase ssd para discos rápidos de tipo SSD,
-
una clase hdd para discos duros clásicos de tipo HDD,
-
una clase nfs para poder compartir espacio en disco entre varios pods.
Depende de usted crear el tipo de disco necesario, en función de las necesidades de los usuarios.
De esta manera, una aplicación que necesite discos rápidos podrá solicitar discos SSD, mientras que otra utilizará discos tradicionales para reducir los costes de almacenamiento.
2. Lista de las clases de almacenamiento
En Minikube, hay una clase de almacenamiento durante la instalación.
Para recuperar esta declaración, ejecute el comando kubectl con las siguientes opciones:
-
El verbo get.
-
El tipo que hay que recuperar (storageclass o su acceso directo sc).
A continuación, se muestra el comando que se debe lanzar:
$ kubectl get storageclass Y el resultado esperado:
NAME PROVISIONER AGE
standard (default) k8s.io/minikube-hostpath 30d Una clase de almacenamiento tiene el nombre estándar y este último se define de forma predeterminada. Otro aspecto importante es que el mecanismo de suministro se llama k8s.io/minikube-hostpath.
3. Detalle de una clase de almacenamiento
Como cualquier...