Kubernetes — 持久卷
Persistent Volume 译自Persistent Volumes 介绍 管理存储是管理计算的独特问题。 PersistentVolume子系统为用户和管理员提供了一个API，其中提供了如何从如何使用存储提供存储的详细信息。为此，我们介绍两种新的API资源：PersistentVolume和PersistentVolumeClaim。 PersistentVolume（PV）是由管理员配置的集群中的一段存储。它是集群中的一种资源就像一个节点是一个集群的资源。 PV是类似Volumes的卷插件，但是具有独立于使用PV的任何单个pod的生命周期。该API对象捕获存储的实现细节，即NFS，iSCSI或云提供商特定的存储系统。 PersistentVolumeClaim（PVC）是用户存储的请求。它类似于pod。 Pod消耗节点资源，PVC消耗PV资源。Pods可以请求特定级别的资源（CPU和内存）。声明可以请求特定的大小和访问模式（例如，一次读写或者多次只读）。 虽然PersistentVolumeClaims允许用户使用抽象存储资源，但是常见的是，用户需要具有不同属性（如性能）的PersistentVolumes，用于不同的问题。 集群管理员需要能够提供多种彼此不同的PersistentVolumes，而不仅仅是大小和访问模式，而不会使用户了解这些卷的实现细节。 对于这些需求，有一个StorageClass资源。 StorageClass为管理员提供了一种描述他们提供的存储的“类”的方法。 不同的类可能映射到服务质量级别，或备份策略，或者由群集管理员确定的任意策略。 Kubernetes本身对于什么类别代表是不言而喻的。 这个概念有时在其他存储系统中称为“配置文件”。 请参阅详细演练与工作示例。 存储和声明的生命周期 PVs是集群中的资源；PVCs是对这种资源的声明，同时也扮演者对资源声明的检查。PVs和PVCs之前的交互遵循生命周期：供应、绑定、使用中、重新申请。 集群管理员创建多个PV。它们携带可供集群用户使用的真实存储的详细信息。它们存在于Kubernetes API中，可用于消费。 供应(Provisioning) PVs会以两种方式供应：静态和动态。 静态 集群管理员创建多个PV。 它们携带可供集群用户使用的真实存储的详细信息。 它们存在于Kubernetes API中，可被使用。 动态 当管理员创建的静态PV都不匹配用户的PersistentVolumeClaim时，集群可能会尝试为PVC指定动态配置卷。 此配置基于StorageClasses：PVC必须指定一个类，并且管理员必须已创建并配置该类才能进行动态配置。 要求该类的声明有效地为自己禁用动态配置。 绑定(Binding) 当用户创建、或已经创建了一个PersistenVolumenClaim并指定大小和访问类型。Master中的控制循环会检测新的PVC，找到一个匹配的PV（如果可能的话），并将它们绑定在一起。如果一个PV被动态地供应某个PVC，循环将总是把这个PV和该PVC绑定。否则，用户总是至少得到他们要求的内容，但是卷可能超出了要求。一旦绑定，PersistentVolumeClaim绑定是排他的，不管用于绑定它们的模式。 如果匹配的卷不存在，请求将无限期地保持。 随着匹配卷变得可用，请求将被绑定。 例如，提供许多50Gi PV的集群将不匹配要求100Gi的PVC。 当集群中添加100Gi PV时，可以绑定PVC。
