存储管理跟计算管理是两个不同的问题。理解每个存储系统是一件复杂的事情,特别是对于普通用户来说,有时并不需要关心各种存储实现,只希望能够安全可靠地存储数据。
为了简化对存储调度,K8S对存储的供应和使用做了抽象,以API形式提供给管理员和用户使用。要完成这一任务,引入了两个新的API资源:Persistent Volume(持久卷,以下简称PV)和Persistent Volume Claim(持久卷申请,以下简称PVC)。
PV是集群中的一块网络存储,跟Node一样,也是集群的资源。PV跟Volume(卷)类似,不过会有独立于Pod的生命周期。由系统管理员配置创建的一个数据卷(即PV类型),它代表了某一类存储插件实现。
PVC是用户的一个请求,跟Pod类似。Pod消费Node的资源,PVC消费PV的资源。Pod 能够申请特定的资源(CPU和内存);PVC能够申请特定的尺寸和访问模式(例如可以加载一个读写,以及多个只读实例),而无须感知后端的存储实现。.
PV类型使用插件的形式来实现。K8S现在支持以下插件:
GCEPersistentDisk
AWSElasticBlockStore
AzureFile
AzureDisk
FC (FibreChannel)
Flocker
NFS
iSCSI
RBD (CephBlock Device)
CephFS
Cinder(OpenStack block storage)
Glusterfs
VsphereVolume
QuobyteVolumes
HostPath
VMware Photon
PortworxVolumes
ScaleIOVolumes
PV是集群的资源。PVC是对这一资源的请求,也是对资源的所有权的检验。PV和PVC 之间的互动遵循如下的生命周期。
集群管理员会创建一系列的PV。这些PV包含了为集群用户提供的真实存储资源。可利用 K8S API来消费。
用户创建一个包含了容量和访问模式的PVC。Master会监听PVC的产生,并尝试根据请求内容查找匹配的PV,并把PV和PVC进行绑定。用户能够获取满足需要的资源,并且在使用过程中可能超出请求数量。
如果找不到合适的卷,这一申请就会持续处于非绑定状态,一直到出现合适的PV。例如一个集群准备了很多的50G大小的持久卷,(虽然总量足够)也是无法响应100G的申请的,除非把100G的PV加入集群。
Pod把PVC作为卷来使用。集群会通过PVC查找绑定的PV,并Mount给Pod。对于支持多种访问方式的卷,用户在使用 PVC 作为卷时,可以指定需要的访问方式。
一旦用户拥有了一个已经绑定的PVC,被绑定的PV就归该用户所有了。用户的Pods能够通过在Pod的卷中包含的PVC来访问他们占有的PV。
当用户完成对卷的使用时,就可以利用API删除PVC对象了,而且还可以重新申请。删除PVC后,对应的卷被视为“被释放”,但这时还不能给其他的PVC使用。之前的PVC数据还保存在卷中,要根据策略来进行后续处理。
PV的回收策略向集群阐述了在PVC释放卷时,应如何进行后续工作。目前可以采用三种策略:保留,回收或者删除。保留策略允许重新申请这一资源。在PVC能够支持的情况下,删除策略会同时删除卷以及AWS EBS/GCE PD或者Cinder卷中的存储内容。如果插件能够支持,回收策略会执行基础的擦除操作(rm -rf/thevolume/*),这一卷就能被重新申请了。
每个PV包含一个spec,用于描述该卷的规格和状态。
cat << EOF > pv-lykops-sfs-0.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv-lykops-sfs-0
labels:
type: nfs
app: pv
version: v1
spec:
capacity:
storage: 1Gi
accessModes:
-ReadWriteMany
persistentVolumeReclaimPolicy: Recycle
nfs:
path: /data
server: 192.168.20.128
readOnly: false
EOF
kubectl create -f pv-lykops-sfs-0.yaml
一般来说,PV会指定存储容量。这里需要使用PV的capcity属性。
目前存储大小是唯一一个能够被申请的指标。
只要资源提供者支持,持久卷能够被用任何方式加载到主机上。每种存储都会有不同的能力,每个PV的访问模式也会被设置成为该卷所支持的特定模式。例如NFS能够支持多个读写客户端,但某个NFS PV可能会在服务器上以只读方式使用。每个PV都有自己的一系列的访问模式,这些访问模式取决于PV的能力。
访问模式的可选范围如下:
ReadWriteOnce:该卷能够以读写模式被加载到一个节点上。
ReadOnlyMany:该卷能够以只读模式加载到多个节点上。
ReadWriteMany:该卷能够以读写模式被多个节点同时加载。
在 CLI 下,访问模式缩写为:
RWO:ReadWriteOnce
ROX:ReadOnlyMany
RWX:ReadWriteMany
重要!一个卷不论支持多少种访问模式,同时只能以一种访问模式加载。例如一个 GCEPersistentDisk既能支持ReadWriteOnce,也能支持ReadOnlyMany。
当前的回收策略可选值包括:
Retain-人工重新申请
Recycle-基础擦除(“rm-rf /thevolume/*”)
Delete-相关的存储资产,例如AWSEBS或GCE PD卷一并删除。
目前,只有NFS和HostPath支持Recycle策略,AWSEBS、GCE PD支持Delete策略。
一个卷会处于如下阶段之一:
Available:可用资源,尚未被绑定到PVC上
Bound:该卷已经被绑定
Released:PVC已经被删除,但该资源尚未被集群回收
Failed:该卷的自动回收过程失败。
CLI 会显示绑定到该 PV 的 PVC。
cat << EOF > pvc-lykops-sfs-0.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc-lykops-sfs-0
labels:
type: nfs
app: pvc
version: v1
spec:
accessModes:
-ReadWriteMany
resources:
requests:
storage: 1Gi
EOF
kubectl create -f pvc-lykops-sfs-0.yaml
PVC使用跟PV一致的访问模式。
PVC跟Pod一样可以请求特定数量的资源。在这里的请求内容就是存储(storage)。Resource Model 文中提到的内容对 PV 和 PVC 同样适用。
Pod能够借助PVC来访问存储。PVC必须跟Pod处于同一个命名空间。集群找到Pod命名空间中的PVC,然后利用PVC获取到PV。这个卷就会被加载到主机上,让Pod使用。
cat << EOF > lykops-sfs.yaml
apiVersion: apps/v1beta1
kind: StatefulSet
metadata:
name: lykops-sfs
labels:
software: apache
project: lykops
app: lykops-sfs
version: v1
spec:
serviceName: lykops-sfs
template:
metadata:
labels:
software: apache
project: lykops
app: lykops-sfs
version: v1
name: test-sfs
spec:
containers:
- name: lykops-sfs
image: web:apache
ports:
- containerPort: 80
name: apache
volumeMounts:
- name: pvc
mountPath: /data/
volumeClaimTemplates:
-metadata:
name: pvc
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 1Gi
EOF
kubectl create -f lykops-sfs.yaml
PVC、PV不能使用在deployment、rc、rs等场景下
如上面的例子:
通用PVC的StatefulSet:StatefulSet名称为test-sfs,卷名为pvc
PV:pv-test-sfs-{0,1}
PVC:pvc-test-sfs-{0,1}
规则如下:
PVC和PV的命名规则为:资源类型-StatefulSet名称-副本数序号(从0开始)
除了命名规则外,还需要保证访问accessModes、resources这两个一样
按照以上规则创建后,可以看到PV和PVC能关联起来