Static provisioning creates storage before an application requests it. An administrator manually provisions each underlying volume and creates a matching PersistentVolume object; users then create PersistentVolumeClaims that claim suitable existing volumes. section 10.1.2 section 10.3
A static-provisioning workflow follows these relationships:
- Provision one or more persistent storage volumes using a supported storage technology. section 10.3
- Create a PersistentVolume object for each pre-provisioned volume. section 10.1.2
- Create a PersistentVolumeClaim specifying requirements such as minimum capacity, access mode, and volume mode. section 10.2.1
- Let Kubernetes bind the claim to an existing PersistentVolume that satisfies those requirements. section 10.6
Node-local storage
An administrator pre-provisions a disk attached to a node and represents it with a PersistentVolume. A workload creates a claim for the required storage, and Kubernetes binds that claim to the matching local volume. Static provisioning of network-attached storage follows a similar procedure. section 10.3 section 10.6
Releasing and reusing a volume
Deleting a pod leaves its claim and PersistentVolume intact. Deleting the claim typically moves a statically provisioned volume to Released under the Retain policy. A new claim cannot immediately reuse it; an administrator must remove and recreate the PersistentVolume object after handling the existing data. section 10.3.3
Figure 10.6 Static provisioning of PersistentVolumes
Shows the administrator-managed relationship between pre-provisioned storage volumes and their PersistentVolume objects. section 10.1.2
