Skip to content

Latest commit

 

History

History
40 lines (29 loc) · 4.54 KB

persistent-storage.md

File metadata and controls

40 lines (29 loc) · 4.54 KB
layout
title description tableOfContents outline pagination
visible
true
visible
visible
true
visible
true
visible
true

Persistent Storage

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.

Types of persistent storage

Storage typeDefinitionDeletion behavior
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.

Types of PVs

Types of PVsPurposeType
PostgresStores database data for the application.StatefulSet
OpenSearchStores indexing data, logs, and search-related data.StatefulSet
MinioStores 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
OdooStores 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

Persistent volume reclaim policies: retain vs. delete

Reclaim policyBehaviorUse case
RetainWhen 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.
DeleteWhen 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.

Checking which PV belongs to which pod

In Rancher, follow the below steps to check which PV is associated with a particular pod.

  1. Launch Rancher, then select the cluster where your deployment resides.
  2. Select the namespace where your pods are deployed.
  3. Navigate to Workloads > Pods to identify the pod. Each pod that uses persistent storage will have a PVC associated with it.
  4. 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.
  5. Navigate to Storage > PersistentVolumeClaims. Find the PVC name from the previous step. When you click on the PVC, the associated PV will appear.
  6. Click on the PV to view additional information on its capacity, reclaim policy, and status.