5 tipos de volúmenes de Kubernetes y cómo trabajar con ellos

¿Qué son los volúmenes de Kubernetes?

Un volumen de Kubernetes es un directorio que contiene datos, al que pueden acceder los contenedores en un pod de Kubernetes. La ubicación del directorio, el medio de almacenamiento que lo soporta y su contenido dependen del tipo específico de volumen que se esté usando.

Los procesos que se ejecutan dentro de los contenedores en un pod ven una vista del sistema de archivos compuesta por:

• Un sistema de archivos raíz que coincide con el contenido de la imagen del contenedor.
• Volúmenes montados en el contenedor (si se define). Cada volumen se monta en una ruta específica dentro del sistema de archivos del contenedor.

Los volúmenes se definen en el campo .spec.containers[*].volumeMounts de la plantilla del pod. Para cada pod y cada imagen de contenedor dentro del pod, tienes que especificar qué volúmenes va a montar y en qué rutas (las rutas pueden ser diferentes para cada contenedor).

Existen varios tipos de volúmenes en Kubernetes. Los más importantes son los volúmenes efímeros, que se almacenan localmente en el nodo de Kubernetes y se eliminan cuando se reinicia un pod, y Kubernetes persistent volumes (PV), que conservan los datos incluso después de que se apague un pod.

En este artículo:

• Tipos de volúmenes de Kubernetes
  • Volúmenes persistentes
  • Volúmenes efímeros
  • Volúmenes EmptyDir
  • Kubernetes hostPath Volúmenes
  • Volúmenes de Kubernetes ConfigMap
• Plugins para almacenar volúmenes de Kubernetes
  • NFS
  • CSI
• ¿Qué son Kubernetes volumeMounts?
• Crear un volumen de Kubernetes mediante el despliegue de pods
• Gestión de volúmenes de Kubernetes con NetApp Cloud Volumes ONTAP

5 tipos de volúmenes de Kubernetes

Kubernetes admite varios volúmenes, lo que permite que cada pod use varios tipos de volumen al mismo tiempo. Los volúmenes efímeros están vinculados al ciclo de vida del pod, mientras que los volúmenes persistentes pueden persistir más allá del ciclo de vida del pod. Esto significa que Kubernetes destruye los volúmenes efímeros una vez que su pod ya no existe, mientras mantiene los datos de los volúmenes persistentes.

Volúmenes persistentes

Kubernetes proporciona un subsistema PersistentVolume con una API que abstrae el aprovisionamiento de almacenamiento y el consumo. Funciona con dos recursos de la API—PersistentVolume (PV) y PersistentVolumeClaim (PVC).

PersistentVolume (PV)
Un PV es un recurso de almacenamiento ubicado en el clúster. Los administradores pueden aprovisionar PVs manualmente, y Kubernetes puede usar clases de almacenamiento para aprovisionar PVs dinámicamente. Al igual que los volúmenes, los PVs son plugins, pero su ciclo de vida es independiente de cualquier pod que use el PV.

Un PV funciona como un objeto API que captura los detalles de la implementación de almacenamiento, incluidos iSCSI, NFS y sistemas de almacenamiento de cloud provider. Funciona de forma similar a un nodo, pero ofrece recursos de almacenamiento en lugar de computación.

PersistentVolumeClaim (PVC)
Un PVC es una solicitud de almacenamiento hecha por un usuario. Funciona de forma similar a un pod pero consume recursos de PV en vez de recursos de nodo. Un PVC puede solicitar recursos de almacenamiento específicos, especificando modos de acceso como ReadWriteOnce, ReadWriteMany y ReadOnlyMany.

Los PVC permiten a los usuarios consumir recursos de almacenamiento abstractos, pero los usuarios normalmente necesitan PV con distintas propiedades para diferentes problemas. Por eso, los administradores de clúster suelen necesitar ofrecer distintos PV que difieren en algo más que el tamaño y los modos de acceso. Pueden hacer eso sin exponer a los usuarios a los detalles de implementación mediante recursos StorageClass.

Contenido relacionado: lee nuestra guía sobre Kubernetes PVC

Volúmenes efímeros

Los volúmenes efímeros no almacenan datos de forma persistente a través de reinicios. Estos volúmenes están vinculados a la vida útil del pod, lo que significa que se crean y eliminan junto con el pod. Permite detener y reiniciar pods sin limitarlos a la disponibilidad de almacenamiento persistente.

Los volúmenes efímeros son sencillos de desplegar y gestionar. Puedes especificarlos en línea en la especificación del pod. Los volúmenes efímeros son ideales para aplicaciones que no requieren almacenamiento persistente, como los servicios de caché.

Volúmenes EmptyDir

Un volumen emptyDir se crea cuando Kubernetes asigna un pod a un nodo. La vida útil de este volumen está ligada al ciclo de vida de un pod en ese nodo específico. Un volumen emptyDir se vuelve a crear cuando los contenedores se reinician o se bloquean. Sin embargo, los datos de este volumen se eliminan y se pierden cuando el pod se elimina del nodo, se bloquea o muere.

Después de crear un volumen emptyDir, puedes declarar el nombre del tipo de volumen como un campo en el archivo de manifiesto del pod. Aparece en la sección de propiedades del volumen con llaves vacías{} como valor. Los volúmenes EmptyDir son adecuados principalmente para el almacenamiento temporal de datos. Por ejemplo, puedes usarlo para espacio scratch, como una fusión basada en disco.

Puedes almacenar volúmenes emptyDir en el medio que respalda el nodo. Por ejemplo, puedes usar almacenamiento de red o SSD. O también, puedes poner "memory" en el campo emptyDir.medium y Kubernetes montará un sistema de archivos respaldado por RAM (tmpfs). Ten en cuenta que Kubernetes borra tmpfs al reiniciar el nodo.

Kubernetes hostPath Volúmenes

Un volumen hostPath monta un directorio o archivo del sistema de archivos del nodo anfitrión en tu pod.

Aquí tienes los casos clave de uso para los volúmenes hostPath:

• Usa un /var/lib/dockerhostPath—para ejecutar un contenedor que requiere acceso a los componentes internos de Docker.
• Usa un /sys hostPath—para ejecutar cAdvisor en un contenedor.
• Permite que un pod especifique un hostPath—para definir si un cierto hostPath debe existir antes de que el pod empiece a ejecutarse y si debe crearse.
• Especifica un tipo para un volumen hostPath—puedes configurar esto además de la propiedad de ruta requerida.

HostPath volúmenes seguridad
HostPath volúmenes plantean muchos riesgos de seguridad. Evita usarlos siempre que sea posible. Si tienes que usar un volumen HostPath, deberías limitarlo solo al directorio o archivo necesario y montarlo como ReadOnly.

Aquí tienes los principales riesgos de seguridad:

• Credenciales expuestas—HostPaths puede exponer credenciales privilegiadas del sistema o APIs privilegiadas. Los actores de amenazas pueden usarlo para atacar otras partes del cluster o para escapar de contenedores.
• Privilegios de root—cualquier directorio o archivo creado en los hosts subyacentes solo puede ser escrito por root. Si quieres escribir en un volumen hostPath, necesitas modificar los permisos de archivo en el host o ejecutar el proceso como root dentro de un contenedor con privilegios.

Puedes usar la AdmissionPolicy para restringir el acceso de HostPath a ciertos directorios. Sin embargo, la política es efectiva solo si requieres que volumeMounts use montajes readOnly.

Volúmenes de Kubernetes ConfigMap

Un ConfigMap permite inyectar datos de configuración en pods. Los datos almacenados dentro de un ConfigMap pueden ser referenciados en un volumen de tipo configMap y luego consumidos por aplicaciones en contenedores que se ejecutan en un pod. Necesitas proporcionar el nombre del ConfigMap en el volumen cuando haces referencia a un ConfigMap. Kubernetes te permite personalizar la ruta para una entrada específica en el ConfigMap.

Plugins para almacenar volúmenes de Kubernetes

Kubernetes proporciona varios plugins de almacenamiento que proporcionan acceso a los dispositivos de almacenamiento desplegados en un clúster de Kubernetes. Estos se implementan usando el objeto StorageClass.

Algunos de los principales plugins actualmente soportados por Kubernetes son GCEPersistentDisk, AWSElasticBlockStore, AzureDisk, Glusterfs, NFS y iSCSI. Para más detalles sobre estos plugins, consulta la documentación StorageClass.

Vamos a revisar con más detalle dos plugins de almacenamiento notables.

NFS

Network File System (NFS) es un protocolo estándar para montar dispositivos de almacenamiento como unidades locales. Kubernetes te permite montar un volumen NFS como una unidad local en un contenedor. Como el código heredado suele acceder a los datos mediante NFS, este complemento es muy útil para migrar cargas de trabajo heredadas a Kubernetes.

Hay dos formas de acceder a los datos mediante NFS y Kubernetes:

• Volúmenes NFS efímeros—pueden adjuntarse al almacenamiento NFS existente.
• PersistentVolumes con NFS—te permite configurar recursos gestionados en un clúster a los que accedes mediante NFS.

CSI

La interfaz de almacenamiento de contenedores (CSI) es una interfaz estándar que permite a los orquestadores de contenedores exponer sistemas de almacenamiento a los contenedores que gestionan. CSI permite a los proveedores de almacenamiento crear plugins que están “fuera del árbol”, es decir, no necesitan registrarse en el repositorio de código de Kubernetes y no se envían con Kubernetes.

Hay muchos plugins fuera del árbol basados en CSI que ofrecen directamente los proveedores de almacenamiento. La llegada de CSI ha hecho que sea mucho más fácil para las tecnologías de almacenamiento soportar Kubernetes.

Contenido relacionado: lee nuestra guía sobre Container Storage Interface

¿Qué son Kubernetes volumeMounts?

Hay dos pasos para crear un volumen y hacerlo accesible a un pod:

• Declarándolo en la propiedad spec:volumes de la plantilla del pod y luego desplegando el pod en algunos nodos
• Montar el volumen en un contenedor específico usando la propiedad spec:containers::volumeMounts

Estos pasos van de la mano. Cuando creas un volumen, también tienes que montarlo en un contenedor y no puedes montar un volumen sin declararlo en la plantilla del pod.

Aquí tienes un ejemplo que muestra tanto la creación como el montaje de un volumen en una configuración YAML de plantilla de pod:

spec: containers: —name: my-app image: nginx volumeMounts: —name: my-volume mountPath: /app/config volumes: —name: my-volume 

En este código:

• volumes (en la parte inferior) crea un volumen llamado my-volume y lo adjunta al pod
• volumeMounts define cómo se monta el volumen, incluida la ruta de archivo por la que el volumen estará disponible desde dentro del contenedor
• Es esencial que se utilice el mismo nombre de volumen en ambos lugares—la declaración de volumen y la propiedad volumeMounts.

Crear un volumen de Kubernetes desplegando pods

Para crear un volumen de Kubernetes, despliegas uno o más pods que declaran el volumen. Una forma común de hacerlo es mediante un objeto Deployment. Aquí tienes un ejemplo de un manifiesto Deployment que hace lo siguiente:

• Despliega tres pods, cada uno con un contenedor NGINX
• Declara un emptyDir volumen
• Monta el volumen en cada uno de los tres contenedores en la raíz

apiVersion: apps/v1 kind: Deployment metadata: name: pods-with-volumes spec: replicas: 3 selector: matchLabels: app: demo template: metadata: labels: app: demo spec: containers: —name: my-container image: nginx:1.14.2 volumeMounts: —mountPath: / name: my-volume volumes: —name: my-volume emptyDir: {} 

Ten en cuenta que el nombre de este Deployment se define en pods-with-volumes—así es como lo mencionas en el entorno de Kubernetes.

Como vimos en la sección anterior, este objeto Deployment realiza las dos acciones necesarias para crear un volumen:

• La propiedad spec:template:volumes declara el volumen.
• La propiedad spec:containers::volumeMounts monta el volumen en los contenedores.

Supongamos que este archivo YAML se guarda con el nombre my-deployment.yaml. Puedes crear el Deployment en tu clúster de Kubernetes usando este comando:

kubectl apply -f my-deployment.yaml

Para verificar que la Deployment se está ejecutando correctamente con los volúmenes esperados, ejecuta este comando:

kubectl describe pods pods-with-volumes

Si todo ha funcionado correctamente, la salida mostrará que cada pod tiene un contenedor llamado my-container con el punto de montaje solicitado:

Montajes: / from my-volume (rw)

La salida también mostrará el volumen que se ejecuta bajo cada pod:

Volúmenes: my-volume: Tipo: EmptyDir (un directorio temporal que comparte la vida de un pod)

Gestión de volúmenes de Kubernetes con NetApp Cloud Volumes ONTAP

NetApp Cloud Volumes ONTAP, la solución líder de gestión de almacenamiento de clase empresarial, ofrece servicios de gestión de almacenamiento seguros y probados en AWS, Azure y Google Cloud. La capacidad de Cloud Volumes ONTAP puede escalar hasta los petabytes y admite varios casos de uso, como servicios de archivos, bases de datos, DevOps o cualquier otra carga de trabajo empresarial, con un sólido conjunto de funcionalidades que incluyen alta disponibilidad, protección de datos, eficiencias de almacenamiento, integración con Kubernetes y más.

En concreto, Cloud Volumes ONTAP es compatible con el aprovisionamiento y la gestión de Kubernetes Persistent Volume requisitos de las cargas de trabajo en contenedores.

Conoce más sobre cómo Cloud Volumes ONTAP ayuda a afrontar los retos de las aplicaciones en contenedores en estas Kubernetes Workloads con Cloud Volumes ONTAP Case Studies.