A, Kubernetes how to manage storage resources
Volume understand
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.
Two, kubernetes Volume species
1, 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 producer has two containers and consumer, they share a Volume. Volume producer is responsible to write data, consumer data is read from the Volume.
① the bottom volumes file defines a emptyDir type of Volume shared-volume.
② producer container to the shared-volume mount / producer_dir directory.
③ producer by echo writes data in the file hello.
④ consumer container to the shared-volume mount / consumer_dir directory.
⑤ consumer by reading data from a file hello cat.
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.
2、hostPath Volume
hostPath Volume role is to Docker Host file system directory that already exists mount to Pod container. Most applications will not use hostPath Volume, because it actually increases the coupling Pod and nodes, limiting the use of Pod. However, those applications require access Kubernetes or Docker internal data (configuration files and binary library) is required to use hostPath.
The following is a look at the relevant section of Volume:
This defines three hostPath volume k8s, certs and pki, respectively Host directory / etc / kubernetes, / etc / ssl / certs and / etc / pki.
If the Pod is destroyed, hostPath corresponding directory will also be retained, this point of view, hostPath persistent stronger than emptyDir. But once Host crashes, hostPath also can not visit.
3, External Storage Provider
If deployed on Kubernetes such as AWS, GCE, Azure other public cloud, the cloud can be used directly as a hard disk Volume, following is an example of AWS Elastic Block Store:
To use ESB volume in the Pod, you must first create in AWS, and then referenced by volume-id. Other cloud hard drive usage may refer to each public cloud vendor's official documents.
Kubernetes Volume may be used mainstream distributed memory, such as Ceph, the GlusterFS etc. The following are examples of Ceph:
Ceph file system / some / path / in / side / cephfs directory path is to mount the container / test-ceph.
相对于 emptyDir 和 hostPath，这些 Volume 类型的最大特点就是不依赖 Kubernetes。Volume 的底层基础设施由独立的存储系统管理，与 Kubernetes 集群是分离的。数据被持久化后，即使整个 Kubernetes 崩溃也不会受损。
当然，运维这样的存储系统通常不是项简单的工作，特别是对可靠性、高可用和扩展性有较高要求时。
Volume 提供了非常好的数据持久化方案，不过在可管理性上还有不足。
4、PV & PVC
Volume 提供了非常好的数据持久化方案，不过在可管理性上还有不足。
拿前面 AWS EBS 的例子来说，要使用 Volume，Pod 必须事先知道如下信息：
（1）当前 Volume 来自 AWS EBS。
（2）EBS Volume 已经提前创建，并且知道确切的 volume-id。
Pod 通常是由应用的开发人员维护，而 Volume 则通常是由存储系统的管理员维护。开发人员要获得上面的信息：
（1）要么询问管理员。
（2）要么自己就是管理员。
这样就带来一个管理上的问题：应用开发人员和系统管理员的职责耦合在一起了。如果系统规模较小或者对于开发环境这样的情况还可以接受。但当集群规模变大，特别是对于生成环境，考虑到效率和安全性，这就成了必须要解决的问题。
Kubernetes 给出的解决方案是 PersistentVolume 和 PersistentVolumeClaim。
PersistentVolume (PV) 是外部存储系统中的一块存储空间，由管理员创建和维护。与 Volume 一样，PV 具有持久性，生命周期独立于 Pod。
PersistentVolumeClaim (PVC) 是对 PV 的申请 (Claim)。PVC 通常由普通用户创建和维护。需要为 Pod 分配存储资源时，用户可以创建一个 PVC，指明存储资源的容量大小和访问模式（比如只读）等信息，Kubernetes 会查找并提供满足条件的 PV。
有了 PersistentVolumeClaim，用户只需要告诉 Kubernetes 需要什么样的存储资源，而不必关心真正的空间从哪里分配，如何访问等底层细节信息。这些 Storage Provider 的底层信息交给管理员来处理，只有管理员才应该关心创建 PersistentVolume 的细节信息。
Kubernetes 支持多种类型的 PersistentVolume，比如 AWS EBS、Ceph、NFS 等，完整列表请参考：https://kubernetes.io/docs/concepts/storage/persistent-volumes/#types-of-persistent-volumes