Imágenes OCI como volúmenes en Kubernetes: Una nueva era para la gestión de datos
Recientemente se ha incorporado un nuevo tipo de volumen al ecosistema de Kubernetes: el volumen image. Esta funcionalidad, disponible a partir de la versión 1.35.0 y actualmente en fase beta, promete cambiar la forma en que gestionamos los datos estáticos y configuraciones en nuestros clústeres.
La relevancia de
Recientemente se ha incorporado un nuevo tipo de volumen al ecosistema de Kubernetes: el volumen image. Esta funcionalidad, disponible a partir de la versión 1.35.0 y actualmente en fase beta, promete cambiar la forma en que gestionamos los datos estáticos y configuraciones en nuestros clústeres.
La relevancia de este tipo de volumen ha ido en aumento en el entorno nativo de la nube. Diversas aplicaciones ya utilizan imágenes de contenedor para almacenar información en formato OCI (Open Container Initiative). Herramientas populares como Falco (para reglas de seguridad), Kyverno (para políticas) y FluxCD (para la gestión de despliegues) son claros ejemplos de esta tendencia. Ahora, esta capacidad es nativa de Kubernetes.
Beneficios de utilizar imágenes OCI para datos
Adoptar este patrón en tus aplicaciones trae consigo ventajas significativas:
Simplificación de la infraestructura: Hasta ahora, gestionar ficheros externos solía requerir servicios de almacenamiento en la nube como S3 o GCS. Esto implicaba costos adicionales, gestión de buckets y configuración de permisos. Al utilizar el volumen image, prescindes de estos servicios externos, simplificando tu arquitectura.
Seguridad integrada: Al tratarse de imágenes OCI estándar, puedes utilizar las mismas herramientas de escaneo de vulnerabilidades que ya usas para tus aplicaciones. Esto asegura que los ficheros de configuración o datos que introduces no contienen vulnerabilidades conocidas.
Despliegues más rápidos: Si separas el código fuente de los datos, puedes actualizar configuraciones generando una nueva imagen de datos (más ligera) sin necesidad de reconstruir la imagen completa de la aplicación.
¿Cómo crear imágenes de datos?
Con esta funcionalidad habilitada, surge la necesidad de crear estas “imágenes de datos”. Aunque pueda sonar complejo, el proceso es bastante sencillo y se apoya en herramientas estándares del ecosistema.
Una variante sencilla, nativa y fácil de implementar es utilizar Docker y la imagen scratch.
Este enfoque no requiere herramientas adicionales. Simplemente creamos un Dockerfile que parte de una imagen vacía y copiamos nuestros datos dentro:
FROM scratch
COPY ./files /
Y el proceso de construcción es el estándar que ya conoces:
Para utilizar este tipo de volumen, defines el volumen en la sección volumes de tu Pod haciendo referencia a la imagen, y luego lo montas en el contenedor mediante volumeMounts.
Aquí tienes un ejemplo sencillo de cómo configurarlo:
En este caso, el contenido de la imagen ghcr.io/mmorejon/erase-una-vez-5:main estará disponible dentro del contenedor en la ruta /srv/data.
¿Cómo probarlo hoy mismo?
Para utilizar esta funcionalidad necesitas un clúster de Kubernetes en su versión 1.35.0. Dado que esta versión es muy reciente, es posible que todavía no esté disponible en los principales proveedores de nube como Azure, AWS o GCP.
Sin embargo, no dejes que eso te detenga. Puedes utilizar el repositorio erase-una-vez-k8s para levantar un clúster local compatible en cuestión de segundos (aproximadamente 40 segundos). Es una forma excelente de experimentar con estas nuevas características en tu propio entorno de desarrollo.
Y el momento de la verdad. Verifica que el volumen se ha montado correctamente
kubectl exec erase-una-vez-5 -- cat /usr/share/nginx/html/example-1.txt
# > Érase una vez Kubernetes
El volumen de tipo image es un paso más hacia la estandarización y simplificación en Kubernetes. Te animo a que lo pruebes y descubras cómo puede optimizar tus flujos de trabajo de datos y configuración.
El Ejecutivo ha sido incapaz de conformar el Consejo Directivo de la nueva Agencia de Protección de Datos Personales, el organismo encargado de fiscalizar el cumplimiento de la norma.
La comunidad tecnológica suele debatir en foros y redes sobre arquitecturas redundantes, tolerancia a fallos y alta disponibilidad. Sin embargo, cuando el "desastre" ocurre en el mundo físico, no hay failover automático ni respaldo en la nube que pueda solucionarlo con un clic.
Senior DevOps Engineer en Intruder. Interesado por entornos basados en Kubernetes, arquitecturas nativas de la nube, procesos CI/CD e infraestructura como código. Autor de la serie de libros Érase una vez Kubernetes/Docker