PersistentVolume (PV)

2026-05-27·CKA k8s Practice

CKA Exam Domain 4 — PV core concepts, storage types, access modes, reclaim policies, lifecycle

← Back to CKA Practice Index A PersistentVolume (PV) is a piece of storage in the cluster that has been provisioned by an administrator or dynamically provisioned via StorageClass. PVs are cluster resources independent of any Pod lifecycle, and Pods use PVs through PersistentVolumeClaims (PVCs).

1. Supported Storage Types

Kubernetes supports a variety of backend storage systems. Common ones include:

Storage Type	Description
`hostPath`	Node local disk (for single-node testing only)
`NFS`	Network File System
`iSCSI`	iSCSI block storage
`AWS EBS`	AWS Elastic Block Storage
`GCE PD`	Google Compute Engine Persistent Disk
`Azure Disk / Azure File`	Azure Disk / File storage
`Ceph RBD / CephFS`	Ceph block storage / filesystem
`Portworx Volumes`	Portworx storage
`Local`	Locally mounted disk (manual management)
`CSI`	Container Storage Interface (universal extension)

Exam Note: The three types hostPath, NFS, and CSI frequently appear in the CKA exam.

2. Access Modes

Mode	Abbreviation	Description
`ReadWriteOnce`	RWO	Read and write by a single node
`ReadOnlyMany`	ROX	Read-only by many nodes
`ReadWriteMany`	RWX	Read and write by many nodes
`ReadWriteOncePod`	RWOP	Read and write by a single Pod (v1.22+)

A PV can support multiple access modes, but only one mode can be used at binding time.

accessModes:
  - ReadWriteOnce

3. Reclaim Policy

When a PVC is deleted, the PV's reclaim policy determines what happens to the storage resource:

Policy	Behavior
`Retain`	Retains the PV and underlying data; requires manual cleanup by administrator
`Recycle`	Runs `rm -rf /volume/*` then becomes available again (deprecated)
`Delete`	Automatically deletes the PV and associated storage resource (common with dynamic provisioning)

persistentVolumeReclaimPolicy: Retain

4. Volume Mode

Mode	Description
`Filesystem`	Default mode, mounted as a filesystem
`Block`	Raw block device (e.g., for database-specific storage)

volumeMode: Filesystem

5. PV Lifecycle

Available ──► Bound ──► Released ──► Failed

Phase	Description
`Available`	Available, not yet bound to any PVC
`Bound`	Bound to a PVC
`Released`	PVC has been deleted, PV not yet reclaimed
`Failed`	Automatic reclamation failed

6. hostPath PV Example

For single-node testing environments only, not suitable for production.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: hostpath-pv
spec:
  capacity:
    storage: 1Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  hostPath:
    path: /data/pv
    type: DirectoryOrCreate

7. NFS PV Example

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv
spec:
  capacity:
    storage: 10Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  nfs:
    server: 192.168.1.100
    path: /exports/data

8. Useful Commands

# View all PVs
kubectl get pv

# View PV details
kubectl describe pv <pv-name>

# Sort by storage capacity
kubectl get pv --sort-by=.spec.capacity.storage

# View PV YAML
kubectl get pv <pv-name> -o yaml

# Delete PV
kubectl delete pv <pv-name>

9. Exam Key Points

PVs are cluster resources and do not belong to any namespace
hostPath is only for single-node testing; use NFS, CSI, etc. for multi-node clusters
PV capacity cannot be dynamically modified (requires deletion and recreation)
persistentVolumeReclaimPolicy determines behavior after PVC deletion
Check PV status: kubectl get pv and look at the PHASE column

🧪 Complete Hands-On Example: Create hostPath PV and Observe Lifecycle States

Scenario

Create a hostPath-type PV and observe its full lifecycle from Available → Bound → Released, verifying access modes and reclaim policy.

Prerequisites

A single-node Kubernetes cluster (single node is sufficient)
The /data/pv directory exists on the node (PV will create it automatically)

Steps

Step 1: Create hostPath PV definition file

cat <<EOF > /tmp/hostpath-pv.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
  name: hostpath-pv
spec:
  capacity:
    storage: 1Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  hostPath:
    path: /data/pv
    type: DirectoryOrCreate
EOF

Step 2: Create PV and check initial status

kubectl apply -f /tmp/hostpath-pv.yaml

kubectl get pv
# NAME          CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   AGE
# hostpath-pv   1Gi        RWO            Retain           Available           manual         5s

At this point STATUS is Available, indicating the PV is ready and waiting for PVC binding.

Step 3: Create PVC to bind to PV

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: hostpath-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
EOF

Step 4: Verify PV status changes to Bound

kubectl get pv
# NAME          CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                  STORAGECLASS   AGE
# hostpath-pv   1Gi        RWO            Retain           Bound    default/hostpath-pvc   manual         30s

kubectl get pvc
# NAME           STATUS   VOLUME        CAPACITY   ACCESS MODES   STORAGECLASS   AGE
# hostpath-pvc   Bound    hostpath-pv   1Gi        RWO            manual         10s

STATUS changes to Bound, and the CLAIM column shows binding to default/hostpath-pvc.

Step 5: Delete PVC and observe Released status

kubectl delete pvc hostpath-pvc

kubectl get pv
# NAME          CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM                  STORAGECLASS   AGE
# hostpath-pv   1Gi        RWO            Retain           Released    default/hostpath-pvc   manual         60s

STATUS changes to Released, but because the reclaim policy is Retain, the PV is not automatically cleaned up and underlying data is preserved.

Step 6: Manually reclaim a Released PV

# To reuse this PV, manually delete and recreate it
kubectl delete pv hostpath-pv

# Clean up host data (optional)
# rm -rf /data/pv

Verification

# Verify Access Mode
kubectl get pv hostpath-pv -o jsonpath='{.spec.accessModes}'
# ["ReadWriteOnce"]

# Verify Reclaim Policy
kubectl get pv hostpath-pv -o jsonpath='{.spec.persistentVolumeReclaimPolicy}'
# Retain

# Verify Storage capacity
kubectl get pv hostpath-pv -o jsonpath='{.spec.capacity.storage}'
# 1Gi

Exam Tips

After creation, PV status is Available, changes to Bound after binding, and Released after PVC deletion
The Retain policy does not automatically delete the PV; administrators must clean it up manually
hostPath is only suitable for single-node test environments and is often used as a quick validation method in exams
Use kubectl get pv -o wide to view more field details