Persistent Storage
Last updated
Last updated
Copyright © 2024 OpenG2P. This work is licensed under Creative Commons Attribution International LicenseCC-BY-4.0 unless otherwise noted.
This document provides information on all the Persistent storages, i.e., PVs (Persistent Volume) and PVCs (Persistent Volume Claim), in OpenG2P deployments. It describes the type of storage, deletion behavior, and how to identify which PV belongs to which pod. It also defines and highlights the specific behavior of the StatefulSets and Deployments.
Storage type | Definition | Deletion behavior |
---|---|---|
Types of PVs | Purpose | Type |
---|---|---|
Reclaim policy | Behavior | Use case |
---|---|---|
In Rancher, follow the below steps to check which PV is associated with a particular pod.
Launch Rancher, then select the cluster where your deployment resides.
Select the namespace where your pods are deployed.
Navigate to Workloads > Pods to identify the pod. Each pod that uses persistent storage will have a PVC associated with it.
Click on the pod and look for the Volumes section under the pod specification. Here, you will find the name of the PVC associated with the pod.
Navigate to Storage > PersistentVolumeClaims. Find the PVC name from the previous step. When you click on the PVC, the associated PV will appear.
Click on the PV to view additional information on its capacity, reclaim policy, and status.
StatefulSet attached storage
StatefulSets are used for applications that require stable network identities and persistent storage. The pods in a StatefulSet have unique identities and their storage is tied to their lifecycle. When a pod in a StatefulSet is deleted, the storage (PV) remains intact unless explicitly deleted.
Examples: Postgres, OpenSearch, and Minio.
By default, the storage attached to a StatefulSet is retained even after the pod is deleted. This is crucial for stateful applications where data persistence is critical.
Deployment attached storage
In stateless applications, deployments are used so that any pod can be replaced by another. The storage associated with a deployment is generally ephemeral unless PVs are explicitly attached.
Examples: Some auxiliary services might use Deployment-based storage, but it is less common for critical data.
If PVs are attached to a deployment, the storage may be deleted when the deployment is deleted, depending on the reclaim policy. Unlike StatefulSets, Deployments do not guarantee data persistence when pods are scaled down or deleted.
Postgres
Stores database data for the application.
StatefulSet
OpenSearch
Stores indexing data, logs, and search-related data.
StatefulSet
Minio
Stores object data, files, and backups.
Deployment
SoftHSM
Stores cryptographic key data used for secure key storage and management.
SoftHSM acts as a software-based Hardware Security Module (HSM) for the application.
Deployment
Kafka
Stores Kafka logs and messages, ensuring durability and persistence of data in the event of a pod restart or failure.
Kafka's stateful nature requires persistent storage to maintain message integrity.
StatefulSet
Odoo
Stores database data, files, and other persistent configurations for the Odoo ERP system and ensures that data is retained across pod during restarting and upgrades.
Deployment
Retain
When a PVC is deleted, the associated PV is not automatically deleted. This is helpful if you want to reattach the PV to another PVC in the future or as a backup.
Critical data that you may want to preserve even after deleting the PVC or StatefulSet.
Delete
When a PVC is deleted, the associated PV is also automatically deleted. This is more suitable for temporary or non-critical data.
Ephemeral or temporary data where automatic cleanup is preferred.