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 from 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 the cloud-native environment. Several applications already use container images to store information in OCI (Open Container Initiative) format. Popular tools like 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 often required cloud storage services like 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 quite simple and relies on standard ecosystem tools.

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

This approach requires no additional tools. We simply create a Dockerfile starting from an empty image and copy our data inside:

FROM scratch

COPY ./files /

And 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, you define the volume in the volumes section of your Pod referencing the image, and then mount it into the container using volumeMounts.

Here is a simple example of how to configure it:

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 content of the image ghcr.io/mmorejon/erase-una-vez-5:main will be available inside the container at the path /srv/data.

How to test it today?

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

However, don’t let that stop you. You can use the once-upon-a-time-k8s repository to spin up a compatible local cluster in seconds (approximately 40 seconds). It’s an excellent way to experiment with these new features in your own development environment.

Create your local cluster using the once-upon-a-time-k8s repository.

For those of us who live in the terminal, here are the steps to reproduce it right now:

1. 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

2. Create the cluster (requires Docker installed)

./bash/cluster.sh create

3. Deploy the example pod

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

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 is another step towards standardization and simplification in Kubernetes. I encourage you to try it out and discover how it can optimize your data and configuration workflows.