Compare the Kubernetes volume types emptyDir, hostPath, and generic ephemeral volumes (the ephemeral.volumeClaimTemplate field in a Pod spec). What is each for, and why is hostPath discouraged in multi-tenant clusters?

## Three ways to get non-persistent storage All three types appear under `spec.volumes` and none of them is meant to outlive the Pod. They differ in *where the bytes live* and *who controls them*. ### emptyDir Kubelet creates a directory under its own data root on the node when the Pod is bound there, mounts it into the requesting containers, and deletes it when the Pod is removed. Key properties: - Survives container restarts inside the Pod; does not survive rescheduling. - `medium: Memory` makes it a tmpfs: RAM-backed, very fast, cleared on Pod removal, and — importantly — the bytes count toward the Pod's memory usage and can trigger an OOM kill. - `sizeLimit` bounds usage; exceeding it makes the Pod eligible for eviction. Without it, one Pod filling the node's disk causes `DiskPressure`, image garbage collection, and evictions of unrelated Pods. Ephemeral-storage requests/limits on containers are the companion control. - Contents are only visible to containers in that Pod, which is exactly why it is the idiomatic init-container handoff. ### hostPath This mounts an existing (or, with some types, newly created) path from the node's filesystem straight into the container. It is the sharpest tool in the box: - **Security.** A Pod that can mount `/` reads every secret on the node. Mounting the container runtime socket (`/var/run/containerd/containerd.sock`) is effectively root on the node, because you can start a privileged container. Mounting kubelet's directory exposes every projected ServiceAccount token on that node. Mounting a writable host binary or unit directory allows persistence. For these reasons the Pod Security Standards forbid hostPath in Baseline and Restricted, and policy engines usually block it outright or allow only an explicit path allowlist. - **Correctness.** The data is node-local and nothing replicates or recreates it. Reschedule the Pod and it sees a different node's filesystem — usually an empty or nonexistent path. `type: DirectoryOrCreate` then silently creates an empty directory, which turns a storage bug into a data-loss-looking bug. - **Ownership and SELinux/permissions** are the node's, not Kubernetes', so files often appear root-owned and unreadable by a non-root container. Legitimate uses are all *node-agent* shaped, run as DaemonSets by cluster operators: log collectors reading `/var/log`, metrics exporters reading `/proc` and `/sys`, CNI/CSI plugins writing to their plugin directories. If your application is not an agent for the node itself, hostPath is the wrong answer — and for node-local *persistent* storage, the supported mechanism is a `local` PersistentVolume with node affinity, which at least makes the node pinning explicit to the scheduler. ### Generic ephemeral volumes Declared inline in the Pod: ``` volumes: - name: scratch ephemeral: volumeClaimTemplate: spec: accessModes: ["ReadWriteOnce"] storageClassName: fast-ssd resources: { requests: { storage: 200Gi } } ``` Kubernetes creates a PVC named `<pod>-<volume>` owned by the Pod. It is provisioned by a normal StorageClass through the normal dynamic-provisioning path, and when the Pod is deleted the owner reference garbage-collects the PVC, which — with the usual `Delete` reclaim policy — destroys the volume. Why it exists: emptyDir can only give you node disk, with no class, no IOPS guarantee, no block mode, and no isolation from other Pods' writes. Generic ephemeral volumes give you everything dynamic provisioning offers with Pod-scoped lifetime. They are the right choice for large build caches, scratch space for data processing, or anything needing a specific performance tier temporarily. A related, narrower type is the **CSI ephemeral volume** (`csi:` inline in the Pod), used by drivers that inject data rather than provide capacity — secrets-store drivers being the common example. That path does not create a PVC at all. ## Choosing quickly - Small scratch, no special requirements → **emptyDir** with a `sizeLimit`. - Need real capacity, a storage class, or block mode, but only for the Pod's life → **generic ephemeral volume**. - Need to read or write the node itself, and you are writing a node agent → **hostPath**, narrowly scoped, read-only where possible. - Need data to survive the Pod → none of these; use a PersistentVolumeClaim.