Dynamic provisioning is when Kubernetes provides storage resources for you by interacting with the cloud provider. When we provisioned the disk manually, we interacted with the cloud APIs using the gcloud command line. What if your organization decides to move to some other cloud provider later? That would break many existing scripts, and you would have to rewrite the storage provisioning steps. Kubernetes is inherently portable and platform-independent. You can provision resources in the same way on any cloud platform.
But then, different cloud providers have different storage offerings. How would Kubernetes know what kind of storage it needs to provision? Well, Kubernetes uses StorageClass resources for that. StorageClass resources are Kubernetes resources that define the type of storage they need to provide when someone uses it.
The following diagram illustrates dynamic provisioning:
Figure 6.10 – Dynamic provisioning
Let’s see an example storage class manifest, fast-storage-class.yaml, that provisions an SSD within GCP:
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: fast
provisioner: kubernetes.io/gce-pd
parameters:
type: pd-ssd
The StorageClass resource contains a provisioner and any parameters the provisioner requires. You may have noticed that I have kept the name fast instead of gce-ssd or similar. That is because we want to keep the names as generic as possible.
Tip
Keep generic storage class names such as fast, standard, block, and shared, and avoid names specific to the cloud platform. Because storage class names are used in Persistent Volume claims, if you migrate to another cloud provider, you may end up changing a lot of manifests just to avoid confusion.
Let’s go ahead and apply the manifest using the following command:
$ kubectl apply -f fast-storage-class.yaml
As the StorageClass resource is created, let’s use it to provision an nginx StatefulSet resource dynamically.
We need to create a Service resource manifest, nginx-dynamic-service.yaml, first:
apiVersion: v1
kind: Service
metadata:
name: nginx-dynamic
labels:
app: nginx-dynamic
spec:
ports:
port: 80
name: web
clusterIP: None
selector:
app: nginx-dynamic
The manifest is very similar to the manual Service resource. Let’s go ahead and apply it using the following command:
$ kubectl apply -f nginx-dynamic-service.yaml
Now, let’s look at the StatefulSet resource manifest, nginx-dynamic-statefulset.yaml:
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: nginx-dynamic
spec:
…
serviceName: “nginx-dynamic”
template:
spec:
containers:
name: nginx
image: nginx volumeMounts:
name: html
mountPath: /usr/share/nginx/html
…
volumeClaimTemplates:
metadata:
name: html
spec:
storageClassName: “fast”
accessModes: [ “ReadWriteOnce” ]
resources:
requests:
storage: 40Gi
The manifest is similar to the manual one, but this one contains the storageClassName attribute in the volumeClaimTemplates section and lacks the selector section, as we are dynamically provisioning the storage. Use the following command to apply the manifest:
$ kubectl apply -f nginx-dynamic-statefulset.yaml
As the StatefulSet resource is created, let’s go ahead and check the PersistentVolumeClaim and PersistentVolume resources using the following commands:
| $ kubectl get pvc | ||||||
| NAME | STATUS | VOLUME | CAPACITY | ACCESS MODES STORAGECLASS | ||
| html-nginx-dynamic-0 | Bound | pvc-6b78 | 40Gi | RWO | fast | |
| $ kubectl get pv | ||||||
| NAME | CAPACITY | ACCESS MODES RECLAIM POLICY | STATUS | CLAIM | ||
| pvc-6b78 | 40Gi | RWO | Delete | Bound | default/html-nginx-dynamic-0 | |
And we can see that the claim is bound to a Persistent Volume that is dynamically provisioned. Now, let’s proceed and run the following command to do similar tests with this StatefulSet resource.
Let’s create a file in the nginx-dynamic-0 pod using the following command:
$ kubectl exec -it nginx-dynamic-0 — bash
root@nginx-dynamic-0:/# cd /usr/share/nginx/html/ root@nginx-dynamic-0:/usr/share/nginx/html# echo ‘Hello, dynamic world’ > index.html root@nginx-dynamic-0:/usr/share/nginx/html# exit
Now, delete the pod and open a shell session again to check whether the file exists by using the following commands:
| $ | kubectl delete pod nginx-dynamic-0 | ||||
| $ | kubectl get pod | nginx-dynamic-0 | |||
| NAME | READY | STATUS | RESTARTS | AGE | |
| nginx-dynamic-0 | 1/1 | Running | 0 | 13s | |
$ kubectl exec -it nginx-dynamic-0 — bash
root@nginx-dynamic-0:/# cd /usr/share/nginx/html/
root@nginx-dynamic-0:/usr/share/nginx/html# cat index.html
Hello, dynamic world
root@nginx-dynamic-0:/usr/share/nginx/html# exit
And as we can see, the file exists in the volume, even if the pod was deleted. That is dynamic provisioning in action for you!
You will have observed that we have used the kubectl command multiple times throughout this chapter. When you perform activities throughout the day, using shortcuts and best practices wherever you can makes sense. Let’s look at some best practices while using kubectl.
