Kubernetes之持久化存储

ConfigMap、Secret、emptyDir、hostPath等属于临时性存储，当pod被调度到某个节点上时，它们随pod的创建而创建，临时占用节点存储资源，当pod离开节点时，存储资源被交还给节点，pod一旦离开它们就失效，不具备持久化存储数据的能力。与此相反，持久化存储拥有独立的生命周期，具备持久化存储能力，其后端一般是独立的存储系统如NFS、iSCSI、cephfs、glusterfs等。

PV与PVC

Kubernetes中的node代表计算资源，而PersistentVolume(PC)则代表存储资源，它是对各种诸如NFS、iSCSI、云存储等各种存储后端所提供存储块的统一抽象，通过它屏蔽低层实现细节。与普通volume不同，PC拥有完全独立的生命周期。

因为PC表示的是集群能力，它是一种集群资源，所以用户不能直接使用PC，就像不能直接使用内存一样，需要先向系统申请。Kubernetes通过PersistentVolumeClaim(PVC)代理用户行为，用户通过对PVC的操作实现对PC申请、使用、释放等操作，PVC是用户层面的资源。

静态PV与动态PV

静态PV由系统管理员负责创建、提供、维护，系统管理员为用户屏蔽真正提供存储的后端及其实现细节，普通用户作为消费者，只需通过PVC申请、使用此类资源。

当用户通过PVC申请PV时，如果系统无法从静态PV为用户分配资源，则尝试创建动态PV。前提条件是用户需要在PVC中给出“storage class”名称，指示系统创建动态PV的具体方式。“storage class”可以理解成某种具体的后端存储，它也是Kubernetes集群中的一种资源，当然在使用之前，需要先由集群管理员负责创建、配置。如果用户的PVC中“storage class”的值为""，则表示不能为此PVC动态创建PV。

想要开启基于“storage class”的动态存储供应功能，需要为apiServer启用"DefaultStorageClass"入口控制器，具体方法为在apiServer选项--enable-admission-plugins中包含"DefaultStorageClass"字符串。

PV与PVC绑定

用户创建包含容量、访问模式等信息的PVC，向系统请求存储资源。系统查找已存在PV或者监控新创建PV，如果与PVC匹配则将两者绑定。如果PVC创建动态PV，则系统将一直将两者绑定。PV与PVC的绑定是一一对应关系，不能重复绑定与被绑定。如果系统一直没有为PVC找到匹配PV，则PVC无限期维持在"unbound"状态，直到系统找到匹配PV。实际绑定的PV容量可能大于PVC中申请的容量。

在POD中使用PVC

当系统为用户创建的PVC绑定PV后，表明用户成功申请了存储资源。用户在pod中定义PVC类型的volume，当创建POD实例时系统将与PVC绑定的PV挂载到POD实例。如果PV支持多种访问模式，用户需要pod的PVC volume中指定期望的类型。注意，pod与PVC必需位于相同namespace之下。

存储对象使用中保护

如果启用了存储对象使用中保护特性，则不允许将正在被pod使用的活动PVC或者绑定到PVC的PV从系统中移除，防止数据丢失。活动PVC指使用PVC的pod处于pending状态并且已经被指派节点或者处于running状态。

如果已经启用存储对象使用中保护特性，且用户删除正在被pod使用的活动PVC，不会立即删除PVC，而是延后到其状态变成非活动。同样如果用户删除已经绑定的PV，则删除动作延后到PV解除绑定后。

当PVC处于保护中时，其状态为"Terminating"并且其"Finalizers"包含"kubernetes.io/pvc-protection"：

kubectl describe pvc hostpath
Name:          hostpath
Namespace:     default
StorageClass:  example-hostpath
Status:        Terminating
Volume:        
Labels: