1、持久化存储卷和声明介绍
PersistentVolume(PV)用于为用户和管理员提供如何提供和消费存储的API,PV由管理员在集群中提供的存储。它就像Node一样是集群中的一种资源。PersistentVolume 也是和存储卷一样的一种插件,但其有着自己独立的生命周期。PersistentVolumeClaim (PVC)是用户对存储的请求,类似于Pod消费Node资源,PVC消费PV资源。Pod能够请求特定的资源(CPU和内存),声明请求特定的存储大小和访问模式。PV是一个系统的资源,因此没有所属的命名空间。
2、持久化存储卷和声明的生命周期
在Kubernetes集群中,PV 作为存储资源存在。PVC 是对PV资源的请求和使用,也是对PV存储资源的”提取证”,而Pod通过PVC来使用PV。PV 和 PVC 之间的交互过程有着自己的生命周期,这个生命周期分为5个阶段:
- 供应(Provisioning):即PV的创建,可以直接创建PV(静态方式),也可以使用StorageClass动态创建
- 绑定(Binding):将PV分配给PVC
- 使用(Using):Pod通过PVC使用该Volume
- 释放(Releasing):Pod释放Volume并删除PVC
- 回收(Reclaiming):回收PV,可以保留PV以便下次使用,也可以直接从云存储中删除
根据上述的5个阶段,存储卷的存在下面的4种状态:
- Available:可用状态,处于此状态表明PV以及准备就绪了,可以被PVC使用了。
- Bound:绑定状态,表明PV已被分配给了PVC。
- Released:释放状态,表明PVC解绑PV,但还未执行回收策略。
- Failed:错误状态,表明PV发生错误。
2.1 供应(Provisioning)
供应是为集群提供可用的存储卷,在Kubernetes中有两种持久化存储卷的提供方式:静态或者动态。
2.1.1 静态(Static)
PV是由Kubernetes的集群管理员创建的,PV代表真实的存储,PV提供的这些存储对于集群中所有的用户都是可用的。它们存在于Kubernetes API中,并可被Pod作为真实存储使用。在静态供应的情况下,由集群管理员预先创建PV,开发者创建PVC和Pod,Pod通过PVC使用PV提供的存储。静态供应方式的过程如下图所示:
2.1.2 动态(Dynamic)
对于动态的提供方式,当管理员创建的静态PV都不能够匹配用户的PVC时,集群会尝试自动为PVC提供一个存储卷,这种提供方式基于StorageClass。在动态提供方向,PVC需要请求一个存储类,但此存储类必须有管理员预先创建和配置。集群管理员需要在API Server中启用DefaultStorageClass的接入控制器。动态供应过程如下图所示:
2.2 绑定
在Kubernetes中,会动态的将PVC与可用的PV的进行绑定。在kubernetes的Master中有一个控制回路,它将监控新的PVC,并为其查找匹配的PV(如果有),并把PVC和PV绑定在一起。如果一个PV曾经动态供给到了一个新的PVC,那么这个回路会一直绑定这个PV和PVC。另外,用户总是能得到它们所要求的存储,但是volume可能超过它们的请求。一旦绑定了,PVC绑定就是专属的,无论它们的绑定模式是什么。
如果没有匹配的PV,那么PVC会无限期的处于未绑定状态,一旦存在匹配的PV,PVC绑定此PV。比如,就算集群中存在很多的50G的PV,需要100G容量的PVC也不会匹配满足需求的PV。直到集群中有100G的PV时,PVC才会被绑定。PVC基于下面的条件绑定PV,如果下面的条件同时存在,则选择符合所有要求的PV进行绑定:
1)如果PVC指定了存储类,则只会绑定指定了同样存储类的PV;
2)如果PVC设置了选择器,则选择器去匹配符合的PV;
3)如果没有指定存储类和设置选取器,PVC会根据存储空间容量大小和访问模式匹配符合的PV。
2.3 使用
Pod把PVC作为卷来使用,Kubernetes集群会通过PVC查找绑定的PV,并将其挂接至Pod。对于支持多种访问方式的卷,用户在使用 PVC 作为卷时,可以指定需要的访问方式。一旦用户拥有了一个已经绑定的PVC,被绑定的PV就归该用户所有。用户能够通过在Pod的存储卷中包含的PVC,从而访问所占有的PV。
2.4释放
当用户完成对卷的使用时,就可以利用API删除PVC对象了,而且还可以重新申请。删除PVC后,对应的持久化存储卷被视为“被释放”,但这时还不能给其他的PVC使用。之前的PVC数据还保存在卷中,要根据策略来进行后续处理。
2.5 回收
PV的回收策略向集群阐述了在PVC释放卷时,应如何进行后续工作。目前可以采用三种策略:保留,回收或者删除。保留策略允许重新申请这一资源。在PVC能够支持的情况下,删除策略会同时删除卷以及AWS EBS/GCE PD或者Cinder卷中的存储内容。如果插件能够支持,回收策略会执行基础的擦除操作(rm -rf /thevolume/*),这一卷就能被重新申请了。
2.5.1 保留
保留回收策略允许手工回收资源。当PVC被删除,PV将仍然存储,存储卷被认为处于已释放的状态。但是,它对于其他的PVC是不可用的,因为以前的数据仍然保留在数据中。管理员能够通过下面的步骤手工回收存储卷:
1)删除PV:在PV被删除后,在外部设施中相关的存储资产仍然还在;
2)手工删除遗留在外部存储中的数据;
3)手工删除存储资产,如果需要重用这些存储资产,则需要创建新的PV。
2.5.2 循环
警告:此策略将会被遗弃。建议后续使用动态供应的模式。
循环回收会在存储卷上执行基本擦除命令:rm -rf /thevolume/*,使数据对于新的PVC可用。
2.5.3 删除
对于支持删除回收策略的存储卷插件,删除即会从Kubernetes中移除PV,也会从相关的外部设施中删除存储资产,例如AWS EBS, GCE PD, Azure Disk或者Cinder存储卷。
3、持久化存储卷
在Kubernetes中,PV通过各种插件进行实现,当前支持下面这些类型的插件:
- GCEPersistentDisk
- AWSElasticBlockStore
- AzureFile
- AzureDisk
- FC (Fibre Channel)
- FlexVolume
- Flocker
- NFS
- iSCSI
- RBD (Ceph Block Device)
- CephFS
- Cinder (OpenStack block storage)
- Glusterfs
- VsphereVolume
- Quobyte Volumes
- HostPath (Single node testing only – local storage is not supported in any way and WILL NOT WORK in a multi-node cluster)
- VMware Photon
- Portworx Volumes
- ScaleIO Volumes
- StorageOS
持久化存储卷的可以通过YAML配置文件进行,并指定使用哪个插件类型,下面是一个持久化存储卷的YAML配置文件。在此配置文件中要求提供5Gi的存储空间,存储模式为Filesystem ,访问模式是ReadWriteOnce,通过Recycle回收策略进行持久化存储卷的回收,指定存储类为slow,使用nfs的插件类型。需要注意的是,nfs服务需要提供存在。
代码语言:javascript复制apiVersion:v1
kind:PersistentVolume
metadata:
name:pv0003
spec:
capacity: #容量
storage:5Gi
volumeMode:Filesystem #存储卷模式
accessModes: #访问模式
- ReadWriteOnce
persistentVolumeReclaimPolicy:Recycle #持久化卷回收策略
storageClassName:slow #存储类
mountOptions: #挂接选项
- hard
- nfsvers=4.1
nfs:
path:/tmp
server:172.17.0.2
3.1 容量(Capacity)
一般来说,PV会指定存储容量。这里通过使用PV的capcity属性进行设置。目前,capcity属性仅有storage(存储大小)这唯一一个资源需要被设置。
3.2 存储卷模式(Volume Mode)
在kubernetes v1.9之前的版本,存储卷模式的默认值为filesystem,不需要指定。在v1.9版本,用户可以指定volumeMode的值,除了支持文件系统外(file system)也支持块设备(raw block devices)。volumeMode是一个可选的参数,如果不进行设定,则默认为Filesystem。
3.3 访问模式(Access Modes)
只要资源提供者支持,持久卷能够通过任何方式加载到主机上。每种存储都会有不同的能力,每个PV的访问模式也会被设置成为该卷所支持的特定模式。例如NFS能够支持多个读写客户端,但某个NFS PV可能会在服务器上以只读方式使用。每个PV都有自己的一系列的访问模式,这些访问模式取决于PV的能力。
访问模式的可选范围如下:
- ReadWriteOnce:该卷能够以读写模式被加载到一个节点上。
- ReadOnlyMany:该卷能够以只读模式加载到多个节点上。
- ReadWriteMany:该卷能够以读写模式被多个节点同时加载。
在 CLI 下,访问模式缩写为:
- RWO:ReadWriteOnce
- ROX:ReadOnlyMany
- RWX:ReadWriteMany
一个卷不论支持多少种访问模式,同时只能以一种访问模式加载。例如一个 GCEPersistentDisk既能支持ReadWriteOnce,也能支持ReadOnlyMany。
存储卷插件 | ReadWriteOnce | ReadOnlyMany | ReadWriteMany |
---|---|---|---|
AWSElasticBlockStore | ✓ | – | – |
AzureFile | ✓ | ✓ | ✓ |
AzureDisk | ✓ | – | – |
CephFS | ✓ | ✓ | ✓ |
Cinder | ✓ | – | – |
FC | ✓ | ✓ | – |
FlexVolume | ✓ | ✓ | – |
Flocker | ✓ | – | – |
GCEPersistentDisk | ✓ | ✓ | – |
Glusterfs | ✓ | ✓ | ✓ |
HostPath | ✓ | – | – |
iSCSI | ✓ | ✓ | – |
PhotonPersistentDisk | ✓ | – | – |
Quobyte | ✓ | ✓ | ✓ |
NFS | ✓ | ✓ | ✓ |
RBD | ✓ | ✓ | – |
VsphereVolume | ✓ | – | – (works when pods are collocated) |
PortworxVolume | ✓ | – | ✓ |
ScaleIO | ✓ | ✓ | – |
StorageOS | ✓ | – | – |
3.4 类(Class)
在PV中可以指定存储类,通过设置storageClassName字段进行设置。如果设置了存储类,则此PV只能被绑定到也指定了此存储类的PVC。在以前的版本中,使用注释volume.beta.kubernetes.io/storage-class字段来指定存储类,而不是storageClassName字段来指定存储类。 此注释仍然可用,但是,在将来的版本中将会被废弃。
3.5 回收策略
当前的回收策略可选值包括:
- Retain-持久化卷被释放后,需要手工进行回收操作。
- Recycle-基础擦除(“rm-rf /thevolume/*”)
- Delete-相关的存储资产,例如AWSEBS或GCE PD卷一并删除。
目前,只有NFS和HostPath支持Recycle策略,AWSEBS、GCE PD支持Delete策略。
3.6 挂接选项(Mount Options)
当持久化卷被挂接至Pod上时,管理员能够指定额外的挂接选项。但不是所有的持久化卷类型都支持挂接选项,下面的存储卷类型支持挂接选项:
- GCEPersistentDisk
- AWSElasticBlockStore
- AzureFile
- AzureDisk
- NFS
- iSCSI
- RBD (Ceph Block Device)
- CephFS
- Cinder (OpenStack block storage)
- Glusterfs
- VsphereVolume
- Quobyte Volumes
- VMware Photon
挂接选项不会进行验证,因此如果如果设置不正确,则会失败。在以前的版本中,使用volume.beta.kubernetes.io/mount-options注释指定挂接选项,而不是使用mountOptions字段。此注释仍然可用,但是在将来的版本中将会被废弃。
4、持久化卷声明
下面是一个名称为myclaim的PVC YAML配置文件,它的访问模式为ReadWriteOnce,存储卷模式是Filesystem,需要的存储空间大小为8Gi,指定的存储类为slow,并设置了标签选择器和匹配表达式。
代码语言:javascript复制kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: myclaim
spec:
accessModes: #访问模式
- ReadWriteOnce
volumeMode: Filesystem #存储卷模式
resources: #资源
requests:
storage: 8Gi
storageClassName: slow #存储类
selector: #选择器
matchLabels:
release: "stable"
matchExpressions: #匹配表达式
- {key: environment, operator: In, values: [dev]}
4.1 选择器
在PVC中,可以通过标签选择器来进一步的过滤PV。仅仅与选择器匹配的PV才会被绑定到PVC中。选择器的组成如下:
- matchLabels: 只有存在与此处的标签一样的PV才会被PVC选中;
- matchExpressions :匹配表达式由键、值和操作符组成,操作符包括In, NotIn, Exists和DoesNotExist,只有符合表达式的PV才能被选择。
如果同时设置了matchLabels和matchExpressions,则会进行求与,即只有同时满足上述匹配要求的PV才会被选择。
4.2 存储类
如果PVC使用storageClassName字段指定一个存储类,那么只有指定了同样的存储类的PV才能被绑定到PVC上。对于PVC来说,存储类并不是必须的。依赖于安装方法,可以在安装过程中使用add-on管理器将默认的StorageClass部署至Kubernetes集群中。当PVC指定了选择器,并且指定了StorageClass,则在匹配PV时,取两者之间的与:即仅仅同时满足存储类和带有要求标签值的PV才能被匹配上。
4.3 PVC作为存储卷
Pod通过使用PVC来访问存储,而PVC必须和使用它的Pod在同一个命名空间中。Pod会同一个命名空间中选择一个合适的PVC,并使用PVC为其获取存储卷,并将PV挂接到主机和Pod上。
代码语言:javascript复制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
参考资料
1.《Configure a Pod to Use a PersistentVolume for Storage》地址:https://kubernetes.io/docs/tasks/configure-pod-container/configure-persistent-volume-storage/
2.《Persistent Volumes》地址:https://kubernetes.io/docs/concepts/storage/persistent-volumes/
3.《Persistent Storage》地址:https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/persistent-storage.md
4.《PersistentVolume v1 core》地址:https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.10/#persistentvolume-v1-core