Kubernetes PV & pvc
介绍
PersistentVolume(pv)和PersistentVolumeClaim(pvc)是k8s提供的两种API资源,用于抽象存储细节。管理员关注于如何通过pv提供存储功能而无需 关注用户如何使用,同样的用户只需要挂载pvc到容器中而不需要关注存储卷采用何种技术实现。 pvc和pv的关系与pod和node关系类似,前者消耗后者的资源。pvc可以向pv申请指定大小的存储资源并设置访问模式,这就可以通过Provision -> Claim 的方式,来对存储资源进行控制。
生命周期
pv和pvc遵循以下生命周期:
- 供应准备。通过集群外的存储系统或者云平台来提供存储持久化支持。 - 静态提供:管理员手动创建多个PV,供PVC使用。 - 动态提供:动态创建PVC特定的PV,并绑定。
- 绑定。用户创建pvc并指定需要的资源和访问模式。在找到可用pv之前,pvc会保持未绑定状态。
- 使用。用户可在pod中像volume一样使用pvc。
- 释放。用户删除pvc来回收存储资源,pv将变成“released”状态。由于还保留着之前的数据,这些数据需要根据不同的策略来处理,否则这些存储资源无法被其他pvc使用。
- 回收(Reclaiming)。pv可以设置三种回收策略:保留(Retain),回收(Recycle)和删除(Delete)。 - 保留策略:允许人工处理保留的数据。 - 删除策略:将删除pv和外部关联的存储资源,需要插件支持。 - 回收策略:将执行清除操作,之后可以被新的pvc使用,需要插件支持。
Provisioning
两种方式提供的PV资源供给:
- static
- dynamic
存储卷,成功之后再创建PersistentVolume对象,才能够在kubernetes中使用。动态卷供给能让集群管理员不必进行预先创建存储卷,而是随着用户需求
进行创建。在1.5版本提高了动态卷的弹性和可用性。
供不同的存储卷。这样的设计让集群管理员能够在同一个集群内,定义和提供不同类型的、不同参数的卷(相同或者不同的存储系统)。这样的设计还确
保了最终用户在无需了解太多的情况下,有能力选择不同的存储选项。
PV类型
pv支持以下类型:
- GCEPersistentDisk
- AWSElasticBlockStore
- NFS
- iSCSI
- RBD (Ceph Block Device)
- Glusterfs
- AzureFile
- AzureDisk
- CephFS
- cinder
- FC
- FlexVolume
- Flocker
- PhotonPersistentDisk
- Quobyte
- VsphereVolume
- HostPath (single node testing only – local storage is not supported in any way and WILL NOT WORK in a multi-node cluster)
PV属性:
- 访问模式,与pv的语义相同。在请求资源时使用特定模式。
- 资源,申请的存储资源数额。
PV卷阶段状态:
- Available – 资源尚未被claim使用
- Bound – 卷已经被绑定到claim了
- Released – claim被删除,卷处于释放状态,但未被集群回收。
- Failed – 卷自动回收失败
AwsElasticBlockServer 静态PV示例
需要满足以下条件方可使用EBS:
- Pod运行的节点必须为AWS EC2实例
- 这些示例需要和EBS在同一个区域和可用区域
- EBS只支持一个EC2挂载一个卷
- RC或者Deployment 副本集只能为1。
1. 创建PV(Persistent Volume)
$ vim ebs-pv.yaml
$ kubectl create -f ebs-pv.yaml
2. 创建PVC(Persistent Volume Claim)
$ vim nginx-pvc.yaml
$ kubectl create -f nginx-pvc.yaml
3.创建deployment服务使用pvc资源
$ vim nginx-with-pvc.yaml
kubectl create -f nginx-with-pvc.yaml
注意事项
。
- 已经被pvc绑定的pv可以被删除,删除后对应的pvc仍为Bound状态。如有pod正在使用此pvc则仍可使用。如无pod使用,则创建pod挂载此pvc时
会出现失败。
- pv可以在绑定后被编辑(如访问模式,容量),导致信息与对应的pvc不一致。