Persistent Volume & Claim
A Persistent Volume (PV) is the actual storage resource, while a Persistent Volume Claim (PVC) is a request for storage by a Pod.
Persistent Volume
A Persistent Volume (PV) in Kubernetes is a storage resource that exists independently of Pods, allowing data to persist even if a Pod is deleted or rescheduled.
One of the use case that need a persistent volume is when we want to deploy a database. We want our data to be persist even when pods that run postgres server died or upgraded.
Let's create new file postgres-pv.yaml
. In this file we will put our persistent volume definition to be used for our database.
accessModes
defines how the volume can be accessed:ReadWriteOnce: Can be mounted as read-write by a single node.
ReadOnlyMany: Can be mounted as read-only by multiple nodes.
ReadWriteMany: Can be mounted as read-write by multiple nodes.
persistentVolumeReclaimPolicy
: determines what happens when the PVC is deleted:Retain: Keeps the data even if PVC is deleted.
Delete: Deletes the PV and its data.
Recycle: Performs a basic wipe of the PV (
rm -rf /thevolume/*
).
Apply and Validate
Lets apply our persistent volume definition and validate it using get pv
or describe pv
.
Persistent Volume Claim
A PersistentVolumeClaim (PVC) is a request for storage by a user. It is similar to a Pod. Pods consume node resources and PVCs consume PV resources. Pods can request specific levels of resources (CPU and Memory). Claims can request specific size and access modes.
Create new file postgres-pvc.yaml
and put our PVC definition there.
After we create the PV, the Kubernetes looks for a PV that satisfies the claim's requirements. The PV and PVC must have the followings to bind:
The same access mode (
ReadWriteOnce
).The same storage class (
manual
).The PVC requested storage size must be less or equal with PV. If not the PVC status will stuck in pending until the PV storage increased.
Apply and Validate
Lets apply and validate using get pvc
or describe pvc
command.
As we can se from get pvc
output above that our PVC status is successfully bound.
Postgres Deployment
Next step is to create a deployment spec definition for our postgres server that use the previously defined PVC. Create new file postgres-deployment.yaml
and put our postgres server definition there.
In this definition we expose our POSTGRES_USER
and POSTGRES_PASSWORD
in plain text. This is no recommended and please don't do this in production. We will learn how to utilize kubernetes secret for this later.
Apply and Validate
Postgres Service
After creating deployment we need to create service to expose it so it will be accessible for our apps. Create new file postgres-service.yaml
and put postgres service definition there.
This will expose the postgres service on port 5432
.
Apply and Validate
Testing Data Persistence
To access our recently deployed postgres database and do some testing we can port forward it.
Connect to postgres server using psql
.
Create a new database mydb
or whatever name you want, connect into it, and create a simple table message
.
Insert a row into the table and select it.
Let's restart our pods using kubectl rollout restart deployment postgres
. After the new pods running our port forward will stop so we need to initiate port forward again. Then connect using psql
and select the table. The existing data should still there even after the old pods removed and new pods created.
References
Last updated