Kubernetes – Volumes

Kubernetes has different types of volumes, and the type determines how and what the volume contains.

Volumes were present in Docker, but they were very much limited to pods. The volume would disappear as soon as the pod died.

Meanwhile, Kubernetes doesn’t limit volumes to containers. A key advantage of Kubernetes volume is that it supports different kinds of storage simultaneously. It supports any or all containers inside the pod.

Types of Kubernetes Volume

Here are some of the most popular Kubernetes volumes

• emptyDir − The emptyDir volume is created when a pod is assigned to a node for the first time. It stays active as long as the pod is running on that node. It’s empty at first, but containers can read and write files from it. Data in the emptyDir gets erased once the pod’s removed from the node.
• hostPath − Your pod mounts a file or directory from the host node’s filesystem.
• gcePersistentDisk − gcePersistentDisk mounts a Google Compute Engine (GCE) Persistent Disk into your Pod. Data is intact when the Pod is removed.
• awsElasticBlockStore − Like gcePersistentDisk, awsElasticBlockStore mounts an Amazon Web Services Elastic Block Store into your Pod.
• nfs − Data in an NFS volume isn’t erased when the pod is removed. It is only unmounted when the pod is removed.
• iscsi − With an iSCSI volume, you can mount an existing iSCSI (SCSI over IP) volume.
• flocker − This is an open-source clustered container data volume manager. Flocker datasets can be mounted into pods with flocker volumes. If the dataset doesn’t exist in Flocker, you first have to create it.
• glusterfs − A glusterfs volume allows you to mount a glusterfs volume into your pod.
• rbd − With an RBD volume, a Rados Block Device volume can be mounted into your pod. Data remains preserved even after the pod is removed from the node.
• cephfs − Data stays intact after removing the pod if you mount an existing CephFS volume.
• gitRepo − The gitRepo volume mounts an empty directory and clones a git repository into it.
• secret − Pods use secret volumes to pass sensitive information, like passwords.
• persistentVolumeClaim − A persistentVolumeClaim volume mounts a persistentVolume into a pod. Users can “claim” persistent volumes (like a GCE PersistentDisk) without knowing the details of the cloud.
• downwardAPI − A downwardAPI volume mounts a directory and writes plain text files with the API data.
• azureDiskVolume − A Microsoft Azure Data Disk is mounted into a Pod using an AzureDiskVolume.

Persistent Volume and Persistent Volume Claim

Persistent Volume (PV) − A piece of network storage that has been provisioned by the cluster administrator. It is independent of any individual pod using it.

Persistent Volume Claim (PVC) − Kubernetes uses PVC storage for pods. Users don’t need to know about the provisioning. Pods and claims must be in the same namespace.

Creating Persistent Volume

kind: PersistentVolume ---------> 1
apiVersion: v1
metadata:
   name: pv1 ------------------> 2
   labels:
      type: local
spec:
   capacity: -----------------------> 3
      storage: 10Gi ----------------------> 4
   accessModes:
      - ReadWriteOnce -------------------> 5
      hostPath:
         path: "/tmp/data01" --------------------------> 6

The above code defines −

• kind: PersistentVolume – PersistentVolume is the kind that tells Kubernetes that the yaml file used is to create a persistent volume.
• name: pv1 – The name of the persistent volume we are creating.
• capacity – This spec defines the power of our PV.
• storage: 10Gi – Tells the underlying infrastructure we’re claiming 10Gi.
• ReadWriteOnce – Tells us what access rights the volume has.
• path: “/tmp/data01” – This tells the machine we’re trying to create a volume under this path.

Creating PV

$ kubectl create –f local.yaml

persistentvolume “pv1” created

Checking PV

$ kubectl get pv

NAME        CAPACITY      ACCESSMODES       STATUS       CLAIM      REASON     AGE

pv1               10Gi            RWO                         Available                            14s

Describing PV

$ kubectl describe pv pv1

Creating Persistent Volume Claim

kind: PersistentVolumeClaim --------------> 1
apiVersion: v1
metadata:
   name: myclaim-1 --------------------> 2
spec:
   accessModes:
      - ReadWriteOnce ------------------------> 3
   resources:
      requests:
         storage: 3Gi ---------------------> 4

The above code defines −

• kind: PersistentVolumeClaim – Tells the underlying infrastructure how much space we want.
• name: myclaim-1 – The name of the claim.
• ReadWriteOnce – Specifies the mode of the claim.
• storage: 3Gi – This tells Kubernetes how much space we are trying to claim.

Creating PVC

$ kubectl create –f myclaim-1
persistentvolumeclaim "myclaim-1" created

Getting Details About PVC

$ kubectl get pvc
NAME        STATUS   VOLUME   CAPACITY   ACCESSMODES   AGE
myclaim-1   Bound    pv1     10Gi         RWO       7s

Describe PVC

$ kubectl describe pv pv0001

Using PV and PVC with POD

kind: Pod
apiVersion: v1
metadata:
   name: mypod
   labels:
      name: frontendhttp
spec:
   containers:
   - name: myfrontend
      image: nginx
      ports:
      - containerPort: 80
         name: "http-server"
      volumeMounts: ----------------------------> 1
      - mountPath: "/usr/share/tomcat/html"
         name: mypd
   volumes: -----------------------> 2
      - name: mypd
         persistentVolumeClaim: ------------------------->3
         claimName: myclaim-1

The above code defines −

• volumeMounts: – The path in the container where the mounting will take place.
• Volume:  This defines the volume definition we’re going to use.
• persistentVolumeClaim:  This defines the volume name that will be used in the defined pod.