The PostgreSQL container used in the StatefulSet is sourced from CrunchyData. CrunchyData provides cloud agnostic PostgreSQL container technology that is designed for production workloads with cloud native High Availability, Disaster Recovery, and monitoring. PostgreSQL is deployed usually as a
statefulset on Kubernetes and requires persistent storage for each instance of PostgreSQL StorageManager instance. OpenEBS provides persistent volumes on the fly when StorageManagers are scaled up.
Advantages of using OpenEBS for PostgreSQL database:
- No need to manage the local disks, they are managed by OpenEBS
- Large size PVs can be provisioned by OpenEBS and PostgreSQL
- Start with small storage and add disks as needed on the fly. Sometimes PostgreSQL instances are scaled up because of capacity on the nodes. With OpenEBS persistent volumes, capacity can be thin provisioned and disks can be added to OpenEBS on the fly without disruption of service
- PostgreSQL sometimes need highly available storage, in such cases OpenEBS volumes can be configured with 3 replicas.
- If required, take backup of the PostgreSQL data periodically and back them up to S3 or any object storage so that restoration of the same data is possible to the same or any other Kubernetes cluster
Note: PostgreSQL can be deployed both as
deployment or as
statefulset. When PostgreSQL deployed as
statefulset, you don't need to replicate the data again at OpenEBS level. When PostgreSQL is deployed as
deployment, consider 3 OpenEBS replicas, choose the StorageClass accordingly.
As shown above, OpenEBS volumes need to be configured with single replica. This configuration work fine when the nodes (hence the cStor pool) is deployed across Kubernetes zones.
If OpenEBS is not installed in your K8s cluster, this can done from here. If OpenEBS is already installed, go to the next step.
Connect to MayaOnline (Optional) : Connecting the Kubernetes cluster to MayaOnline provides good visibility of storage resources. MayaOnline has various support options for enterprise customers.
Configure cStor Pool
If cStor Pool is not configured in your OpenEBS cluster, this can be done from here. As PostgreSQL is a StatefulSet application, it requires single storage replication factor. During cStor Pool creation, make sure that the maxPools parameter is set to >=3. If cStor pool is already configured, go to the next step. Sample YAML named openebs-config.yaml for configuring cStor Pool is provided in the Configuration details below.
Create Storage Class
You must configure a StorageClass to provision cStor volume on cStor pool. In this solution we are using a StorageClass to consume the cStor Pool which is created using external disks attached on the Nodes. The storage pool is created using the steps provided in the Configure StoragePool section. Since PostgreSQL is a StatefulSet application, it requires only one replication at the storage level. So cStor volume
replicaCountis 1. Sample YAML named openebs-sc-disk.yamlto consume cStor pool with cStorVolume Replica count as 1 is provided in the configuration details below.
Launch and test PostgreSQL
Install PostgreSQL on OpenEBS volume using the following command.
helm install --name my-release --storage-class=openebs-cstor-disk replication.slaveReplicas=2 stable/postgresql
A live deployment of PostgreSQL using OpenEBS volumes can be seen at the website www.openebs.ci
Deployment YAML spec files for PostgreSQL and OpenEBS resources are found here
Post deployment Operations
Monitor OpenEBS Volume size
It is not seamless to increase the cStor volume size (refer to the roadmap item). Hence, it is recommended that sufficient size is allocated during the initial configuration. However, an alert can be setup for volume size threshold using MayaOnline.
Monitor cStor Pool size
As in most cases, cStor pool may not be dedicated to just PostgreSQL database alone. It is recommended to watch the pool capacity and add more disks to the pool before it hits 80% threshold. See cStorPool metrics
#Use the following YAMLs to create a cStor Storage Pool. # and associated storage class. apiVersion: openebs.io/v1alpha1 kind: StoragePoolClaim metadata: name: cstor-disk spec: name: cstor-disk type: disk poolSpec: poolType: striped # NOTE - Appropriate disks need to be fetched using `kubectl get disks` # # `Disk` is a custom resource supported by OpenEBS with `node-disk-manager` # as the disk operator # Replace the following with actual disk CRs from your cluster `kubectl get disks` # Uncomment the below lines after updating the actual disk names. disks: diskList: # Replace the following with actual disk CRs from your cluster from `kubectl get disks` # - disk-184d99015253054c48c4aa3f17d137b1 # - disk-2f6bced7ba9b2be230ca5138fd0b07f1 # - disk-806d3e77dd2e38f188fdaf9c46020bdc # - disk-8b6fb58d0c4e0ff3ed74a5183556424d # - disk-bad1863742ce905e67978d082a721d61 # - disk-d172a48ad8b0fb536b9984609b7ee653
apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: openebs-cstor-disk annotations: openebs.io/cas-type: cstor cas.openebs.io/config: | - name: StoragePoolClaim value: "cstor-disk" - name: ReplicaCount value: "1" provisioner: openebs.io/provisioner-iscsi reclaimPolicy: Delete