Local Persistent Volume

The manual creation of a PersistentVolume (PV) by an administrator that maps to a specific local disk path. Unlike dynamic provisioning, which uses a StorageClass to automatically create volumes, static provisioning requires pre-creating the PV with a nodeAffinity rule that binds it to a specific node. This is the standard method for Local Persistent Volumes because the disk is physically attached to a single machine.

• PV spec must include persistentVolumeReclaimPolicy: Retain to prevent data deletion
• Pod scheduling is automatically constrained to the node where the physical disk resides
• Essential for air-gapped environments where dynamic provisioners may not be available

The scheduling constraints that guarantee a pod consuming a Local Persistent Volume lands on the exact node with the physical disk. The PV's nodeAffinity field specifies required node labels, while Node Taints with tolerations prevent other workloads from consuming the dedicated storage hardware.

• Use requiredDuringSchedulingIgnoredDuringExecution for hard binding
• Combine with GPU taints to co-locate compute and high-speed storage on the same node
• Critical for data locality in distributed training where shuffle operations benefit from local disk

While both reference a directory on the node's filesystem, HostPath is intended for single-node testing and is not suitable for production. Local Persistent Volumes survive pod restarts and rescheduling because they are managed as first-class PV resources with proper lifecycle management.

• HostPath: No binding guarantees, data lost on pod eviction, no capacity tracking
• Local PV: Persistent across pod lifecycle, supports ReadWriteOnce access mode, integrates with PVC binding
• Local PVs are the production-grade evolution for stateful AI workloads requiring direct disk access

Local Persistent Volumes do not natively support CSI snapshotting because the data is tied to a single physical disk. To protect data, implement application-level replication or use tools like Velero with restic integration to back up local volume contents to object storage.

• Restic can stream filesystem-level backups from local volumes
• For databases like etcd or CockroachDB, rely on native replication instead of storage snapshots
• In air-gapped environments, backup targets must be on-premises object stores like MinIO

A Kubernetes feature that ensures pods are scheduled with awareness of the underlying hardware topology, including NUMA nodes, PCIe lanes, and local storage attachment. When combined with Local PVs, topology-aware scheduling guarantees that a pod requesting a local NVMe drive is placed on the CPU socket directly connected to that drive.

• Enabled via the Topology Manager kubelet component
• Uses hint providers from the CPU Manager, Device Manager, and storage plugins
• Reduces cross-socket memory access latency for latency-sensitive inference workloads

A contrasting storage pattern where the volume lifecycle is tied to the pod, not an independent PV resource. Generic Ephemeral Volumes can use a StorageClass to dynamically create temporary local storage that is deleted when the pod terminates.

• Useful for scratch space during data preprocessing or model compilation
• Avoids the manual PV management overhead of static provisioning
• Not suitable for datasets that must persist across pod restarts or rescheduling