{{announcement.body}}
{{announcement.title}}

Storage with Kubernetes

DZone 's Guide to

Storage with Kubernetes

Every project and application requuires storage, and Kubernetes Volumes provides a number of options for supportion application with various needs.

· Cloud Zone ·
Free Resource

Storage is a common need for applications. They need it to store log files, configuration files, artifacts, media, and more. When applications run in a web server, they use the disk space on the server to store these files. However, when they run in a container, allocating a disk space is not so straightforward. There are several considerations when creating a strategy for container volumes:

  • On-disk files in a container may be ephemeral.
  • The container gets re-spawned, losing any files it has.
  • Files are needed to be shared across containers.
  • Files may be needed beyond the lifespan of pods.

One of the advantages of using Kubernetes for managing containers is that it provides several options to meet different storage needs.

Volumes

Kubernetes Volume is a directory on a disk backed by some media. This Volume is available to all containers running inside a Pod. The Pod specification mentions what kind of volume is to be provisioned and where to mount it. The kind of Volume is specified by choosing one between many Volume Types that Kubernetes provides. Some of these are:

  • AWS EBS
  • Azure Disk
  • Ceph file system
  • configMap
  • emptyDir
  • local
  • nfs
  • persistentVolumeClaim
  • secret

emptyDir

This kind of Volume is created when a Pod is scheduled on a node. This volume is for the lifetime of the pod only. It gets deleted as soon as pod is terminated. All containers within the Pod share this volume. The use case for such a volume can be to use as a temporary space for applications internal work or use as a cache for improving the performance of applications. See the below pod specification:

YAML
 




x
16


1
apiVersion: v1
2
kind: Pod
3
metadata:
4
  name: my-server
5
spec:
6
  containers:
7
  - image: nginx
8
    name: my-server
9
    volumeMounts:
10
    - mountPath: /testcache
11
      name: cache-volume
12
  volumes:
13
  - name: cache-volume
14
    emptyDir:
15
      medium: Memory


AWS EBS, Azure Disk, and GCE Persistent Disk

AWS/AKS/GKE and other cloud providers provide storage to be used by their managed Kubernetes services. Consider the following example where the Pod specification makes use of an Azure Disk: 

YAML
 






In the above specification,

  •  diskName : Name of the VHD blob object
  •  diskURI : URI of the VHD blob

Persistent Volume

The pod specifications we saw so far all mention the type of volume to be used by that pod. This tightly couples the volume kind with pod. However, at times it is better to not explicitly mention the Type of volume rather just provision a variety of storage and the Pods will make use of the storage which suits them best. This is handled through Persistent Volume and Persistent Volume Claim.

A Persistent Volume (PV) represents a storage that been provisioned by you. It is a resource in Kubernetes cluster and its lifetime is beyond those of pods in the cluster.  

A Persistent Volume Claim (PVC) is a specification which requests for a storage to be used by Pod.

Hence, PV is a storage resource and PVC is a request for that resource.

  • First, you provision a PV with details of actual storage.
  • Next, you create a PVC specification which has details of storage request.
  • A Kubernetes control loop tries to bind a PVC with any PV that matches.
  • Kubernetes then mounts the bound volume to the Pod.
  • When a user has no further need of the volume then they can delete the PVC. The PV specification mentions a reclaim policy which tells the cluster what to do when the volume has been released.

A PV specification is as follows: 

YAML
 




x


1
apiVersion: v1
2
kind: PersistentVolume
3
metadata:
4
  name: my-pv
5
spec:
6
  capacity:
7
    storage: 10Gi
8
  volumeMode: Filesystem
9
  accessModes:
10
    - ReadWriteOnce
11
  persistentVolumeReclaimPolicy: Recycle
12
  storageClassName: any-name
13
  nfs:
14
    path: /test
15
    server: 10.0.0.0
16
 
          


  •  capacity : specifies the size of volume.
  •  volumeMode : use filesystem to use a file system or block for a raw block device.
  •  accessMode : this can be  ReadWriteOnce, ReadOnlyMany or ReadWriteMany 
  •  reclaimPolicy : This can be Retain, Recycle, or Delete.

Apply the above PV specification:

Shell
 






 A PVC specification is as follows:

YAML
 






Apply the above PVC specification:

Shell
 






Now we can use this PV is our Pod specification as follows:

YAML
 




xxxxxxxxxx
1
16


1
apiVersion: v1
2
kind: Pod
3
metadata:
4
 name: pod-with-volume
5
spec:
6
 containers:
7
 - image: nginx
8
   name: pod-with-volume
9
   volumeMounts:
10
   - mountPath: /data
11
     name: my-volume
12
 volumes:
13
 - name: my-volume
14
   persistentVolumeClaim:
15
     claimName: my-pvc


Snapshots

For enabling snapshots of a volume kubernetes provides  VolumeSnapshotContent  and  VolumeSnapshot  resources.

A  VolumeSnapshotContent  is the snapshot of the content of a Volume while  VolumeSnapshot  is a request for a snapshot. Just like a PVC is bound to a PV, the  VolumeSnapshot  is bound to a  VolumeSnapshotContent. Here is a sample specification of both:

YAML
 




xxxxxxxxxx
1


 
1
apiVersion: snapshot.storage.k8s.io/v1beta1
2
kind: VolumeSnapshot
3
metadata:
4
  name: my-vol-snapshot
5
spec:
6
  source:
7
        volumeSnapshotContentName: my-snapshot-content



YAML
 




xxxxxxxxxx
1
13


1
apiVersion: snapshot.storage.k8s.io/v1beta1
2
kind: VolumeSnapshotContent
3
metadata:
4
  name: my-snapshot-content
5
spec:
6
  deletionPolicy: Delete
7
  driver: hostpath.csi.k8s.io
8
  source:
9
    snapshotHandle: 8qgh0te3-nleb-63h8-g6ae-734rac76hu01
10
  volumeSnapshotRef:
11
    name: my-vol-snapshot
12
    namespace: default


Dynamic Volumes

So far, we have created volumes manually, but in a managed environment it is highly recommended to have a facility where we can create volumes on-demand. Kubernetes provides Dynamic Volumes which eliminate the need to pre-provision volumes. To enable Dynamic Volumes we have to use a Kubernetes resource known as StorageClass . This object specifies which storage provisioner is to be used and the associated parameters. For example, to use a SSD disk provided by Google Kubernetes Engine, create the following  StorageClass:

YAML
 

Now create a  PersistentVolumeClaim  which uses this  StorageClass

YAML
 




xxxxxxxxxx
1
12


 
1
apiVersion: v1
2
kind: PersistentVolumeClaim
3
metadata:
4
  name: my-pvc
5
spec:
6
  accessModes:
7
    - ReadWriteOnce
8
  storageClassName: my-class
9
  resources:
10
    requests:
11
      storage: 30Gi


This automatically provisions an SSD like a persistent disk.

Summary

  • Kubernetes Volumes offer storage which is persistent and lasts longer than lifetime of a container or even a pod.
  • To decouple volume types with a pod specification use PVC and PV.
  • To dynamically provision volumes use StorageClass.

This post has described all the above features with near real-life Kubernetes samples and they can be readily used in your projects.

Topics:
container storage, dynamic volumes, kubernetes, kubernetes storage, kubernetes volumes, persistent volume, snapshots

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}