emptyDir Lifecycle
What happens to an emptyDir when a container restarts, or when its Pod is replaced on another Node? The Kubelet creates it empty when the Pod is assigned to a Node, every container that mounts it shares it, and a restart keeps it, but once the Pod leaves that Node it is deleted, and a replacement Pod gets a new, empty one. With medium: Memory it is a tmpfs that counts against the memory limit of the container writing to it.
Play the animation 6 steps, animated, best on a wide screen
emptyDir Lifecycle, step by step
-
Pod web-a is assigned to Node-1, and before any container starts, the Kubelet there creates its emptyDir: a new, empty directory on Node-1 storage. The spec says only emptyDir: {}, so there is no source and nothing to copy in.
Play from step 1 -
Both containers mount the same emptyDir at /cache. The app writes part-1 into it and the sidecar reads part-1 straight back, because every container that mounts it sees the same files.
Play from step 2 -
The app container crashes and the Kubelet restarts it. A container crash does not remove the Pod from Node-1, so the emptyDir stays, and the restarted app reads part-1 back from /cache.
Play from step 3 -
Node-1 is drained with --delete-emptydir-data. It is cordoned, marked unschedulable, then Pod web-a is evicted, and its ReplicaSet creates a replacement under a new name. A Pod removed from its Node for any reason loses its emptyDir, so part-1 is gone.
Play from step 4 -
The replacement, Pod web-b, lands on Node-2, since Node-1 is cordoned. Its emptyDir: {} brings nothing back, so the Node-2 Kubelet makes a new, empty directory and ls /cache finds no files. A PVC named in the template would still hold part-1.
Play from step 5 -
With medium: Memory, this emptyDir would be a tmpfs in Node-2 RAM, shared as before. Its bytes count against the memory limit of the container that writes them, and the tmpfs is capped at the 256Mi sizeLimit, or at the Pod memory limit if lower.
Play from step 6