Kubernetes Persistent Volumes
In this blog post, I’ll be walking through a simple example of how to create a persistent volume in Kubernetes. There are several volume types in Kubernetes, but to get started I’ll be using the local volume type.
A local volume represents a mounted local storage device such as a disk, partition or directory. I’ll be using a single node Kubernetes cluster running within Ubuntu server and using a docker image of a .Net Core WebAPI application that uses the
persistent volume to write logs to. Below are them main steps needed to achive this goal, it assumed that you have knowledge of creating the .Net Core appliation and the Kubernetes single node cluster.
Create a Persistent Volume
You begin by creating a hostPath Persistent Volume. Kubernetes supports hostPath for development and testing on a single-node cluster. A hostPath Persistent Volume uses a file or directory on the Node to emulate network-attached storage.
In a production cluster, you would not use hostPath. Instead a cluster administrator would provision a network resource like a Google Compute Engine persistent disk, an NFS share, or an Amazon Elastic Block Store volume. Cluster administrators can also use StorageClasses to set up dynamic provisioning.
The configuration file specifies that the volume is at /mnt/data on the cluster’s Node. The configuration also specifies a size of 10 gibibytes and an access mode of ReadWriteOnce, which means the volume can be mounted as read-write by a single Node.
It defines the Storage Class name manual for the Persistent Volume, which will be used to bind Persistent Volume Claim requests to this Persistent Volume.
Create the PersistentVolume: Copy the code into a pv-volume.yaml file and run:
kubectl apply -f pv-volume.yaml
View information about the Persistent Volume:
kubectl get pv my-pv-volume
Configuration for the Persistent Volume:
apiVersion: v1
kind: PersistentVolume
metadata:
name: my-pv-volume
labels:
type: local
spec:
storageClassName: manual
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
hostPath:
path: "/mnt/data"
Create a Persistent Volume Claim
The next step is to create a PersistentVolumeClaim. Pods use Persistent Volume Claims to request physical storage. In this exercise, you create a Persistent Volume Claim that requests a volume of at least three gibibytes that can provide read-write access for at least one Node.
The configuration file specifies that the volume is at /mnt/data on the cluster’s Node. The configuration also specifies a size of 10 gibibytes and an access mode of ReadWriteOnce, which means the volume can be mounted as read-write by a single Node.
It defines the StorageClass name manual for the Persistent Volume, which will be used to bind Persistent Volume Claim requests to this Persistent Volume.
Create the Persistent Volume Claim:Copy the code into a pv-volume-claim.yaml file and run:
kubectl apply -f a pv-volume-claim.yaml
After you create the Persistent Volume Claim, the Kubernetes control plane looks for a Persistent Volume that satisfies the claim’s requirements.
If the control plane finds a suitable Persistent Volume with the same StorageClass, it binds the claim to the volume.
Look again at the Persistent Volume:
kubectl get pv my-pv-volume
Now the output shows a STATUS of
Bound.
Look at the Persistent Volume Claim:
kubectl get pvc my-pv-claim
Configuration for the Persistent Volume Claim:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: my-pv-claim
spec:
storageClassName: manual
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 3Gi
Create a Pod
The next step is to create a Pod that uses your PersistentVolumeClaim as a volume.
Notice that the Pod’s configuration file specifies a PersistentVolumeClaim, but it does not specify a PersistentVolume. From the Pod’s point of view, the claim is a volume.
Create the Pod:Copy the code into a pv-pod.yaml file and run:
kubectl apply -f pv-pod.yaml
Verify that the container in the Pod is running;
kubectl get pod my-pv-pod
Configuration for the Pod:
apiVersion: v1
kind: Pod
metadata:
name: my-pv-pod
labels:
run: my-app
spec:
volumes:
- name: my-pv-storage
persistentVolumeClaim:
claimName: my-pv-claim
containers:
- name: my-app
image: 'docker.io/mydockerwebapp:v1'
ports:
- containerPort: 80
name: "http-server"
volumeMounts:
- mountPath: "/my/logs"
name: pv-storage
Using Persistent Volume Claims with Deployments
At this point, a persistent volume and a persistent volume claim have been created. The persistent volume claim has been bound to the
persistent volume by matching the access modes and capacity. You can confirm this by running the kubectl get pv command and looking at
the STATUS column of the mysql-pv-volume. The claim is now ready to be used by a pod or deployment spec. To demonstrate this I’ll use a
mysql deployment that creates a service for mysql and runs a single mysql container. Pay close attention to the volumes and volumeMounts sections.
The volumeMounts section of the container spec specifies the name of the volume and the mountPath inside the container.
The volumes section creates uses the persistent volume claim as it’s mapping to an actual volume that can be used by the container.
Create the Persistent Volume Service & Deployment:
Copy the code into a pv-deployment.yaml file and run:
kubectl apply -f pv-deployment.yaml
Verify that the container in the Pod is running;
kubectl get pod my-pv-pod
You can now test your app using http://localhost:31718/api/mycontroller
Configuration for the Deployment:
apiVersion: v1
kind: Service
metadata:
name: dockerwebapi-srv
namespace: default
labels:
run: my-app
spec:
ports:
- protocol: TCP
port: 80
nodePort: 31718
selector:
run: my-app
clusterIP: 10.152.183.80
type: NodePort
sessionAffinity: None
externalTrafficPolicy: Cluster
- - -
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
namespace: default
labels:
run: my-app
spec:
replicas: 1
selector:
matchLabels:
run: my-app
template:
metadata:
creationTimestamp: null
labels:
run: my-app
spec:
containers:
- name: my-app
image: 'docker.io/mydockerwebapp:v1'
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
Understanding Persistent Volume Reclaim Policies
here is a setting you can defined called persistentVolumeReclaimPolicy in the PersistentVolume manifest. This setting determines what happens to the data in a volume when its
released from a claim. Meaning the claim was deleted and the volume is no longer bound to any claim. There are three options for persistentVolumeReclaimPolicy; Retain, Delete,
and Recycle. Retain preserves the data and the volume. When a claim is removed the volume simply remains as it was and can be attached to new claims that fit the requirements
of the claim. Note, that by using retain the new claims would have access to the old data stored on the volume. Delete will delete the volume when a claim is deleted.
It does not however delete the data inside the volume, just the volume. So, if you re-create a volume at the same path it will load up the old data into the volume.
Recycle is being deprecated in favor of dynamic volumes. But, it’s worth knowing that it can be used to preserve the volume but to delete the data in the volume when a claim is deleted.
Reclaim Policies: Retain, Delete, Recycle (deprecated in favor of dynamic volumes)
Configuration showing reclaim policies:
apiVersion: v1
kind: PersistentVolume
metadata:
name: my-pv-volume
labels:
type: local
spec:
storageClassName: manual
capacity:
storage: 1Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Delete
hostPath:
path: "/mnt/data"