Skip to content

Update persistent-volumes.md #153

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
noctarius merged 1 commit into from
Jun 18, 2026
Merged

Update persistent-volumes.md #153

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 5 additions & 1 deletion docs/architecture/concepts/persistent-volumes.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,7 +5,7 @@ weight: 30200
---

Persistent Volumes (PVs) in Kubernetes provide a mechanism for managing storage resources independently of individual
Pods. Unlike ephemeral storage, which is tied to the lifecycle of a Pod, PVs ensure data persistence across Pod restarts
Pods. Unlike ephemeral storage, which is tied to the lifecycle of a Pod, PVs ensure data persists across Pod restarts
and rescheduling, enabling stateful applications to function reliably in a Kubernetes cluster.

In Kubernetes, storage resources are abstracted through the Persistent Volume framework, which decouples storage
Expand All @@ -19,3 +19,7 @@ Key characteristics of Persistent Volumes include:
- **Access Modes:** PVs support multiple access modes, such as ReadWriteOnce (RWO), ReadOnlyMany (ROX), and ReadWriteMany (RWX), defining how storage can be accessed by Pods.
- **Reclaim Policies:** When a PV is no longer needed, it can be retained, recycled, or deleted based on its configured reclaim policy.
- **Storage Classes:** Kubernetes allows administrators to define different types of storage using StorageClasses, enabling automated provisioning of PVs based on workload requirements.

In simplyblock, each PV is connected to the storage cluster with NVMe-oF (TCP, RoCEv2) through multiple paths to
multiple storage nodes, with the primary path being a local loopback when possible. Each PV is implemented as a
namespace in an NVMe-oF subsystem on the storage nodes.