What This Pattern Does:

--- ### ✅ **Case 1: Dynamic PVC Binding (Most Common)** **Label/Title:** 📦 Dynamic Volume Provisioning **Description:** The Deployment references a PVC that dynamically provisions a PersistentVolume using a StorageClass. This is the standard and most portable way to request persistent storage in Kubernetes. **Key Notes:** * No need to pre-create a PV. * PVC requests storage using a `storageClassName`. * Backed by cloud or CSI volumes (e.g., EBS, Ceph, GCE PD). --- ### ✅ **Case 2: Static Binding (Manually Pre-bound PV)** **Label/Title:** 📦 Statically Pre-bound Volume **Description:** A PersistentVolume is manually created with a `claimRef` that points to a specific PVC. This PVC is then used by a Deployment. This setup is used when the underlying storage is already provisioned, such as an NFS export or disk device. **Key Notes:** * The `PersistentVolume` and `PersistentVolumeClaim` must match in size, access mode, etc. * Binding is static and happens only if names and selectors match. * Useful in clusters with manual or legacy provisioning workflows. --- ### ✅ **Case 3: Shared Volume (PVC Used by Multiple Pods)** **Label/Title:** 📂 Shared Volume Claim **Description:** Multiple Deployments reference the same PVC, allowing them to share data. This setup is only valid when the backing PersistentVolume supports `ReadWriteMany` or `ReadOnlyMany`. **Key Notes:** * PVC must have `accessModes: [ReadWriteMany]`. * PV type must support multiple mounts (e.g., NFS, CephFS). * Suitable for logs, shared configs, or caches. --- ### 📘 General Relationships **Pod/Deployment → PVC:** Uses the PVC as a volume via `volumeMounts` and `volumes.persistentVolumeClaim.claimName`. **PVC → PV:** PVC gets bound to a matching PV either dynamically (via `StorageClass`) or statically (via `claimRef`). **PV → Storage Backend:** PV is the abstraction over physical or virtual storage (disk, cloud volume, NFS, etc). ---

Caveats and Consideration:

---

Compatibility:



Recent Discussions with "meshery" Tag