Detailed usage of kubernetes object Volume

Overview

Volume is the abstraction and virtualization of various storage resources. Provides a unified interface for managing, controlling, and using storage resources. The volume in Openstack provides storage for virtual machines, and the volume in Docker provides storage for containers. Because the smallest deployable running unit in Kubernetes is pod, Kubernetes volume provides storage for pod. Of course, you do not need to provide a volume when deploying a pod. The containers in the pod use the hard disk of the node where they are located. The place where data can be read and written at the same time is called the readable and writable layer. This storage is temporary storage at the container level, not the pod level. Its life cycle is the same as that of the container. If the container crashes and is restarted, that is, the old container is deleted and a new container is started, the readable and writable layer of the old container is deleted together with the container, and the data on it is lost. Similarly, if the pod is migrated and scheduled between nodes, the read-write layer of the container will not be migrated and scheduled. Therefore, kubernetes needs to provide pod-level volume. The volume in this article refers specifically to kubernetes.

Volume Type

Volume is an abstract concept that has many concrete implementations, each with its own purpose, characteristics, and features. Almost anything can be used as a volume, the types are as follows:

• awsElasticBlockStore
• azureDisk
• azureFile
• cephfs
• configMap
• csi
• downwardAPI
• emptyDir
• fc (fibre channel)
• flocker
• gcePersistentDisk
• gitRepo (deprecated)
• glusterfs
• hostPath
• iSCSI
• local
• nfs
• persistentVolumeClaim
• projected
• portworxVolume
• quobyte
• rbd
• scaleIO
• secret
• storageos
• vsphereVolume
• We will not introduce all the above types one by one here, but only briefly introduce the local disk storage and distributed storage that may be used currently.

Description and examples of common storage types

cephfs

Cephfs is an excellent and popular cloud environment storage solution because it is open source, highly available, elastically scalable, has no special requirements for the operating system and hardware, is easy for users to build, and has no special requirements for the nodes that use it. It has all the features described in awsElasticBlockStore, and a single volume can be used by multiple nodes simultaneously. Users first build their own cephfs environment, then configure the kubernetes cluster to connect to it, and finally use the volume provided by it in the pod. For details, refer to here.

configMap

The user first creates a configMap and saves data in it. At this time, the data is saved in the etcd database of Kubernetes, and the volume does not exist yet. When the user references the created configMap in a pod, the system first creates a volume on the node and saves the data in it. This volume occupies the storage space occupied by the node. After that you can use it like a normal volume.

ConfigMap is an object type in Kubernetes. Its core essence is to pass separately managed configuration information to containers in pods in the form of volumes, and is not used to store persistent data. See here for details.

downwardAPI

Similar to configMap, it passes information to the container in the pod in the form of volume. The information in configMap is passed by the user when creating an object, while the information in downwardAPI comes from the pod object itself. downwardAPI does not need to be created. It is a field in pod Spec, and its content points to other fields of the pod object itself, such as pod metadata, image, and other information. When creating a pod, the system first extracts the pointed fields, then creates a volume and saves the extracted fields and mounts them, so that the container can read these fields.

The purpose of downwardAPI is to provide a means to pass the pod's own field information, such as label and annotation, to the container. See here for details.

emptyDir

The emptyDir volume is created only when a pod instance is run on the node. It is first an empty directory on the node, and any container in the pod can mount it as a volume. If the container is deleted and restarted for some reason, the created emptyDir will not be deleted or cleared. When a pod instance leaves a node and is scheduled to another node or is deleted due to scaling down, emptyDir is deleted, which means that the pod is still there but the data is lost. Example:

apiVersion: v1
kind: Pod
metadata:
 name: test-pd
spec:
 containers:
 - image: k8s.gcr.io/test-webserver
  name: test-container
  volumeMounts:
  - mountPath: /cache
   name: cache-volume
 volumes:
 - name: cache-volume
  emptyDir: {}

glusterfs

Like cephfs, a popular storage solution for cloud environments

hostPath

apiVersion: v1
kind: Pod
metadata:
 name: test-pd
spec:
 containers:
 - image: k8s.gcr.io/test-webserver
  name: test-container
  volumeMounts:
  - mountPath: /test-pd
   name: test-volume
 volumes:
 - name: test-volume
  hostPath:
   # directory location on host
   path: /data
   # this field is optional
   type: Directory

iSCSI

Internet Small Computer System Interface, which is characterized by its cheapness.

local

Similar to emptyDir, it also occupies storage space in the node. The difference is that it is an object type in Kubernetes, and users can manage it like ordinary objects. emptyDir is allocated at runtime when a pod instance is started and deleted when the pod leaves the node. The local volume is created by the user, and the system allocates resources for it on the appropriate node. The pod scheduled to this node can mount it, and it will not disappear when the pod leaves unless the user deletes it. Example:

apiVersion: v1
kind: PersistentVolume
metadata:
 name: example-pv
spec:
 capacity:
  storage: 100Gi
 # volumeMode field requires BlockVolume Alpha feature gate to be enabled.
 volumeMode: Filesystem
 accessModes:
 -ReadWriteOnce
 persistentVolumeReclaimPolicy: Delete
 storageClassName: local-storage
 local:
  path: /mnt/disks/ssd1
 nodeAffinity:
  required:
   nodeSelectorTerms:
   - matchExpressions:
    - key: kubernetes.io/hostname
     operator: In
     values:
     - example-node

nfs

nfs
Network File System

persistentVolumeClaim

Similar to flocker, used to shield different cloud environments

projected

If a container needs to mount multiple existing volumes such as Secret, ConfigMap, DownwardAPI, etc., each volume of this type needs to occupy a mount directory respectively. However, projected can integrate them together and mount them in only one directory. For example:

apiVersion: v1
kind: Pod
metadata:
 name: volume-test
spec:
 containers:
 - name: container-test
  image: busybox
  volumeMounts:
  - name: all-in-one
   mountPath: "/projected-volume"
   readOnly: true
 volumes:
 - name: all-in-one
  projected:
   sources:
   - secret:
     name: mysecret
     Items:
      - key: username
       path: my-group/my-username
   - downwardAPI:
     Items:
      - path: "labels"
       fieldRef:
        fieldPath: metadata.labels
      - path: "cpu_limit"
       resourceFieldRef:
        containerName: container-test
        resource: limits.cpu
   - configMap:
     name: myconfigmap
     Items:
      - key: config
       path: my-group/my-config