ConfigMap and Secret as Files
How does a ConfigMap or Secret volume change under a running app without showing a half-written file? Kubelet writes the keys the volume asks for as files in a hidden timestamped directory behind the ..data symlink. An update writes the new version beside it, renames a ..data_tmp link over ..data, atomic on Linux, and deletes the old one. It lands on the next Kubelet sync after the cache catches up, the app keeps running, and on Linux a Secret volume is tmpfs.
Play the animation 3 steps, animated, best on a wide screen
ConfigMap and Secret as Files, step by step
-
By default Kubelet watches ConfigMap app on the API server. Before the container starts it writes every key as a file, or only the keys the volume lists in items, into a hidden timestamped directory, then points the ..data symlink at it. The app.conf entry is a symlink to ..data/app.conf. On Linux a Secret volume is built the same way, on tmpfs.
Play from step 1 -
Someone edits ConfigMap app. The watch updates the Kubelet cache, and on its next periodic sync, by default up to about 90 seconds later, Kubelet writes the whole v2 into a second timestamped directory. Nothing points at it yet, so the app still reads v1.
Play from step 2 -
In the same sync, Kubelet points a new ..data_tmp symlink at v2 and renames it over ..data. On Linux the rename is atomic, so opening app.conf gets all of v1 or all of v2, never a mix, and only then is the v1 directory deleted. Nothing restarts the app: the next time it opens app.conf, it reads v2. A subPath mount of app.conf would keep v1 until its container restarts.
Play from step 3