Access Modes & Reclaim Policy

Access modes and reclaim policies are two critical settings that control how persistent volumes behave. Access modes determine how many pods can access a volume and in what way, while reclaim policies determine what happens to the volume and its data when the PVC is deleted. Understanding these settings helps you configure storage correctly for your applications.

Access Modes

Access modes define how a PersistentVolume can be mounted. They control whether one or multiple pods can access the volume, and whether those pods can read, write, or both.

ReadWriteOnce (RWO)

Allows the volume to be mounted as read-write by a single node. This is the most common access mode and works with most storage types (AWS EBS, GCE Persistent Disk, Azure Disk, local storage).

Use cases:

• Databases (MySQL, PostgreSQL, MongoDB)
• Single-instance applications with persistent data
• Any application where only one pod needs write access

Limitations:

• Only one pod can mount the volume at a time
• Multiple pods on the same node can share the volume (rarely used)

ReadOnlyMany (ROX)

Allows the volume to be mounted as read-only by multiple nodes. Useful for distributing configuration files, shared libraries, or read-only data to many pods.

Use cases:

• Configuration files shared across multiple pods
• Read-only reference data
• Shared libraries or assets

Limitations:

• No write access allowed
• Not all storage types support ROX

ReadWriteMany (RWX)

Allows the volume to be mounted as read-write by multiple nodes. This is the most flexible but also the most restrictive in terms of which storage backends support it.

Use cases:

• Shared file storage (web content, user uploads)
• Content management systems
• Applications that need shared writable storage

Limitations:

• Only supported by network-based storage (NFS, some cloud file storage)
• Performance can be slower than RWO due to network overhead

Access Mode Selection Guide

Reclaim Policy

Reclaim policy determines what happens to a PersistentVolume when its bound PersistentVolumeClaim is deleted. This is a critical setting because it affects data persistence and storage cleanup.

Retain

When a PVC is deleted, the PV is retained but not automatically deleted. The PV status becomes “Released” and can be manually reclaimed. The data on the volume remains intact.

Use cases:

• Critical data that must not be accidentally deleted
• Manual backup before deletion
• Compliance requirements for data retention

Important: Retained PVs cannot be reused until manually cleaned up. You must manually delete the PV and the underlying storage.

Delete

When a PVC is deleted, the PV is automatically deleted, and the underlying storage is destroyed. All data is permanently lost.

Use cases:

• Development and testing environments
• Temporary data
• Ephemeral workloads
• When automatic cleanup is desired

Important: This is the default for dynamically provisioned volumes. Be careful in production environments where data loss is unacceptable.

Recycle

Deprecated - This policy is deprecated and should not be used. It was used to wipe the volume and make it available for reuse, but it’s been replaced by dynamic provisioning with StorageClasses.

Reclaim Policy Selection Guide

Combining Access Modes and Reclaim Policies

Here’s an example showing how access modes and reclaim policies work together:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: database-pvc
spec:
  accessModes:
    - ReadWriteOnce  # Only one pod can mount
  resources:
    requests:
      storage: 20Gi
  storageClassName: standard
---
apiVersion: v1
kind: Pod
metadata:
  name: database
spec:
  containers:
  - name: postgres
    image: postgres:14
    volumeMounts:
    - name: data
      mountPath: /var/lib/postgresql/data
  volumes:
  - name: data
    persistentVolumeClaim:
      claimName: database-pvc

The StorageClass defines the reclaim policy:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: standard
provisioner: kubernetes.io/gce-pd
parameters:
  type: pd-standard
reclaimPolicy: Retain  # Data retained when PVC deleted

Best Practices

1. Use RWO for databases - Most databases need exclusive write access
2. Use RWX sparingly - Only when truly needed, and understand performance implications
3. Retain for production - Use Retain policy in production to prevent accidental data loss
4. Delete for development - Use Delete policy in dev/test to simplify cleanup
5. Document policies - Make reclaim policies explicit in StorageClasses and document them
6. Test data recovery - Understand how to recover data with Retain policy before you need it
7. Match access mode to use case - Don’t use RWX if you only need RWO (better performance)

Common Patterns

Database Pattern (RWO + Retain)

# StorageClass for databases
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: database-storage
provisioner: kubernetes.io/gce-pd
parameters:
  type: pd-ssd
reclaimPolicy: Retain  # Protect database data

Shared Content Pattern (RWX + Delete)

# StorageClass for shared content
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: shared-content
provisioner: kubernetes.io/gce-pd
parameters:
  type: pd-standard
reclaimPolicy: Delete  # Auto-cleanup for shared files

Topics

• Access Modes - Detailed explanation of each access mode
• Reclaim Policy - Detailed explanation of reclaim policies

See Also

• PVs & PVCs - How to create and use persistent volumes
• StorageClasses - Dynamic provisioning and storage templates