OCI Images as Kubernetes Volumes: A New Era for Data Management

A new volume type has recently joined the Kubernetes ecosystem: the image volume. This feature, available starting with version 1.35.0 and currently in beta, promises to change how we manage static data and configurations in our clusters.

The relevance of this volume type has been growing in cloud-native environments. Several applications already use container images to store information in OCI (Open Container Initiative) format. Popular tools such as Falco (for security rules), Kyverno (for policies), and FluxCD (for deployment management) are clear examples of this trend. Now, this capability is native to Kubernetes.

Benefits of Using OCI Images for Data

Adopting this pattern in your applications brings significant advantages:

1. Infrastructure Simplification: Until now, managing external files has often required cloud storage services such as S3 or GCS. This involved additional costs, bucket management, and permission configuration. By using the image volume, you do away with these external services, simplifying your architecture.
2. Integrated Security: Since these are standard OCI images, you can use the same vulnerability scanning tools you already use for your applications. This ensures that the configuration files or data you introduce do not contain known vulnerabilities.
3. Faster Deployments: If you separate source code from data, you can update configurations by generating a new data image (lighter) without needing to rebuild the entire application image.

How to Create Data Images

With this functionality enabled, the need arises to create these “data images.” Although it might sound complex, the process is straightforward and relies on standard ecosystem tools.

A simple, native, and easy-to-implement approach is to use Docker with the scratch image.

This method requires no additional tools. You simply create a Dockerfile that starts from an empty image and copies your data into it:

FROM scratch

COPY ./files /

The build process is the standard one you already know:

$ docker image build -t ghcr.io/mmorejon/erase-una-vez-5:main .

$ docker image push ghcr.io/mmorejon/erase-una-vez-5:main

Usage Example

To use this volume type, define the volume in the volumes section of your pod by referencing the image, and then mount it into the container using volumeMounts.

Here is a simple configuration example:

apiVersion: v1
kind: Pod
metadata:
  name: volume-example
spec:
  containers:
    - name: app
      image: ghcr.io/mmorejon/erase-una-vez-1:v0.3.2
      volumeMounts:
        - name: data-volume
          mountPath: /srv/data
  volumes:
    - name: data-volume
      image:
        reference: ghcr.io/mmorejon/erase-una-vez-5:main
        pullPolicy: IfNotPresent

In this case, the contents of the image ghcr.io/mmorejon/erase-una-vez-5:main will be available inside the container at /srv/data.

How to Test It Today

To use this functionality, you need a Kubernetes cluster running version 1.35.0. Since this version is very recent, it may not yet be available from major cloud providers such as Azure, AWS, or GCP.

However, you can still experiment locally. The erase-una-vez-k8s repository allows you to spin up a compatible cluster in approximately 40 seconds, making it an excellent way to explore these new features.

Create your local cluster using the erase-una-vez-k8s repository.

For those who live in the terminal, here are the steps to reproduce it:

Clone the repository with the ready-to-use environment:

$ git clone https://github.com/mmorejon/once-upon-a-time-k8s.git

$ cd once-upon-a-time-k8s

Create the cluster (Docker required):

$ ./bash/cluster.sh create

Creating cluster "book" ...

 ✓ Ensuring node image (kindest/node:v1.35.0)
 ✓ Preparing nodes
 ✓ Writing configuration
 ✓ Starting control-plane
 ✓ Installing CNI
 ✓ Installing StorageClass
 ✓ Joining worker nodes

Set kubectl context to "kind-book"
You can now use your cluster with:

kubectl cluster-info --context kind-book

Have a nice day!

Deploy the example:

$ kubectl apply -f https://raw.githubusercontent.com/mmorejon/erase-una-vez-5/refs/heads/main/manifest.yaml

pod/erase-una-vez-5 created

Check the pods running in the cluster:

$ kubectl get pods

NAME              READY   STATUS    RESTARTS   AGE
erase-una-vez-5   1/1     Running   0          16s

List all files mounted in the pod:

$ kubectl exec erase-una-vez-5 -- ls -la /usr/share/nginx/html/

total 16
drwxr-xr-x    1 root     root          4096 Jan 23 20:33 .
drwxr-xr-x    3 root     root          4096 Dec 18 00:29 ..
-rw-r--r--    1 root     root            26 Jan 22 13:57 example-1.txt
-rw-r--r--    1 root     root            55 Jan 22 13:57 example-2.txt

And the moment of truth. Verify that the volume has been mounted correctly:

$ kubectl exec erase-una-vez-5 -- cat /usr/share/nginx/html/example-2.txt

> The scratch image was used to create the OCI artifact.

The image volume type represents another step toward standardization and simplification in Kubernetes. I encourage you to try it out and explore how it can optimize your data and configuration workflows.

Summary: Why This Feature Matters

The introduction of OCI images as Kubernetes volumes represents a fundamental shift in how we approach data and configuration management in cloud-native environments. This feature addresses critical pain points that have long plagued Kubernetes deployments:

Operational Excellence: By eliminating the need for external storage services like S3 or GCS for static data, organizations can reduce infrastructure complexity, lower costs, and minimize the attack surface of their applications. The native integration with Kubernetes means one less external dependency to manage, monitor, and secure.

Security by Design: The ability to scan data images with the same vulnerability tools used for application images closes a significant security gap. Configuration files and static data are no longer blind spots in your security posture — they're first-class citizens in your security pipeline.

Developer Velocity: The separation of code from data enables faster iteration cycles. Teams can update configurations independently of application releases, reducing deployment friction and enabling more agile development practices.

Industry Alignment: With major tools like Falco, Kyverno, and FluxCD already adopting this pattern, Kubernetes is now aligning with industry best practices. This native support ensures consistency across the ecosystem and reduces developers' cognitive load when working with multiple tools.