About this scenario
hello 2.1 reads /etc/hello/config.yaml. The file used to come from a gitRepo volume. Kubernetes 1.36 removed that volume type for good, so it was taken out of the Deployment, and the Pods now crash on startup.
CI already publishes the config as an OCI artifact, ghcr.io/k8wiz/hello-config:2.1. Image volumes, stable since Kubernetes 1.36, mount the files of an OCI image or artifact into a Pod, read-only. Mount it at /etc/hello.
Objectives
- Read why hello crashes
- Mount ghcr.io/k8wiz/hello-config:2.1 at /etc/hello as an image volume
- hello runs 3 ready replicas
- See the greeting the mounted config sets
What you'll practice
- Kubernetes 1.36 removed the gitRepo volume for good, because it could let an attacker run code as root on the node. Replace it with an init container that clones the repo, or with an image volume.
- An image volume mounts the files of an OCI image or artifact, read-only, without baking them into the app's image. The kubelet pulls it like a container image, with the same pull policy and events.
- Config, models and static content can ship through your registry (for example with
oras push) and roll out by changing a tag. - Image volumes need a container runtime that supports them, such as containerd 2.1 or later.
How the playground works
The cluster runs entirely in your browser: a simulated API server, scheduler, kubelets and controllers, with virtual nodes in three zones. kubectl output follows the real formats, errors use the real messages, and the add-ons (CSI storage, Traefik, Envoy Gateway, cert-manager, Flux, Argo CD) behave like their real counterparts for the common paths. It's a simulation, so some behavior is simplified. Your progress is saved in this browser.