这个文档描述当前在k8s中PersistentVolumes的使用。 我们建议和volume一起进行了解
Introduction
管理存储和管理计算是截然不同的问题。 持久存储子系统对用户和管理者提供了API， 通过这API, 你可以了解存储是如何提供的，是如何消耗的，为了达到这样的效果，我们将介绍两个新的API：PersistenVolume和PersistenVolumeClaim
一个 PersistenVolume（PV）是一块在集群中被管理员划定好的网络存储，它就和node的一样，都是cluster的一个资源。 PV相当前Volume的扩展， 只不过有一个独立于任何使用PV的Pod个体的生命周期。这个API捕捉了一个存储实施的细节，这个存储可以是NFS,ISCSI或者cloud-provider-specfifc存储系统
一个PersistentVolumeClaim(PVC) 是一个由用户发起的存储请求， 它类似于一个Pod，Pod占用节点资源，PVC消费PV资源。
Pod可以请求不同级别的资源（CPU和内存）. Claims可以请求一个特殊的大小和access modes（例如可以挂载一次读写，或者多次只读）的资源
请看 detailed walkthrough with working examples
Lifecycle of a volume and claim
PV占用集群资源。 PVC是请求这些资源并充当这些资源的一个提取证，在一个生命周期中，PV和PVC是相互作用的
Provisioning
一个集群的管理者会创建一些PV，这些PV关注的是能被集群用户使用的真实存储的细节。这些PV存在k8s的API，可以被有效的使用。
Binding
因为一个指明大小的，有指定access modes的存储请求 ， 一个用户会创建一个PersistentVolumeClaim。在master中，使用循环来监视，这样就能发现新的PVC，并且找到一个相匹配的PV（如果可以的话）， 然后把他们绑定到一块。用户将总是能得到他们所要求的最少的东西，但是得到的存储可能超过他所要求的。 一旦绑定， 不论什么模式被用来绑定他们，PersistentVolumeClaim的绑定是独有的。
如果没有volume可以匹配上的，则Claims会一直保持未绑定状态。当匹配到的volume是有效的时候，Claim将会变为绑定的。 例如，一个集群提供了50G的PV将不会被一个请求100G的PVC所匹配。 当集群提供一个100G的PV的时候，这个PVC将会被绑定。
Using
Pod把claims当作存储卷。 集群检测claim来发现相绑定的存储卷和pod存储卷的挂载点（ mounts that volume for a pod）。 对于支持多种access modes的volume来说， 当用户把claim做为一个pod的volume的时候需要指出想要的mode
一旦用户有一个claim并且claim处于绑定状态，这个绑定的PV在用户不解除绑定的时候一直属于该用户。 Users schedule Pods and access their claimed PVs by including a persistentVolumeClaim in their Pod’s volumes block.See below for syntax details. 用户通过在他们的Pod的存储块中包含一个PVC来调度Pod和使用它们请求到的PV
Releasing
当一个用户使用完了他volume， 可以通过API来删除对应的PVC，这样允许回收资源。 当claim被删除后，这个volume可以被认为是“release"状态， 但是它对其他的claim来说是不可用的。 前一个claim产生的数据会一直在volume中，这必须根据你们的策略进行处理
Reclaiming
PersistentVolume的回收策略告诉集群，当volume从他所属的claim中被释放后，集群可以对volume做什么。 当前，volume可以保留，回收和删除。 保留允许手动再利用资源。AWS EBS, GCE PD或者Cinder volume这些volume插件支持在k8s中删除PersistenVolume和其关联的在外部基础设施中的存储。（ For those volume plugins that support it, deletion removes both the PersistentVolume object from Kubernetes as well as deletes associated storage asset in external infrastructure such as AWS EBS, GCE PD or Cinder volume.）。 如果有合适的volume插件支持，那么会对volume循环的执行一个基本的擦除命令（rm -rf /tenvoluem/*）来使得他对新的claim变得可用。
Tpyes of Persistent Volumes
PersistenVolume类型是作为插件（plugin）实现的。k8s当前支持下面这种产检（plugin）：
- GCEPersistentDisk
- AWSElasticBlockStore
- AzureFile
- FC (Fibre Channel)
- NFS
- iSCSI
- RBD (Ceph Block Device)
- CephFS
- Cinder (OpenStack block storage)
- Glusterfs
- VsphereVolume
- HostPath (single node testing only – local storage is not supported in any way and WILL NOT WORK in a multi-node cluster)
Persistent Volumes
每一个PV都包含一个spec和status，它是volume的规格和status
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv0003
spec:
capacity:
storage: 5Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Recycle
nfs:
path: /tmp
server: 172.17.0.2
Capacity
一个PV都会有一个特定的存储能力，使用PV的capacity来设置。可以参考k8s Resource Model 来了解capacity想达到的效果（ See the Kubernetes Resource Model to understand the units expected by capacity）
当前只有存储的大小可以被设置或者被请求，未来可能包括IOPS，throughput等等
Access Modes
一个PersistentVolume可以被挂在一个主机上通过任何被资源提供者支持的方式。就像下表列出来的一样，提供者有不同的能力，每一个PV的access mode被设置成指定volume所支持的特定的mode。例如，NFS可以支持多次读写的客户端（ NFS can support multiple read/write clients），但是一个NFS的PV可能在server上被到处作为只读的。每一个PV通过它自己的access mode设置来描述自己特别的能力
access modes的类别为：
- ReadWriteOnce – the volume can be mounted as read-write by a single node
- ReadOnlyMany – the volume can be mounted read-only by many nodes
- ReadWriteMany – the volume can be mounted as read-write by many nodes
缩写为：
- RWO - ReadWriteOnce
- ROX - ReadOnlyMany
- RWX - ReadWriteMany
重要的：一个volume在同一时间，只能使用一种access mode被挂载，即使他支持多个。例如：一个GCEPersistenDisk可以在一个node中作为ReadWriteOnce被挂载或者使用ReadOnlyMany被多个node挂载，但是这两种方式不能同时存在
| Volume Plugin | ReadWriteOnce | ReadOnlyMany | ReadWriteMany |
|---|---|---|---|
| AWSElasticBlockStore | x | - | - |
| AzureFile | x | x | x |
| CephFS | x | x | x |
| Cinder | x | - | - |
| FC | x | x | - |
| FlexVolume | x | x | - |
| GCEPersistentDisk | x | x | - |
| Glusterfs | x | x | x |
| HostPath | x | - | - |
| iSCSI | x | x | - |
| NFS | x | x | x |
| RDB | x | x | - |
| VsphereVolume | x | - | - |
Recycling Policy
当前的回收策略是：
- Retain – manual reclamation 手工回收
- Recycle – basic scrub (“rm -rf /thevolume/*”) 基础擦除
- Delete – associated storage asset such as AWS EBS, GCE PD or OpenStack Cinder volume is deleted
当前，只有NFS和HostPath支持Recycle 。 AWS EBS, GCE PD和Cinder存储卷支持删除
Phase
一个volumn将是下面状态中的一种
- Avaliable - 一个空闲的资源，还没有和claim绑定
- Bound - volume已经和claim绑定
- Released - 对应的claim已经被删除。但是资源没有被集群回收
- Failed --这个volume自动回收失败
The CLI will show the name of the PVC bound to the PV
PersistentVolumeClaims
每一个PVC都包括一个spec和status, 他是claim的规格和status
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: myclaim
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 8Gi
selector:
matchLabels:
release: "stable"
matchExpressions:
- {key: environment, operator: In, values: [dev]}
Access Modes
参照PV access mode
Resources
Claims和pod一样，可以请求指定数量的资源。这个请求是针对存储的， resource model 同样适用于volumes和claims
Selector
Claims可以指定一个label选择器来进一步的过滤设置的volumes。只有通过labels匹配上选择器的volumes才可以和claim绑定
选择器由两部分组成：
- matchLabels - volume必须有一个这个样值的label
- matchExpressions - values和operator把列出的key和操作符关联起来（ a list of requirements made by specifying key, list of values, and operator that relates the key and values），有效的操作符包括In, NotIn，Esxists和DoesNotExist
matchLabels和matchExpressions需要同时匹配（ All of the requirements, from both matchLabels and matchExpressions are ANDed together – they must all be satisfied in order to match）
Claims As Volumes
Pod通过把claim当作volume来使用存储。当Pod使用claim，Claim必须和Pod存在于相同的命名空间。集群在Pod的命名空间查找claim，并使用它得到claim的PersistentVolume（ uses it to get the PersistentVolume backing the claim.）
kind: Pod
apiVersion: v1
metadata:
name: mypod
spec:
containers:
- name: myfrontend
image: dockerfile/nginx
volumeMounts:
- mountPath: "/var/www/html"
name: mypd
volumes:
- name: mypd
persistentVolumeClaim:
claimName: myclaim
A Note on NameSpaces
PersistentVolumes的绑定是特殊的，因为PersistentVolumeClaims在一个命名空间下，只有在同一个命名空间下的挂载请求，才能请求相同的ROX RWX（ mounting claims with “Many” modes (ROX, RWX) is only possible within one namespace.）
本人翻译是个渣..