We all know that a container is a transient, unstable existence (it can die at any time), and all the data in it is gone after it dies, but we have a lot of data that needs to be persisted all the time. What happens then? The idea is simple: store the container’s data in a persistent location (such as S3).

Volume

To solve this problem, Kubernetes provides Volume. A Volume is a directory supported by a storage middleware lock, which is determined by the Volume type.

A00784D4-9D6B-4091-B78E-16834F743338

As shown in the figure above, in K8S, a Volume is attached to a Pod. As we mentioned before, network and storage are shared in Pod, so this Volume can be shared by all containers in Pod. A Volume has the same lifetime as a Pod, but is longer than a container, allowing data to be shared between containers.

Volume Types

A directory mounted to a Pod is supported by the underlying Volume Type, which determines the directory’s properties, such as size, content, and so on. Here are some of the Volume types:

emptyDir

As the name suggests, this is an “empty” Volume. This empty Volume will be created when pods are scheduled on nodes. A Volume of this type has the same life cycle as a Pod. If the Pod dies, all data in the Volume is lost.

hostPath

If the POD dies, the data will remain on the host, but if the host dies, the data will be lost.

gcePersistentDisk

As the name suggests, strongly coupled GCE, not to mention.

awsElasticBlockStore

Same as above

nfs

With NFS, we can mount an NFS share to a pod.

iscsi

Same as above

secret

We can use this type to attach the information we put in Secret, such as passwords and tokens, to pod for the application to use.

persistentVolumeClaim

This is one of the most important, is also one of the most commonly used, we can make a Persistent Volume (PV) mounted to the Pod, through persistentVolumeClaim (PVC).

Persistent Volumes

In traditional IT environments, storage is managed by the system administrator, and the end user gets instructions on how to use IT, but doesn’t care how the underlying storage is managed.

In the container world, it’s the same thing. Kubernetes has a subsystem called Persistent Volumes to which administrators add and manage Persistent Volumes through the Persistent Volume API. The user then uses the Persistent Volume Claim API to use it.

A PV is a storage device mounted to a cluster over a network.

73BBB017-7870-4014-88E4-67B1AE5BC73F

PVS can be created statically with the StorageClass resource or added dynamically. A StorageClass contains predefined initializers and parameters to create a PV.

Some Volume Types that support management with PV are:

  • GCEPersistentDisk
  • AWSElasticBlockStore
  • AzureFile
  • NFS
  • iSCSI
  • CephFS
  • Cinder
  • etc.

Persistent Volume Claims

A Persistent Volume Claim (PVC) is a request that a user wants to use storage. Users apply for PV resources by specifying the size, access rights, etc. When a suitable resource (PV) is found, it is bound to the PVC:

CD52FF8E-EFFE-4519-AAD8-073BE55E97E5

When bind succeeds, the PVC is ready to be used in the Pod:

2AECAABF-FE93-4F51-9716-CDBB334BE549

When a user finishes using the reclaimed PV, the reclaimed PV can be released, reclaimed and used again.