Volumes
On-disk files in a container are ephemeral, which will be lost when the container crashes and are difficult to be shared between containers running together in a pod. The Kubernetes volume abstraction solves both of these problems. Volumes cannot be independently created, but defined in the pod spec.
All containers in a pod can access its volumes, but the volumes must be attached and can be attached to any directory in the container.
The following figure shows how a storage volume is used between containers in a pod.
A volume will no longer exist if the pod to which it is attached does not exist. However, files in the volume may outlive the volume, depending on the volume type.
Volume Types
Kubernetes supports multiple types of volumes. The most commonly used ones are as follows:
- emptyDir: an empty volume used for temporary storage
- hostPath: a volume that mounts a directory of the host into your pod
- ConfigMap and secret: special volumes that inject or pass information to your pod. For details about how to mount ConfigMaps and secrets, see ConfigMaps and Secrets.
- persistentVolumeClaim: Kubernetes persistent storage class. For details, see PersistentVolumes, PersistentVolumeClaims, and StorageClasses.
emptyDir
emptyDir is an empty volume in which your applications can read and write the same files. The lifetime of an emptyDir volume is the same as that of the pod it belongs to. After the pod is deleted, data in the volume is also deleted.
Some uses of an emptyDir volume are as follows:
- Scratch space, such as for a disk-based merge sort
- Checkpointing a long computation for recovery from crashes
Example emptyDir configuration:
apiVersion: v1 kind: Pod metadata: name: nginx spec: containers: - image: nginx:alpine name: test-container volumeMounts: - mountPath: /cache name: cache-volume volumes: - name: cache-volume emptyDir: {}
emptyDir volumes are stored on the disks of the node where the pod is located. You can also set the storage medium to the node memory, for example, by setting medium to Memory.
volumes: - name: html emptyDir: medium: Memory
HostPath
hostPath is a persistent storage volume. Data in an emptyDir volume will be deleted when the pod is deleted, but not the case for a hostPath volume. Data in a hostPath volume will still be stored in the node path to which the volume was mounted. If the pod is re-created and scheduled to the same node and it is mounted with a new hostPath volume, data written by the old pod can still be read.
Data stored in hostPath volumes is related to the node. Therefore, hostPath is not suitable for applications such as databases. For example, if a pod in which a database instance runs is scheduled to another node, the read data will be totally different.
Therefore, do not use hostPath to store cross-pod data, because after a pod is rebuilt, it will be randomly scheduled to another node, which may cause inconsistency when data is written.
apiVersion: v1 kind: Pod metadata: name: test-hostpath spec: containers: - image: nginx:alpine name: hostpath-container volumeMounts: - mountPath: /test-pd name: test-volume volumes: - name: test-volume hostPath: path: /data
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot