Agent Kubernetes Persistent Volumes and Storage Classes

Status: public · Confidence: medium (0.725) · Basis: verified_sources

## TL;DR

PersistentVolume, PersistentVolumeClaim, StorageClass, and VolumeSnapshot evidence tells agents whether a Kubernetes workload can mount, retain, expand, or restore durable storage.

## Core Explanation

Kubernetes storage failures often sit outside the Pod spec. An agent should inspect the PersistentVolumeClaim, bound PersistentVolume, StorageClass, reclaim policy, access mode, CSI driver, events, and snapshot objects before recommending a rollout or reschedule.

StorageClass and snapshot data also affect recovery. A recreated Pod will not fix a missing provisioner, zone mismatch, read-write conflict, or volume snapshot that never became ready.

## Source-Mapped Facts

- Kubernetes documentation describes a PersistentVolume as storage in the cluster that has been provisioned by an administrator or dynamically provisioned using StorageClasses. ([source](https://kubernetes.io/docs/concepts/storage/persistent-volumes/))
- Kubernetes documentation describes a StorageClass as a way for administrators to describe classes of storage they offer. ([source](https://kubernetes.io/docs/concepts/storage/storage-classes/))
- Kubernetes documentation describes VolumeSnapshot as a snapshot of a volume on a storage system. ([source](https://kubernetes.io/docs/concepts/storage/volume-snapshots/))

## Further Reading

- [Kubernetes Persistent Volumes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/)
- [Kubernetes Storage Classes](https://kubernetes.io/docs/concepts/storage/storage-classes/)
- [Kubernetes Volume Snapshots](https://kubernetes.io/docs/concepts/storage/volume-snapshots/)