Volume Management in Kubernetes
Since pods created in k8s are ephemeral, we are able to get the data as long as pods are alive, but if pods are terminated data stored in it completely lost and it cannot get back, for that we need to mount a volume to write the data into that of a pod. To do that we have different ways. Let’s look at those things.
Host path: with this type, we can configure a directory on the host itself (node) and specify a path /data. Once the volume is created, we mount the volume to a directory inside the container to access it. Even when the pod deleted, the data processed will be still on the host and it can get back once the pod is up. Sample YAML for host path volumes is as follows:
- name: redis
- name: redis-storage
- name: redis-storage
this type is fine for a single node, but it is not good for multi node clusters. This is because the pods will use /data directory in all the nodes and expects all of them to be the same and have the same data. Since they are on different nodes, they are not same, unless you configured external replicated cluster storage solution. Kubernetes supports several types of storage solutions such as NFS, FLOCKER, EBS, Azure Disk, etc. for example to configure AZURE DISK as the storage option for the volume we will do as follows
On Azure VM, create a Pod using the volume spec based on azure.
In the pod, you need to provide the following information:
- disk name: (required) the name of the VHD blob object OR the name of an Azure managed data disk if Kind is Managed.
- disk URI: (required) the URI of the vhd blob object OR the resource of an Azure managed data disk if Kind is Managed.
- kind: (optional) kind of disk. Must be one of Shared (multiple disks per storage account), Dedicated (single blob disk per storage account), or Managed (Azure managed data disk). Default is Shared.
- caching mode: (optional) disk caching mode. Must be one of None, ReadOnly, or ReadWrite. Default is None.
- type: (optional) the filesystem type to mount. Default is ext4.
- readOnly: (optional) whether the filesystem is used as readOnly. Default is false.
- image: kubernetes/pause
- name: azure
- name: azure
kubectl create -f azure.yaml
in the above type, we configured the volumes within the pod definition files, when you have a large environment, where lot pods are running inside it, every time you deploy a pod you have to configure volume for each pod. Instead of that, we will configure a large pool of volume centrally, then the pods will use small pieces out of that pool, that is where persistent volumes can help us, A persistent volume (PV) is a cluster-wide pool of storage volumes configured by an administrator to be used by pods on the cluster, and pods can use the storage using volume claims (PVCs). We can use persistent volumes as below, where I’m not gonna talk about host path with PV and PVC because that is not recommended for production oriented. Here I’m using the Azure file storage class for dynamic provisioning, An Azure disk can only be mounted with Access mode type ReadWriteOnce, which makes it available to one node in AKS. If you need to share a persistent volume across multiple nodes, use Azure Files.
1.Create a file named azure-file-sc.yaml and copy in the following example manifest.
2.create PVC for that storage class
3.mount the claim to pod
- image: httpd
- mountPath: "/mnt/azure"
- name: volume
apply the yamls to configure and claim the volumes