8.1 共享存储机制概述
Kubernetes对于有状态的容器应用或者对数据需要持久化的应用，
不仅需要将容器内的目录挂载到宿主机的目录或者emptyDir临时存储
卷，而且需要更加可靠的存储来保存应用产生的重要数据，以便容器应
用在重建之后仍然可以使用之前的数据。不过，存储资源和计算资源
（CPU/内存）的管理方式完全不同。为了能够屏蔽底层存储实现的细
节，让用户方便使用，同时让管理员方便管理，Kubernetes从1.0版本就
引入PersistentVolume（PV）和PersistentVolumeClaim（PVC）两个资源
对象来实现对存储的管理子系统。
PV是对底层网络共享存储的抽象，将共享存储定义为一种“资源”，
比如Node也是一种容器应用可以“消费”的资源。PV由管理员创建和配
置，它与共享存储的具体实现直接相关，例如GlusterFS、iSCSI、RBD
或GCE或AWS公有云提供的共享存储，通过插件式的机制完成与共享
存储的对接，以供应用访问和使用。
PVC则是用户对存储资源的一个“申请”。就像Pod“消费”Node的资
源一样，PVC能够“消费”PV资源。PVC可以申请特定的存储空间和访问
模式。
使用PVC“申请”到一定的存储空间仍然不能满足应用对存储设备的
各种需求。通常应用程序都会对存储设备的特性和性能有不同的要求，
包括读写速度、并发性能、数据冗余等更高的要求，Kubernetes从1.4版
本开始引入了一个新的资源对象StorageClass，用于标记存储资源的特
性和性能。到1.6版本时，StorageClass和动态资源供应的机制得到了完
善，实现了存储卷的按需创建，在共享存储的自动化管理进程中实现了
重要的一步。
通过StorageClass的定义，管理员可以将存储资源定义为某种类别
（Class），正如存储设备对于自身的配置描述（Profile），例如“快速
存储”“慢速存储”“有数据冗余”“无数据冗余”等。用户根据StorageClass
的描述就能够直观地得知各种存储资源的特性，就可以根据应用对存储
资源的需求去申请存储资源了。
Kubernetes从1.9版本开始引入容器存储接口Container Storage
Interface（CSI）机制，目标是在Kubernetes和外部存储系统之间建立一
套标准的存储管理接口，通过该接口为容器提供存储服务，类似于
CRI（容器运行时接口）和CNI（容器网络接口）。
存储类别（Class）
PV可以设定其存储的类别，通过storageClassName参数指定一个
StorageClass资源对象的名称。具有特定类别的PV只能与请求了该类别
的PVC进行绑定。未设定类别的PV则只能与不请求任何类别的PVC进行
绑定