Volume Introduction

Concept

We know that the disk files in the container are temporary. Once the container ends running, its files will also be lost. If data needs to be stored for a long time, persistent support for container data is needed, that involves a core concept in Kubernetes: Volume.

Kubernetes, like Docker, also provides support for storage through the way of Volume. Kubernetes Volume is similar to Docker Volume, with the main differences as follows:

1. The Volume in Kubernetes is defined at the Pod level. The Volume can be mounted on multiple containers in the Pod to the same or different paths.

2. The Volume in Kubernetes has the same lifecycle as the Pod, but not related to the lifecycle of the container. When the container terminates or restarts, the data in the Volume will not be lost.

3. The Volume will be cleaned up when the Pod is deleted. Whether data is lost depends on the specific type of the Volume. For example, the data of the Volume of the type emptyDir will be lost, while the data of the PV type will not be lost.

The essence of Volume is a directory, which can contain data, and the containers in the Pod can access this directory. The form of this directory, the medium that supports this directory, and the contents of the directory depend on the specific type of volume used. Kubernetes currently supports a variety of Volume types, commonly used types are as follows:

• cephfs

• glusterfs

• nfs

• csi

• FlexVolume

• emptyDir

• hostPath

• local

• persistentVolumeClaim

• secret

• configMap

Here only some common Volume types are mentioned, for more details visit the official document Volume (opens in a new tab).

Common Volume Types

emptyDir

emptyDir has the same lifecycle as the Pod, it is created when the Pod is assigned to the Node, Kubernetes automatically assigns a directory on the Node, so there is no need to specify the corresponding directory file on the Node host. The initial content of this directory is empty, when the Pod is removed from the Node (the Pod is deleted or the Pod migrates), the data in the emptyDir will be permanently deleted. emptyDir Volume is mainly used for temporary directories that some applications do not need to save permanently, or to share data between containers in the Pod, etc. emptryDir defaults to using host disk storage, but other media can also be used as storage, such as network storage, memory, etc., set the value of emptyDir.medium field to Memory to use memory for storage.

hostPath

The hostPath type of Volume allows mounting files or directories on the Node node into the Pod, but the hostPath type of Volume is rarely used, because the files on each Node node may be different, resulting in a group of Pods (such as Deployment) may behave differently on different Node nodes, and the Pod will cause data confusion once it is scheduled for other Node nodes. Furthermore, to create the file or directory to be written into the Node node in the container requires running processes in the container as root, which poses a certain security risk.

Secret

The Secret object is used to store and manage sensitive information, such as passwords, OAuth tokens, and ssh keys. Putting such information in a secret allows better control of its usage and reduces the risk of accidental exposure. For example, we can put Docker authentication information into Secret, and then mount it into the Pod for authentication when pulling the image, the example is as follows: 1, create Secret

# MYSECRET is the secret name, please specify it yourself
kubectl create secret docker-registry MYSECRET \
--docker-server=uhub.surfercloud.com \
--docker-username=YOUR_SurferCloud_USERNAME@EMAIL.COM \
--docker-password=YOUR_UHUB_PASSWORD

2, Pod mounts Secret

apiVersion: v1
kind: Pod
metadata:
  name: secret-test
spec:
  containers:
  - name: secret-test
    image: centos
    command:
      - sleep
      - "3600"
    volumeMounts:
    - name: config
      mountPath: /root/.docker/
  volumes:
  - name: config
    secret:
      secretName: MYSECRET 
      items:
      - key: .dockerconfigjson
        path: config.json
        mode: 0644

3, Check the mounting effect

$ kubectl exec secret-test -- cat /root/.docker/config.json
{"auths":{"uhub.surfercloud.com":{"username":"YOUR_SurferCloud_USERNAME@EMAIL.COM","password":"YOUR_UHUB_PASSWORD","auth":"dXNlcm5hbWU6cGFzc3dvcmQ="}}}

PV&PVC&StorageClass

Kubernetes currently mainly uses three PersistentVolume, PersistentVolumeClaim, and StorageClass API objects to perform persistent storage, each of which is introduced as follows.

PV

The full name of PV is PersistentVolume. PersistentVolume is a type of Volume, which is an abstraction of underlying storage. PV is created and configured by cluster administrators. Like Node, PV is also a cluster-level resource. PV contains storage type, storage size, and access mode. The life cycle of PV is independent of the Pod, although the Pod using it is destroyed, the PV can still exist.

PersistentVolume interfaces with shared storage through a plug-in mechanism. Kubernetes currently supports the following plug-in types, among which FlexVolume and CSI are Kubernetes standard plug-ins, used to integrate the storage devices of various cloud manufacturers. UK8S is based on CSI and flexVolume to integrate UDisk, UFS, UFile, and other SurferCloud storage media.

• FlexVolume

• CSI

• NFS

• RBD (Ceph Block Device)

• CephFS

• Glusterfs

• HostPath

• Local

PVC

The full name of PVC is PersistentVolumeClaim, PVC is a user's request for storage resources. PVC is similar to Pod, Pod consumes node resources, PVC consumes PV resources. Pod can request CPU and memory, while PVC can request specific storage space and access mode. Users who are really using storage do not need to worry about the details of the underlying storage implementation, they just need to use PVC directly.

StorageClass

Because different applications have different requirements for storage performance, such as read and write speed, concurrency performance, storage size, and so on. If you can only apply for PV statically through PVC, this obviously cannot meet all the storage needs of any application. To solve this problem, Kubernetes has introduced a new resource object: StorageClass, through the definition of StorageClass, cluster administrators can first define storage resources as different types of resources, such as fast storage, slow storage, shared storage (multi-read and write), and block storage (single read and write), etc.

When a user applies for storage resources through PVC, StorageClass uses Provisioner (different storage resources correspond to different Provisioners) to automatically create the required PV for the user. In this way, the application can apply for suitable storage resources at any time without worrying about the cluster administrator not having allocated the required PV in advance.

UK8S supported regions for storage mounting