The problem
Kubernetes doesn't provide data persistence out of the box, which means when a pod is re-created, the data (of a database application for example) is lost. 🙉
So, you need to create and configure the actual physical storage and manage it by yourself.
How to do it 👩🏻💻
Once configured, you can use that physical storage using Kubernetes storage components.
In this video I show you 3 different Kubernetes volume components, that you need to use to connect the actual physical storage to your pod, so that the application inside the container can access it.
3 Volume Components
- The 1st component "Persistent Volume" is a cluster resource, like CPU or RAM, which is created and provisioned by administrators.
- The 2nd component "Persistent Volume Claim" on the other hand is a user's or pod's request for a persistent volume.
- With the 3rd component "Storage Class" you can dynamically provision Persistent Volume component and so automate the storage provisioning process.
ConfigMap and Secret as Volume Types
ConfigMap and Secret components can be used to:
- create individual key-value pairs, like db credentials or db url
- but also create configuration files, that can be mounted into the pod as volumes
You can find the full video here:
Kubernetes 101 ► Compact and easy-to-read ebook bundle 🚀
It's a handy way to quickly look something up or refresh your knowledge at work and use it as your cheatsheet 😎
I'm happy to connect with you on 🙂
Top comments (4)
Hello Nana,
I'm a newbie to K8s and I'm @ "Tutorial 18" of "Kubectl basic commands" on your youtube playlist.
Just wanted your suggestion and advice before I subscribe to a particular platform. What platform do you use for your demonstrations? On-Prem/Cloud? Azure/AWS/Google? I would preferably use the same platform that you are using nevertheless.
I'm interested in learning K8s since I have to work on SQLServer 2019 BDC on Azure and your tutorials are amazing. They are well thought out, well planned and well animated :).
Thanks,
grajee
Persistent volumes and deployments don't really go well together in my opinion. Why not just stick to statefulsets?
Yes, that's exactly right. You usually deploy DB applications with StatefulSet components and use volumes there. However the exceptions can be for example if you are just using a configuration file or a secret file for your application. Then you have a deployment with configMap or secret volumes. Or you can also have just 1 pod DB, with no replicas. In that case I would use deployment and not StatefulSet, because you need statefulSet if you need more than 1 pod replica of the DB.
Interesting. I use statefulsets even if there's a single replica 🤣. But using a deployment makes sense.
As for configmaps and secrets, Never had to deal with volumes directly. I didn't know you can store these on volumes. I was under the impression kubernetes stores them in etcd or something. We just need to mount them as volumes or env variables