This chapter will discuss how Kubernetes manages storage resources.
First, we will learn about Volume and how Kubernetes provides storage for containers in the cluster through Volume; then we will practice several commonly used Volume types and understand their respective application scenarios; finally, we will discuss how Kubernetes uses Persistent Volume and Persistent Volume Claim separates the responsibilities of cluster administrators and cluster users, and implements static and dynamic provisioning of Volumes.
Volume
In this section, we discuss Volume, the storage model of Kubernetes, and learn how to map various persistent storage to containers.
We often say: Containers and Pods are ephemeral.
The implication is that they may have a short lifespan, being destroyed and created frequently. When the container is destroyed, the data stored in the container's internal file system will be cleared.
To persist container data, Kubernetes Volumes can be used.
The life cycle of a Volume is independent of the container, the container in the Pod may be destroyed and rebuilt, but the Volume will be preserved.
Essentially, a Kubernetes Volume is a directory, similar to a Docker Volume. When a Volume is mounted to a Pod, all containers in the Pod can access the Volume. Kubernetes Volume also supports multiple backend types, including emptyDir, hostPath, GCE Persistent Disk, AWS Elastic Block Store, NFS, Ceph, etc. For a complete list, please refer to https://kubernetes.io/docs/concepts/storage/volumes/#types -of-volumes
Volume provides abstractions for various backends. When a container uses Volume to read and write data, it does not need to care whether the data is stored in the file system of the local node or on the cloud disk. To it, all types of Volumes are just a directory.
We will start with the simplest emptyDir to learn about Kubernetes Volume.
emptyDir
emptyDir is the most basic Volume type. As its name suggests, an emptyDir Volume is an empty directory on the Host.
emptyDir Volumes are persistent for containers, but not for Pods. When a Pod is deleted from a node, the contents of the Volume are also deleted. But if only the container is destroyed and the Pod is still there, the Volume is not affected.
That is to say: the life cycle of emptyDir Volume is consistent with that of Pod.
All containers in a Pod can share a Volume, and they can specify their own mount paths. The following is an example to practice emptyDir, the configuration file is as follows:
Here we simulate a producer-consumer scenario. A Pod has two containers producerand consumerthey share a Volume. producer Responsible for writing data to Volume, consumer it is to read data from Volume.
① A type of Volume volumes is defined at the bottom of the file .emptyDirshared-volume
②The producer container will shared-volume mount to the /producer_dir directory.
③ producer By echo writing the data to the file hello .
④The consumer container will be shared-volume mounted to the /consumer_dir directory.
⑤ consumer By reading data cat from a file .hello
Execute the following command to create a Pod:
kubectl logs It shows that the container consumer successfully read the producer written data, verifying that the two containers share the emptyDir Volume.
Because emptyDir is a directory in the Docker Host filesystem, its effect is equivalent to executing docker run -v /producer_dir and docker run -v /consumer_dir. By docker inspect looking at the detailed configuration information of the container, we found that both containers have mounted the same directory:
Here /var/lib/kubelet/pods/3e6100eb-a97a-11e7-8f72-0800274451ad/volumes/kubernetes.io~empty-dir/shared-volume is the real path of emptyDir on Host.
emptyDir is a temporary directory created on the Host, and its advantage is that it can easily provide shared storage for containers in a Pod without additional configuration. But it's not persistent, if the Pod doesn't exist, the emptyDir also doesn't exist. According to this feature, emptyDir is particularly suitable for scenarios where containers in a Pod need to temporarily share storage space, such as the previous producer-consumer use case.
In the next section we learn about hostPath Volume.
books:
1. "Play Kubernetes for 5 minutes a day"
https://item.jd.com/26225745440.html
2. "Fun with Docker container technology for 5 minutes a day"
https://item.jd.com/16936307278.html
3. "Fun with OpenStack for 5 minutes a day"
https://item.jd.com/12086376.html
