Persistent Volume
A Kubernetes PersistentVolume (PV) is a cluster-wide object that represents a piece of storage that has been provisioned either statically by an administrator or dynamically via a StorageClass. Unlike ephemeral volumes that are tied to the lifetime of a Pod, a PV exists independently and can outlive any consumer Pods, enabling stateful workloads to retain data across rescheduling or restarts. Each PV encapsulates details such as capacity, access modes, reclaim policy and the specifics of the underlying storage medium (for example, AWS EBS, NFS, or a CSI-provisioned backend).
Official documentation: https://kubernetes.io/docs/concepts/storage/persistent-volumes/
Terrafrom Mappings:
kubernetes_persistent_volume.metadata[0].name
kubernetes_persistent_volume_v1.metadata[0].name
Supported Methodsβ
GET
: Get a PersistentVolume by nameLIST
: List all PersistentVolumesSEARCH
: Search for a PersistentVolume using the ListOptions JSON format e.g.{"labelSelector": "app=wordpress"}
Possible Linksβ
ec2-volume
β
A PersistentVolume whose spec.awsElasticBlockStore
(or CSI driver) references an AWS EBS disk ultimately maps to an EC2 volume. Overmind links the PV to the underlying ec2-volume
so you can assess risks such as deletion protection, encryption status or capacity limits of the actual block device.
efs-access-point
β
When a PV is backed by Amazon EFS via the EFS CSI driver, it mounts the file system through a specific EFS Access Point. Linking the PV to the corresponding efs-access-point
lets you trace permissions, throughput and network configurations that could affect the workloadβs storage availability.
StorageClass
β
Most dynamically provisioned PVs include a storageClassName
field that references the StorageClass used to create them. By linking to the StorageClass
, Overmind shows the provisioning parameters, reclaim policy and allowed topologies that govern how this PV was created and how it behaves when released.