As the Service resource is created, we can create a StatefulSet resource that uses the created PersistentVolume and Service resources. The StatefulSet resource manifest, nginx-manual-statefulset.yaml, looks like this:

apiVersion: apps/v1
kind: StatefulSet
metadata:
name: nginx-manual
spec:
selector:
matchLabels:
app: nginx-manual
serviceName: “nginx-manual”
replicas: 1
template:
metadata:
labels:
app: nginx-manual
spec:
containers:
name: nginx
image: nginx volumeMounts: – name: html
mountPath: /usr/share/nginx/html

volumeClaimTemplates:
metadata:
name: html
spec:
accessModes: [ “ReadWriteOnce” ]
resources:
requests:
storage: 40Gi
selector:
matchLabels:
usage: nginx-manual-disk

The manifest contains various sections. While most are similar to the Deployment resource manifest, this requires a volume definition and a separate volumeClaimTemplates section. The volumeClaimTemplates section consists of the accessModes, resources, and selector sections. The selector section defines the matchLabels attribute, which helps to select a particular PersistentVolume resource. In this case, it selects the PersistentVolume resource we defined previously. It also contains the serviceName attribute that defines the headless Service resource it will use.

Now, let’s go ahead and apply the manifest using the following command:

$ kubectl apply -f nginx-manual-statefulset.yaml

Now, let’s inspect a few elements to see where we are. The StatefulSet resource creates a PersistentVolumeClaim resource to claim the PersistentVolume resource we created before.

Get the PersistentVolumeClaim resource using the following command:

$ kubectl get pvc
NAME
STATUS VOLUME
CAPACITY
ACCESS MODES
html-nginx-manual-0
Bound
nginx-manual-pv
50G
RWO

As we can see, the StatefulSet resource has created a PersistentVolumeClaim resource called html-nginx-manual-0 that is bound to the nginx-manual-pv PersistentVolume resource. Therefore, manual provisioning has worked correctly.

If we query the PersistentVolume resource using the following command, we will see that the status is now showing as Bound:

$ kubectl get pv
NAME
CAPACITY
ACCESS MODES
RECLAIM POLICY
STATUS
nginx-manual-pv
50G
RWO
Retain
Bound

Now, let’s have a look at the pods using the following command:

$ kubectl get pod
NAME
READY     STATUS
RESTARTS   AGE
nginx-manual-0   1/1
Running     0
14s

As we see, the StatefulSet resource has created a pod and appended it with a serial number instead of a random hash. It wants to maintain ordering between the pods and mount the same volumes to the pods they previously mounted.

Now, let’s open a shell into the pod and create a file within the /usr/share/nginx/html directory using the following commands:

$ kubectl exec -it nginx-manual-0 — /bin/bash root@nginx-manual-0:/# cd /usr/share/nginx/html/ root@nginx-manual-0:/usr/share/nginx/html# echo ‘Hello, world’ > index.html root@nginx-manual-0:/usr/share/nginx/html# exit

Great! So, let’s go ahead and delete the pod and see whether we can get the file in the same location again using the following commands:

$ kubectl delete pod nginx-manual-0
$ kubectl get pod
NAME	READY	STATUS	RESTARTS	AGE
nginx-manual-0	1/1	Running	0	3s
$ kubectl exec -it nginx-manual-0 — /bin/bash
root@nginx-manual-0:/# cd /usr/share/nginx/html/ && cat				index.html
Hello, world
root@nginx-manual-0:/usr/share/nginx/html# exit

And, as we can see, the file still exists, even after we deleted the pod.

Static provisioning isn’t one of the best ways of doing things, as you must manually keep track and provision volumes. That involves a lot of manual activities and may be error-prone. Some organizations that want to keep a line between Dev and Ops can use this technique. Kubernetes allows this provision. However, for more DevOps-friendly organizations, dynamic provisioning is a better way of doing it.