Volúmenes

En esta página, se proporciona una descripción general de los volúmenes en Kubernetes y su uso con Google Kubernetes Engine (GKE).

Descripción general

Los archivos en disco en un contenedor son el lugar más simple para que una aplicación escriba datos, pero este enfoque tiene desventajas. Los archivos se pierden cuando el contenedor falla o se detiene por algún motivo. Además, otros contenedores que se ejecutan en el mismo pod no pueden tener acceso a los archivos dentro de un contenedor. La abstracción del volumen de Kubernetes aborda ambos problemas.

En teoría, un volumen es un directorio al que pueden acceder todos los contenedores en un pod. La fuente de volumen declarada en la especificación de pod determina la manera en que se crea el directorio, el medio de almacenamiento usado y los contenidos iniciales del directorio. Un pod especifica qué volúmenes contiene y la ruta en la que los contenedores activan el volumen.

Los tipos de volumen efímero tienen la misma duración que sus pods adjuntos. Estos volúmenes se crean cuando se crea el pod y persisten durante los reinicios del contenedor. Cuando el pod termina o se borra, sucede lo mismo con sus volúmenes.

Otros tipos de volumen son las interfaces para el almacenamiento duradero que existen independientemente de un pod. A diferencia de los volúmenes efímeros, los datos en un volumen respaldado por el almacenamiento duradero se conservan cuando se quita el pod. El volumen simplemente se desactiva y los datos se pueden transferir a otro pod. Debes usar los recursos PersistentVolume para administrar la duración de los tipos de almacenamiento duraderos, en vez especificarlos directamente.

Tipos de volúmenes

Los volúmenes difieren en la implementación de almacenamiento y el contenido inicial. Puedes elegir la fuente de volumen que mejor se adapte a tu caso práctico. En las siguientes secciones, se describen varias fuentes de volúmenes comunes. Para obtener una lista completa de los tipos de volúmenes, consulta la documentación sobre volúmenes de Kubernetes.

emptyDir

Un volumen emptyDir proporciona un directorio vacío desde el cual los contenedores en el pod pueden leer y en los que pueden escribir. Cuando el pod se quita de un nodo por algún motivo, los datos en emptyDir se borran de forma permanente. Un volumen emptyDir se almacena en cualquier medio que realice una copia de seguridad del nodo, que puede ser un disco, un SSD o un almacenamiento de red, en función de tu entorno. Los volúmenes emptyDir son útiles para el espacio temporal y comparten datos entre varios contenedores en un pod.

Todas las activaciones de emptyDir son parte del almacenamiento efímero del nodo, que también incluye los registros y la capa que admite escritura del contenedor. De forma predeterminada, GKE Autopilot establece el almacenamiento efímero en 1 GiB para darle a tu app un poco de espacio para crear algunos archivos. Si necesitas más o menos, puedes ajustar tu almacenamiento efímero en tu Deployment mediante la configuración de una solicitud de recursos para ephemeral-storage.

Si usas contenedores con grupos de nodos de Linux, puedes configurar el campo emptyDir.medium en Memory para indicarle a Kubernetes que active un tmpfs (sistema de archivos respaldado por la RAM). Sin embargo, esto no es compatible con los contenedores de Windows Server.

ConfigMap

Un recurso ConfigMap proporciona una forma de incorporar datos de configuración en los Pods. Se puede hacer referencia a los datos almacenados en un objeto ConfigMap en un volumen de tipo ConfigMap y, luego, consumirlos a través de archivos que se ejecutan en un pod. Los archivos en un volumen ConfigMap se especifican mediante un recurso ConfigMap.

Secreto

Un volumen Secret se utiliza para que los datos sensibles, como contraseñas, tokens de OAuth y claves SSH, estén disponibles en las aplicaciones. Se puede hacer referencia a los datos almacenados en un objeto Secret en un volumen de tipo Secret y, luego, consumirlos a través de archivos que se ejecutan en un pod.

downwardAPI

Un volumen downwardAPI hace que los datos de la API de Downward estén disponibles para las aplicaciones. Estos datos incluyen información sobre el pod y el contenedor en el que se ejecuta la aplicación. Por ejemplo, un pod puede configurarse para exponer un DownwardAPIVolumeFile a aplicaciones, que incluye el espacio de nombres y la dirección IP del pod. Para obtener una lista completa de los tipos de datos que puedes agregar, consulta Funciones de la API de Downward.

PersistentVolumeClaim

Los operadores de clúster pueden usar un volumen PersistentVolumeClaim a fin de aprovisionar almacenamiento duradero para que usen las aplicaciones. Un pod usa una PersistentVolumeClaim para activar un volumen que respalda este almacenamiento duradero.

¿Qué sigue?