Kubernetes v1.33 promotes Image Volumes to beta, letting OCI artifacts mount directly into pods as read-only volumes, boosting portability and efficiency.
In Kubernetes v1.33, the Image Volume feature moves from alpha to beta—marking a major step toward enabling cleaner, container-native ways of managing read-only content in pods. While still disabled by default (due to ongoing runtime support gaps), the functionality is powerful enough to warrant early exploration, especially if you deal with model packaging, binary artifact delivery, or configuration management in your workloads.
In this post, we’ll walk through what Image Volumes are, what’s new in the beta release, and how you might use them in real-world scenarios.
Image Volumes allow you to mount an OCI image (or artifact) as a read-only volume inside a Kubernetes pod. Instead of bundling static content (like configuration files, machine learning models, or malware signatures) directly inside your main application container, you can:
Build a separate OCI artifact containing only the files you want
Push it to a registry (just like any other container image)
Mount it into your pod using the volumes.image.reference field
This clean separation between executable logic and passive data reduces image size, improves reuse, and better supports secure, composable workloads.
This feature is especially relevant for the growing set of Kubernetes users in the AI/ML, DevSecOps, and artifact distribution spaces.
Some practical use cases include:
Mounting ML model weights from a pre-packaged artifact without baking them into your model server image
Distributing signed configuration files from a central registry to multiple pods securely
Loading proprietary malware signatures into a public scanner image without rebuilding it
Until now, options to achieve these patterns were either clunky (init containers copying files), insecure (custom hostPath volumes), or hard to manage at scale (ConfigMaps with binary blobs). Image Volumes provide a clean, OCI-native alternative.
With v1.33, the feature now supports subPath and subPathExpr within volumeMounts. This lets you mount a specific subdirectory from the image volume into the container. It's a small but important change—it gives you finer control over which part of the image is exposed, avoiding unnecessary content being visible to the container.
Here's a quick example:
This mounts the contents of dir from the referenced image into /volume in the container.
Important: Subdirectories must already exist in the image volume. If not, the container will fail to start and kubelet will report the error using standard events.
CRI-O supports image volumes in beta, starting from v1.33.
containerd has merged alpha support and is actively working on beta support in PR #11578.
This means you may still need to enable the feature gate manually (ImageVolume=true) on your API server and kubelet, and ensure your runtime is up to date.
The SIG Node team is actively working toward feature stabilization and wider runtime support. We expect more feedback, real-world adoption, and additional use cases to emerge as the beta matures. If you're interested, get involved:
Join the conversation on Kubernetes Slack: #sig-node
With Image Volumes now in beta, Kubernetes is one step closer to treating container images as composable file systems—a move that better aligns with how modern infrastructure teams are designing pipelines and managing content.
Even though it’s still behind a feature gate, this is the right time to start testing the feature, identifying blockers, and preparing your workloads for the eventual GA.
Thanks to everyone involved in the community who helped drive this forward.
FAQs
What are Image Volumes in Kubernetes?
Image Volumes allow Kubernetes pods to mount an OCI image as a read-only volume. This separates executable logic from static data, enabling cleaner delivery of models, binaries, or config files without embedding them in the application container.
What use cases are Image Volumes best suited for?
They are ideal for scenarios like:
Serving ML models without bundling them in the container
Distributing signed config files securely
Loading proprietary data (e.g., malware signatures) into scanners These use cases benefit from clean, OCI-native data delivery.
What improvements are included in the Kubernetes v1.33 beta release of Image Volumes?
v1.33 introduces support for subPath and subPathExpr, allowing you to mount specific subdirectories of an image volume. It also adds kubelet metrics for tracking usage and mount success/failure.
Which container runtimes support Image Volumes as of v1.33?
CRI-O: Supports Image Volumes in beta starting with v1.33.
containerd: Has merged alpha support and is actively developing beta compatibility. The feature must be manually enabled via the ImageVolume feature gate.
What are the key implementation details developers should know?
Mounts are read-only and noexec
Pull behavior aligns with container image pulls and supports pull secrets
Compatible with the AlwaysPullImages admission controller
Uses standard container image layer mechanisms for mounting
Like what you read? Support my work so I can keep writing more for you.
