This chapter will discuss how Kubernetes manage storage resources.
First we will learn Volume, and Kubernetes how to provide storage container cluster via Volume is; then we will practice several common types of Volume and understand their respective scenarios; and finally, we will discuss how Kubernetes Persistent Volume and Persistent Volume Claim separate cluster administrator and cluster user's responsibility, and supply of static and dynamic supply Volume of practice.
Volume
In this section we discuss the storage model Volume Kubernetes learn how to be mapped to a variety of persistent storage container.
We often say: container and Pod is short.
The implication is that they may be very short life cycle, are frequently created and destroyed. When the container destroyed, stored in a container inside the file system data will be cleared.
For persistent data storage container may be used Kubernetes Volume.
Volume of the life cycle is independent of the vessel, Pod in the container may be destroyed and rebuilt, but Volume is retained.
Essentially, Kubernetes Volume is a directory, which is similar to the Docker Volume. When Volume Pod is to mount, in all containers 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., a complete list of reference https://kubernetes.io/docs/concepts/storage/volumes/#types -of-volumes
Volume provides an abstraction of various backend, the container in the use of Volume data read and write data does not need to be concerned about in the end is stored in the file system of the local node in the cloud it is still hard. It is, for all types of Volume is just a directory.
We will start learning the easiest emptyDir Kubernetes Volume.
emptyDir
emptyDir Volume is the most basic type. As its name implies, a emptyDir Volume is an empty directory on the Host.
emptyDir Volume of the container is durable for the Pod is not. When the Pod is deleted from the node, the contents of Volume will be deleted. But only if the container is destroyed while still Pod, the Volume unaffected.
In other words: emptyDir Volume lifecycle consistent with the Pod.
Pod in all containers can share Volume, which can be assigned its own mount path. Here emptyDir be practiced by way of example, the configuration file as follows:
Here we simulate a producer-consumer scenarios. Pod with two containers producerand consumerthat share a Volume. producer Volume is responsible to write data, consumer the data is read from the Volume.
① the bottom document volumes defines a emptyDir type of Volume shared-volume.
② producer container will shared-volume mount to the /producer_dir directory.
③ producer by echo writing the data to file hello in.
④ consumer container will shared-volume mount to the /consumer_dir directory.
⑤ consumer through cat the file hello read data.
Run the following command to create Pod:
kubectl logs Display container consumer successfully read the producer written data is verified two containers share emptyDir Volume.
Because emptyDir is Docker Host file system directory, the effect is equivalent to the implementation of docker run -v /producer_dir and docker run -v /consumer_dir. By docker inspect viewing the configuration details of the container, we found two containers mount the same directory:
Here /var/lib/kubelet/pods/3e6100eb-a97a-11e7-8f72-0800274451ad/volumes/kubernetes.io~empty-dir/shared-volume is emptyDir real path on the Host.
emptyDir temporary directory is created on the Host, the advantage that can be conveniently provided in Pod shared storage container, no additional configuration. But it does not have the persistence, if Pod does not exist, emptyDir will be no. According to this feature, emptyDir Pod in a container especially suitable for temporary shared storage space required scene, such as consumer-use producers foregoing embodiment.
The next section we learn hostPath Volume.