Persistent volume mount in Elastic Kubernetes service
Persistent storage is necessary for storing application data. We have seen how we can mount a local volume in docker to persist any data. If you haven’t read that, you can just go through my earlier article.
When using an orchestrator, we will need to do few more things than just to mount a persistent store to a Pod(container). In this article, we will explore the AWS Elastic Kubernetes service to create a cluster and then mount a persistent Elastic blob store so that any change that we do in our app shall persist.
To get started, you will need to set aws-cli and Terraform on your machine. In EKS, it’s a bit tedious to create a cluster using aws-cli commands manually and therefore we will use terraform to get this prerequisite done.
You can follow the steps on this link from Hashicorp, which guides you on how to create and configure an EKS cluster. Once your cluster is up and running, we will execute few kubectl commands to mount a persistent Elastic Blob Store.
The usual process to claim a persistent store is to first create a volume in AWS followed by a storage-class then create a persistent volume(PV) and finally a persistent volume claim(PVC) that will be used by a Pod. Alternatively, we can just skip the creation of persistent volume and go ahead and create a persistent volume claim kind object which will automatically create a corresponding PV for you
Note that an EBS Volume can only be used by a single Pod at the same time. Thus, the access mode of your PVC can only be
So, let’s first create a volume through aws-cli or console
aws ec2 create-volume --region <aws-region> --availability-zone <aws-az> --size <size-in-Gb> --volume-type <type>
Then let’s go ahead and create a storage class if you don’t have a default one in your cluster.
Now let’s create a persitent volume claim(PVC)
We can create these objects simply by using kubectl create command
kubectl create -f <file-name>.yaml
Now let’s create a workload or a pod that is going to utilize this volume and a load-balancer service to expose our running container.
- name: myfrontend
- mountPath: "/usr/share/nginx/html"
- name: mypd
- port: 80
We can just validate once all objects have been created using kubectl get command.
If volume is not in bound state, we can check the event logs to get an idea of any problem.
kubectl get events
We can also verify that the volume state has now changed to ‘in-use’ in aws console.
Now, just to make sure that we are able to persist any data, we will go ahead and create a index.html file under the mounted path of the pod and validate that our site is alive.
Now, that we have nginx homepage that we want to persist, we will kill this pod and launch a new pod mounting the same volume path where we have our data of interest and validate that it exists and can be utilized.
So, let’s delete the old pod named nginx-pod and create a new pod named new-nginx-pod to validate.
This is how we can persist any data in our kubernetes cluster. Apart from using EBS, there is Elastic File system service(EFS) for the same purpose with some differences.
I hope you found this article insightful, Thanks for reading! 😃