Kubernetes持久化存储1

erlchina

一、简介

　　存储管理与计算管理是两个不同的问题。Persistent Volume子系统，对存储的供应和使用做了抽象，以API形式提供给管理员和用户使用。要完成这一任务，我们引入了两个新的API资源：Persistent Volume（持久卷）和Persistent Volume Claim（持久卷消费者）。

　　Persistent Volume（PV）是集群之中的一块网络存储。跟Node一样，也是集群的资源。PV跟Volume(卷)类似，不过会有独立于Pod的生命周期。这一API对象包含了存储的实现细节，例如NFS、iSCSI或者其他的云提供商的存储系统。Persistent Volume Claim(PVC)是用户的一个请求。跟Pod类似，Pod消费Node的资源，PVC消费PV的资源。Pod能够申请特定的资源（CPU和内存）；Claim能够请求特定的尺寸和访问模式（例如可以加载一个读写，以及多个只读实例）。

二、PV和PVC的生命周期

　　PV是集群的资源。PVC是对这一资源的请求，也是对资源的所有权的检验。PV和PVC之间的互动遵循如下的生命周期。

2.1 供应

　　集群管理员会创建一系列的PV。这些PV包含了为集群用户提供的真实存储资源，它们可利用KubernetesAPI来消费。

2.2 绑定

　　用户创建一个包含了容量和访问模式的持久卷申请。Master会监听PVC的产生，并尝试根据请求内容查找匹配的PV，并把PV和PVC进行绑定。用户能够获取满足需要的资源，并且在使用过程中可能超出请求数量。

　　如果找不到合适的卷，这一申请就会持续处于非绑定状态，一直到出现合适的PV。例如一个集群准备了很多的50G大小的持久卷，（虽然总量足够）也是无法响应100G的申请的，除非把100G的PV加入集群。

2.3 使用

　　Pod把申请作为卷来使用。集群会通过PVC查找绑定的PV，并Mount给Pod。对于支持多种访问方式的卷，用户在使用PVC作为卷的时候，可以指定需要的访问方式。

一旦用户拥有了一个已经绑定的PVC，被绑定的PV就归该用户所有了。用户的Pods能够通过在Pod的卷中包含的PVC来访问他们占有的PV。

2.4 释放

　　当用户完成对卷的使用时，就可以利用API删除PVC对象了，而且他还可以重新申请。删除PVC后，对应的卷被视为“被释放”，但是这时还不能给其他的PVC使用。之前的PVC数据还保存在卷中，要根据策略来进行后续处理。

2.5 回收

　　PV的回收策略向集群阐述了在PVC释放卷的时候，应如何进行后续工作。目前可以采用三种策略：保留，回收或者删除。保留策略允许重新申请这一资源。在持久卷能够支持的情况下，删除策略会同时删除持久卷以及AWS EBS/GCE PD或者Cinder卷中的存储内容。如果插件能够支持，回收策略会执行基础的擦除操作（rm -rf /thevolume/*），这一卷就能被重新申请了。

三、持久卷PV

3.1 持久卷的类型

　　持久卷是以插件方式实现的，目前支持如下插件：

• GCEPersistentDisk
  
• AWSElasticBlockStore
  
• NFS
  
• iSCSI
  
• RBD (Ceph Block Device)
  
• Glusterfs
  
• HostPath (单节点测试使用)
  
• 持久卷
  

3.2 持久卷定义

　　每个 PV 包含一个 spec 以及 status ，用于描述该卷的规格和状态。

　　

apiVersion: v1　　
kind: PersistentVolume
　　
metadata:
　　name: pv0001
　　
spec:
　　capacity:
　　storage: 5Gi
　　accessModes:
- ReadWriteMany　　persistentVolumeReclaimPolicy: Recycle
　　nfs:
　　path:
"/data/disk1"　　server:
192.168.20.47　　readOnly:
false　　


3.3 Capacity（容量）

　　一般来说，PV会指定存储容量。这里需要使用PV的capcity属性。目前存储大小是唯一一个能够被申请的指标，今后会加入更多属性，例如IOPS，吞吐能力等。

3.4 AccessModes（访问模式）

　　只要资源提供者支持，持久卷能够被用任何方式加载到主机上。每种存储都会有不同的能力，每个PV的访问模式也会被设置成为该卷所支持的特定模式。例如NFS能够支持多个读写客户端，但是某个NFS PV可能会在服务器上以只读方式使用。每个PV都有自己的一系列的访问模式，这些访问模式取决于PV的能力。访问模式的可选范围如下：

• ReadWriteOnce：该卷能够以读写模式被加载到一个节点上。
  
• ReadOnlyMany：该卷能够以只读模式加载到多个节点上。
  
• ReadWriteMany：该卷能够以读写模式被多个节点同时加载。
  

在CLI下，访问模式缩写为：

• RWO：ReadWriteOnce
  
• ROX：ReadOnlyMany
  
• RWX：ReadWriteMany
  

　　另外，一个卷不论支持多少种访问模式，同时只能以一种访问模式加载。例如一个GCE Persistent Disk既能支持ReadWriteOnce，也能支持ReadOnlyMany。

3.5 RecyclingPolicy（回收策略）

　　当前的回收策略可选值包括：

• Retain，人工重新申请
  
• Recycle，基础擦除（“rm-rf/thevolume/*”）
  
• Delete，相关的存储资产例如AWS EBS，GCE PD或者OpenStack Cinder卷一并删除。
  

目前，只有NFS和HostPath支持Recycle策略，AWS EBS、GCE PD以及Cinder卷支持Delete策略。

3.6 阶段（Phase）

　　一个卷会处于如下阶段之一：

• Available：可用资源，尚未被绑定到PVC上
  
• Bound：该卷已经被绑定
  
• Released：PVC已经被删除，但该资源尚未被集群回收
  
• Failed：该卷的自动回收过程失败。
  

四、PersistentVolumeClaims（持久卷消费者）

　　每个 PVC 包含一个 spec 以及 status，用以表达其规格和状态。

　　

apiVersion: v1　　
kind: PersistentVolumeClaim
　　
metadata:
　　name: nfs
-pvc　　
spec:
　　accessModes:
- ReadWriteMany　　resources:
　　requests:
　　storage: 1Gi
　　


4.1 访问模式

　　PVC使用跟PV一致的访问模式。

4.2 资源

　　PVC跟Pod一样可以请求特定数量的资源。在这里的请求内容就是存储（storage）。ResourceModel文中提到的内容对PV和PVC同样适用。

4.3 使用PVC卷

　　Pod能够借助PVC来访问存储。PVC必须跟Pod处于同一个命名空间。集群找到Pod命名空间中的PVC，然后利用PVC获取到背后的PV。这个卷就会被加载到主机上，让Pod可以使用。

　　

[iyunv@k8s-master pv]# cat test-pvc-pod.yaml　　
apiVersion: v1
　　
kind: Pod
　　
metadata:
　　name: test
-nfs-pvc　　labels:
　　name: test
-nfs-pvc　　
spec:
　　containers:
- name: test-nfs-pvc　　image: registry:
5000/back_demon:1.0　　ports:
- name: backdemon　　containerPort:
80　　command:
- /run.sh　　volumeMounts:
- name: nfs-vol　　mountPath:
/home/laizy/test/nfs-pvc　　volumes:
- name: nfs-vol　　persistentVolumeClaim:
　　claimName: nfs
-pvc　　
[iyunv@k8s
-master pv]# kubectl exec -ti test-nfs-pvc /bin/bash　　
[iyunv@test
-nfs-pvc /]# cd /home/laizy/test/nfs-pvc/　　
[iyunv@test
-nfs-pvc nfs-pvc]# ls　　
1.out
　　
[iyunv@test-nfs-pvc nfs-pvc]# touch 2.out
　　
[iyunv@test-nfs-pvc nfs-pvc]# ls
　　
1.out  2.out
　　

在对应的远程NFS主机上看，可以看到刚刚在Pod内部生成的文件。