What's the difference between a PersistentVolume and a PersistentVolumeClaim?

A PersistentVolume is a cluster-scoped storage resource, provisioned by an admin or a storage driver, describing an actual piece of storage (a disk, an NFS export, a cloud volume). A PersistentVolumeClaim is a namespaced request for storage that a Pod makes, which Kubernetes binds to a matching PersistentVolume. Use this tool for the PV itself; use the PersistentVolumeClaim Generator for the claim that consumes it.

Why isn't there a cloud-provider (EBS/GCE/Azure Disk) source option?

In-tree cloud volume plugins are deprecated in favor of CSI (Container Storage Interface) drivers, whose PV YAML is driver-specific (a `csi` block with a driver name and volume handle) rather than a small set of common fields. hostPath and NFS are still the two source types you'll hit most often when hand-writing a PV for local development, a lab cluster, or a legacy NFS-backed setup, so this tool focuses on those.

What does the reclaim policy actually control?

It controls what happens to the underlying storage after the bound PersistentVolumeClaim is deleted. 'Retain' keeps the PV and its data around for manual cleanup (safest default for anything you care about), 'Delete' removes the PV and, for dynamically provisioned volumes, asks the storage backend to delete the underlying storage too, and 'Recycle' (deprecated) does a basic `rm -rf` scrub before making the volume available again.

Does hostPath work in a multi-node cluster?

Only if the Pod using it is scheduled onto the exact node where that path exists, since hostPath just points at a directory on one node's local filesystem. It's fine for single-node clusters (kind, minikube) or node-pinned workloads, but not a substitute for shared storage across a real multi-node cluster.

PersistentVolume YAML Generator

Overview

Introduction

Writing a PersistentVolume manifest by hand means remembering the exact nesting for capacity, access modes, and whichever storage backend you're pointing at, and it's easy to typo a quantity suffix or forget the reclaim policy entirely.

This tool builds a PersistentVolume manifest from a form: pick a capacity, one or more access modes, a reclaim policy, and a hostPath or NFS source, and get back valid YAML you can apply directly.

What Is Kubernetes PersistentVolume Generator?

A form-based generator for the `v1/PersistentVolume` resource, the cluster-scoped object that represents a real, provisioned piece of storage in Kubernetes.

It supports the two source types you're most likely to hand-write: `hostPath` (a directory on a specific node, useful for local/dev clusters) and `nfs` (a network filesystem export reachable from any node), plus the common capacity, accessModes, and persistentVolumeReclaimPolicy fields every PV needs regardless of source.

How Kubernetes PersistentVolume Generator Works

Your inputs map directly onto the PV spec: `capacity.storage` gets your entered quantity (validated against Kubernetes' quantity suffixes like Gi/Mi/Ti), `accessModes` becomes a list of the modes you toggled on, and `persistentVolumeReclaimPolicy` is set to whichever policy you selected.

Depending on the source type toggle, the tool emits either a `hostPath.path` block or an `nfs.server`/`nfs.path` block, and nothing else, so the output only contains fields relevant to your chosen backend.

When To Use Kubernetes PersistentVolume Generator

Use it when standing up a local or lab cluster (kind, minikube, k3s) and you need a quick hostPath-backed PV to bind a PVC against, without digging through the docs for the exact YAML shape.

It's also useful for NFS-backed clusters where storage is provisioned manually rather than through a CSI driver and dynamic provisioning.

Often used alongside Kubernetes PersistentVolumeClaim Generator and Kubernetes StatefulSet Generator.

Features

Advantages

Validates capacity as a real Kubernetes quantity (e.g. '10Gi') before generating anything, catching a common source of `kubectl apply` rejections.
Only emits the source-specific fields for whichever backend (hostPath or NFS) you actually selected, keeping the output minimal and readable.
Covers all three access modes and all three reclaim policies in one form, so you don't need to memorize their exact spelling.

Limitations

Doesn't generate CSI-based PVs (cloud block/file storage via a driver), since those fields are driver-specific rather than a small common set.
Doesn't create the matching PersistentVolumeClaim, use the PersistentVolumeClaim Generator alongside this one to bind against the PV.

Examples

A 10Gi hostPath PV for local development

Input

name: local-data-pv, capacity: 10Gi, accessModes: [ReadWriteOnce], reclaimPolicy: Retain, sourceType: hostPath, hostPath: /mnt/data

Output

apiVersion: v1
kind: PersistentVolume
metadata:
  name: local-data-pv
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  hostPath:
    path: /mnt/data

A minimal hostPath PV, suitable for binding a single-node PVC in a local dev cluster.

Best Practices & Notes

Best Practices

Default to 'Retain' for anything with real data, and only use 'Delete' once you're confident the underlying storage backend's delete behavior is what you expect.
Set a `storageClassName` when you want explicit, non-dynamic binding to a specific PVC rather than relying on the default storage class.
Prefer NFS (or a real CSI driver) over hostPath for anything that needs to survive a Pod being rescheduled to a different node.

Developer Notes

The generator treats `capacity`, `accessModes`, and `persistentVolumeReclaimPolicy` as always-present fields and only branches on the source type for the `hostPath` vs `nfs` block, matching how the upstream API schema itself is structured (source types are mutually exclusive oneOf-style fields under `spec`). Quantity validation is a regex against the common binary suffixes (Ki/Mi/Gi/Ti/Pi/Ei); it does not attempt to validate decimal SI suffixes or exponent notation, which are rarer in hand-written manifests.

Kubernetes PersistentVolume Generator Use Cases

Provisioning a hostPath-backed PV for a local kind/minikube cluster
Wiring up an NFS export as cluster storage for a lab or on-prem environment
Quickly producing a PV to pair with a hand-written PersistentVolumeClaim during a tutorial or demo

Common Mistakes

Forgetting that hostPath only works if the consuming Pod lands on the same node the path exists on.
Setting reclaimPolicy to 'Delete' on a PV backed by data you actually want to keep.
Mismatching accessModes between the PV and the PVC that's supposed to bind to it, which prevents binding entirely.

Tips

Feed the generated PV's name and storageClassName into the PersistentVolumeClaim Generator to make sure the two manifests are compatible.

Kubernetes PersistentVolume Generator