The local volume static provisioner manages PersistentVolume lifecycle for pre-allocated disks by detecting and creating PVs for each local disk on the host, and cleaning up the disks when released. It does not support dynamic provisioning.

• Overview
• User Guide
  • Getting started
  • Managing your local volumes
  • Deploying
  • Upgrading
  • FAQs
  • Best Practices
• Version Compatibility
• K8s Feature Status
  • 1.14: GA
  • 1.12: Beta
  • 1.10: Beta
  • 1.9: Alpha
  • 1.7: Alpha
  • Future features
• E2E Tests
  • Running
  • View CI Results
• Community, discussion, contribution, and support
  • Code of conduct

Local persistent volumes allows users to access local storage through the standard PVC interface in a simple and portable way. The PV contains node affinity information that the system uses to schedule pods to the correct nodes.

An external static provisioner is provided here to help simplify local storage management once the local volumes are configured. Note that the local storage provisioner is different from most provisioners and does not support dynamic provisioning. Instead, it requires that administrators preconfigure the local volumes on each node and if volumes are supposed to be

1. Filesystem volumeMode (default) PVs - mount them under discovery directories.
2. Block volumeMode PVs - create a symbolic link under discovery directory to the block device on the node.

The provisioner will manage the volumes under the discovery directories by creating and cleaning up PersistentVolumes for each volume.

A caveat to scheduling a Pod on the same node as its local PV is that when the node hosting the PV is deleted, while the data is likely lost, the PV object still exists and therefore the system is indefinitely trying to schedule the Pod to a deleted node. See our local volume node cleanup documentation which contains information on how to make your workloads automatically recover from node deletion.

To get started with local static provisioning, you can follow our getting started guide to bring up a Kubernetes cluster with some local disks, deploy local-volume-provisioner to provision local volumes and use PVC in your pod to request a local PV.

See our operations documentation which contains of preparing, setting up and cleaning up local volumes on the nodes.

See our helm documentation for how to deploy and configure local-volume-provisioner in Kubernetes cluster with helm.

If you want to manage provisioner with plain YAML files, you can refer to our example yamls. helm generated yamls are good sources of examples too. Here is a full explanation of provisioner configuration.

See our upgrading documentation for how to upgrade provisioner version or update configuration in Kubernetes cluster.

See FAQs.

See Best Practices.

Recommended provisioner versions with Kubernetes versions

Also see known issues and CHANGELOG.

• No new features added

• Added support for automatically formatting a filesystem on the given block device in localVolumeSource.path

• New PV.NodeAffinity field added.
• Important: Alpha PV NodeAffinity annotation is deprecated. Users must manually update their PVs to use the new NodeAffinity field or run a one-time update job.
• Alpha: Raw block support added.

• New StorageClass volumeBindingMode parameter that will delay PVC binding until a pod is scheduled.

• New local PersistentVolume source that allows specifying a directory or mount point with node affinity.
• Pod using the PVC that is bound to this PV will always get scheduled to that node.

• Local block devices as a volume source, with partitioning and fs formatting
• Dynamic provisioning for shared local persistent storage
• Local PV health monitoring, taints and tolerations
• Inline PV (use dedicated local disk as ephemeral storage)

Run ./hack/e2e.sh -h to view help.

Check testgrid sig-storage-local-static-provisioner dashboard.

Learn how to engage with the Kubernetes community on the community page.

You can reach the maintainers of this project at:

• Slack
• Mailing List

Participation in the Kubernetes community is governed by the Kubernetes Code of Conduct.