Kubernetes——PV 和 PVC 的生命周期
PV 和 PVC 的生命周期
PV 是 Kubernetes 集群的存储资源，而 PVC 则代表着资源需求。创建 PVC 时对 PV 发起的使用申请，即为 "绑定"。PV 和 PVC 是一一对应的关系，可用于响应 PVC 申请的 PV 必须要能够容纳 PVC 的请求条件，它们二者的交互遵循如下声明周期：、
一、存储供给
存储攻击（Provisioning）是指为 PVC 准备可用 PV 的机制。Kubernetes 支持两种 PV 供给方式：静态供给和动态供给。
1)静态供给
静态供给是指由集群管理员手动创建一定数量的 PV 的资源供应方式。这些 PV 负责处理存储系统的细节，并将其抽象成易用的存储资源供用户使用。静态提供的 PV 可能属于某存储类（StorageClass），也可能没有存储类，这一点取决于管理员的设定。
2）动态供给
不存在某静态 PV 匹配到用户的 PVC 申请时，Kubernetes 集群会尝试为 PVC 动态创建符合需求的 PV，此即为动态供给。这种方式依赖于存储类的辅助，PVC 必须向一个事先存在的存储类发起动态分配 PV 的请求，没有指定存储类的 PVC 请求会被禁止使用动态创建 PV 的方式。
另外，为了支持使用动态供给机制，集群管理员需要为准入控制器（admission controller）启用 "DefaultStorageClass" 选项，这一点通过 "--admission-control" 命令行选项为 API Server 进行设定即可。
二、存储绑定
用户基于一系列存储需求和访问模式定义好了 PVC 后，Kubernetes 系统的控制器即会为其查找匹配的 PV，并于找到之后在此二者之间建立关联关系，而后它们二者之间的状态即转为 "绑定"（Binding）。若 PV 是为 PVC 而动态创建的，则该 PV 专用于其 PVC。
若是无法为 PVC 找到可匹配的 PV，则 PVC 将一直处于未绑定（unbound）状态，直到有符合条件的 PV 出现并完成绑定方才可用。
1）存储使用（Using）
Pod 资源基于 persistenVolumeClaim 卷类型的定义，将选定的 PVC 关联为存储卷，而后即可为内部的容器使用。对于支持多种访问模式的存储卷来说，用户需要额外指定要使用的模式。一旦完成将存储卷挂碍至 Pod 对象内的容器中，其应用即可使用关联的 PV 提供的存储空间。
2）PVC 保护（Protection）
为了避免使用中的存储卷被移除而导致数据丢失，Kubernetes 自 1.9 版本起引入了 "PVC 保护机制"。启用了此特性后，万一有用户删除了仍处于某 Pod 资源使用中的 PVC 时，Kubernetes 不会立即予以移除，而是推迟到不再被任何 Pod 资源使用后方才执行删除操作。处于此阶段的 PVC 资源的 status 字段为 "Termination"，并且其 Finalizers 字段中包含 "kubernetes.io/pvc-protection"。
三、存储回收（Reclaiming）
完成存储卷的使用目标之后，即可删除 PVC 对象以便进行资源回收。不过，至于如何操作取决于 PV 的回收策略。目前，可用的回收策略有三种：
- Retained
- Recycled
- Deleted
1）留存（Retain）
留存意味着在删除 PVC 之后，Kubernetes 系统不会自动删除 PV，而仅仅是将它置于 "释放" 状态。不过，此种状态的 PV 尚且不能被其他 PVC 申请所绑定，因为此前的申请生成的数据仍然存在，需要由管理员手动决定其后续处理方案。这就意味着，如果想要再次使用此类的 PV 资源，则需要由管理员按下面的步骤手动执行删除操作。
- 删除 PV，这之后，此 PV 的数据依然留存于外部的存储之上。
- 手工清理存储系统上依然留存的数据。
- 手工删除存储系统级的存储卷（例如，RBD 存储系统上的 image）以释放空间，以便再次创建，或者直接将其重新创建为 PV。
2）回收（Recycle）
如果可被底层存储插件支持，资源回收策略会在存储卷上执行数据删除操作并让 PV 资源再次变为可被 Claim。另外，管理员也可以配置一个自定义的回收器 Pod 模板，以便执行自定义的回收操作。不过此种回收策略将废弃。
3）删除（Delete）
对于支持 Deleted 回收策略的存储插件来说，在 PVC 被删除后，会直接移除 PV 对象，同时移除的还有 PV 相关的外部存储系统上的存储资产（asset）。支持这种操作的存储系统有 AWS EBS、GCE PD、 Azure Disk 或 Cinder。动态创建的 PV 资源的回收策略取决于相关存储类上的定义，存储类上的默认策略为 Delete，大多数情况下，管理员都需要按用户期望的处理机制修改此默认策略，以免导致数据非计划内的误删除。
四、扩展PVC
Kubernetes 自 1.8 版本起增加了扩展 PV 空间的特性，截至目前，它所支持的扩展 PVC 机制的存储卷有以下几种：
- gcePersistentDisk
- awsElasticBlockStore
- Cinder
- glusterfs
- rbd
"PersistentVolumeClaimResize" 准入插件负责对支持空间大小变动的存储卷执行更多的验证操作，管理员需要事先启用此插件才能使用 PVC 扩展机制，那些将 "allowVolumeExpansion" 字段的值设置为 "true" 的存储类即可动态扩展存储卷空间。随后，用户改动 Claim 请求更大的空间即能触发底层 PV 空间扩展从而带来 PVC 存储卷的扩展。
对于包含文件系统的存储卷来说，只有在有新的 Pod 资源基于读写模式开始使用 PVC 时才会被执行文件系统的大小调整操作。
换句话说，如果某被扩展的存储卷已经由 Pod 资源所使用，则需要重建此 Pod 对象才能出发文件系统大小的调整操作。支持空间调整的文件系统仅有 XFS 和 EXT3/EXT4。
