Kubernetes 1.36 adds image volumes

Kubernetes released version 1.36 on April 22, 2026, adding image volumes as a stable feature that lets pods mount content from OCI registries directly inside containers as read-only filesystems. The project’s documentation says the capability is enabled by default in v1.36 and can be used by setting a `volumes[*].image` field in a Pod spec. (kubernetes.io) The release team said v1.36 includes 70 enhancements, with 18 graduating to stable. Kubernetes says the 1.36 release series remains actively supported, with patch release 1.36.1 published on May 13, 2026. (kubernetes.io) ### What exactly did Kubernetes add in 1.36? (kubernetes.io) Kubernetes documentation describes an image volume as a volume source that represents an OCI object — a container image or artifact — available on the kubelet’s host machine. In practice, that means a pod can mount files packaged in an OCI image without treating that image as the application container itself. The docs show a pod mounting `quay.io/crio/artifact:v2` at `/volume` and reading files from that path. The Kubernetes release blog said OCI volume source support graduated to stable in v1.36. The enhancement tracking issue for KEP-4639 lists the stable release target as 1.36, after alpha in 1.31 and beta in 1.33-1.34. (kubernetes.io) ### Why would operators use this instead of an init container? Ivan Velichko wrote in an iximiuz Labs challenge that getting artifact contents into a pod historically required either an init container copying files into a shared `emptyDir` volume or baking those files into the application image itself. His challenge says image volumes provide a simpler option in Kubernetes v1.36 by letting the pod mount an OCI image directly as a volume. (kubernetes.io) Kubernetes documentation frames the feature as a way to mount content from OCI registries inside containers. The volumes concept page lists “providing read-only access to data in a different container image” as one of the supported use cases. (kubernetes.io) ### What does the pod spec look like? The Kubernetes task page says an image volume is enabled by setting `.spec.volumes[*].image.reference` to a valid OCI reference and then consuming that volume through `volumeMounts` in the container. The example uses `pullPolicy: IfNotPresent`, mounts the volume at `/volume`, and then reads files from paths inside the mounted image filesystem. (labs.iximiuz.com) Kubernetes also says `subPath` and `subPathExpr` can be used with image volumes from v1.33 onward. The documentation includes an example that mounts only the `dir` subpath from the OCI-backed volume into the container. (kubernetes.io) ### Where does Ivan Velichko’s example fit in? Ivan Velichko’s iximiuz Labs challenge uses an nginx pod and an OCI image containing a custom `index.html` page. The exercise asks users to deploy a pod named `nginx-1` in the default namespace, reference `registry.iximiuz.com/welcome-page:v1` as an image volume, and mount it at `/usr/share/nginx/html` so nginx serves the packaged page. (kubernetes.io) The challenge describes the pattern as a way to ship static assets, model weights and configuration files. That aligns with the Kubernetes feature’s core design in KEP-4639, which says the goal is to package and distribute binary artifacts using OCI image and distribution standards and mount them directly into pods. (kubernetes.io) ### What should users check before trying it? The Kubernetes task page says clusters need to be running Kubernetes server version v1.31 or later to follow the tutorial, though the feature state is listed as stable in v1.36. The same page says the container runtime must support image volumes, and users need `kubectl` configured against a cluster. (labs.iximiuz.com) Kubernetes lists version 1.36.1 as the latest patch release in the 1.36 series, released on May 13, 2026. The next scheduled patch target shown on the release page is 1.36.2 on June 9, 2026, and Velichko’s hands-on exercise remains available on iximiuz Labs for users who want to test the feature with a running nginx pod. (labs.iximiuz.com) (kubernetes.io 1) (kubernetes.io 2)