A local volume exposes storage attached to one Kubernetes node. Unlike a hostPath volume, it lets the scheduler keep a pod on the node containing its data and limits arbitrary host-path access through PersistentVolume management. section 10.3.1
A local volume uses a pre-provisioned storage path and binds through the usual storage objects:
- An administrator creates a StorageClass with the no-provisioner setting and WaitForFirstConsumer binding mode. section 10.3.1
- The administrator defines a PersistentVolume with a local path, capacity, access mode, and node affinity naming the storage node. section 10.3.1
- A developer creates a PersistentVolumeClaim and mounts it in a pod like any other claim. section 10.3.2
- When the pod is created, the claim binds and the scheduler places the pod on the volume’s node. section 10.3.2
Binding a pod to node-local storage
Create a local PersistentVolume for /tmp/my-disk, create a claim such as quiz-data-local, and mount that claim in a pod. The claim remains unbound until the pod exists because binding waits for the first consumer; afterward, kubectl get pvc shows the claim bound to local-disk-on-my-node. section 10.3.1 section 10.3.2
Listing 10.8 Defining a local PersistentVolume
kind: PersistentVolume
apiVersion: v1
metadata:
name: local-disk-on-my-node #1
spec:
accessModes:
- ReadWriteOnce
storageClassName: local #2
capacity:
storage: 10Gi
local: #3
path: /tmp/my-disk #3
nodeAffinity: #4
required: #4
nodeSelectorTerms: #4
- matchExpressions: #4
- key: kubernetes.io/hostname #4
operator: In #4
values: #4
- insert-the-name-of-the-node-with-the-disk #4
Inspect the PersistentVolume manifest to see how the local path and required node affinity connect storage to one node. section 10.3.1
Node locality is also the main limitation. If a StatefulSet pod’s node fails, its replacement can remain Pending because the local volume’s node affinity prevents scheduling elsewhere. The data cannot automatically follow the pod to another node. section 16.2.2
