043.Kubernetes集群存储-共享存储

一 共享存储

1.1 共享存储作用

Kubernetes对于有状态的容器应用或者对数据需要持久化的应用,不仅需要将容器内的目录挂载到宿主机的目录或者emptyDir临时存储卷,而且需要更加可靠的存储来保存应用产生的重要数据,以便容器应用在重建之后仍然可以使用之前的数据。

1.2 共享存储资源

为了能够屏蔽底层存储实现的细节,便于使用和管理,Kubernetes从1.0版本就引入PersistentVolume(PV)和PersistentVolumeClaim(PVC)两个资源对象来实现对存储的管理子系统。
PV是对底层网络共享存储的抽象,将共享存储定义为一种“资源”,比如Node也是一种容器应用可以“消费”的资源。PV由管理员创建和配置,它与共享存储的具体实现直接相关,例如GlusterFS、iSCSI、RBD或GCE或AWS公有云提供的共享存储,通过插件式的机制完成与共享存储的对接,以供应用访问和使用。
PVC则是用户对存储资源的一个“申请”。就像Pod“消费”Node的资源一样,PVC能够“消费”PV资源。PVC可以申请特定的存储空间和访问模式。
若使用PVC“申请”到一定的存储空间仍然不能满足应用对存储设备的需求。比如通常应用程序都会对存储设备的特性和性能有不同的要求,包括读写速度、并发性能、数据冗余等更高的要求,因此Kubernetes从1.4版本开始引入了一个新的资源对象StorageClass,用于标记存储资源的特性和性能。
Kubernetes 1.6版本时,StorageClass和动态资源供应的机制得到了完善,实现了存储卷的按需创建。通过StorageClass的定义,管理员可以将存储资源定义为某种类别(Class),正如存储设备对于自身的配置描述(Profile),例如“快速存储”“慢速存储”“有数据冗余”“无数据冗余”等。用户根据StorageClass的描述就能够直观地得知各种存储资源的特性,就可以根据应用对存储资源的需求去申请存储资源。
Kubernetes从1.9版本开始引入容器存储接口Container Storage Interface(CSI)机制,目标是在Kubernetes和外部存储系统之间建立一套标准的存储管理接口,通过该接口为容器提供存储服务,类似于CRI(容器运行时接口)和CNI(容器网络接口)。

二 PV

2.1 PV详解

PV作为存储资源,主要包括存储能力、访问模式、存储类型、回收策略、后端存储类型等关键信息的设置。
示例1:如下声明的PV具有如下属性:5GiB存储空间,访问模式为ReadWriteOnce,存储类型为slow(要求在系统中已存在名为slow的StorageClass),回收策略为Recycle,并且后端存储类型为nfs(设置了NFS Server的IP地址和路径)。
[root@k8smaster01 study]# vi nfspv01.yaml
  1 apiVersion: v1
  2 kind: PersistentVolume
  3 metadata:
  4   name: pv1
  5 spec:
  6   capacity:
  7     storage: 5Gi
  8   accessModes:
  9   - ReadWriteOnce
 10   persistentVolumeReclaimPolicy: Recycle
 11   storageClassName: slow
 12   nfs:
 13     path: /tmp
 14     server: 172.17.0.2
Kubernetes主要支持的PV类型如下:
  • AWSElasticBlockStore:AWS公有云提供的ElasticBlockStore。
  • AzureFile:Azure公有云提供的File。
  • AzureDisk:Azure公有云提供的Disk。
  • CephFS:一种开源共享存储系统。
  • FC(FibreChannel):光纤存储设备。
  • FlexVolume:一种插件式的存储机制。
  • Flocker:一种开源共享存储系统。
  • GCEPersistentDisk:GCE公有云提供的PersistentDisk。
  • Glusterfs:一种开源共享存储系统。
  • HostPath:宿主机目录,仅用于单机测试。
  • iSCSI:iSCSI存储设备。
  • Local:本地存储设备,从Kubernetes1.7版本引入,到1.14版本时更新为稳定版,目前可以通过指定块(Block)设备提供LocalPV,或通过社区开发的sig-storage-local-static-provisioner插件(https://github.com/kubernetes-sigs/sigstorage-local-static-provisioner)来管理LocalPV的生命周期。
  • NFS:网络文件系统。
  • PortworxVolumes:Portworx提供的存储服务。
  • QuobyteVolumes:Quobyte提供的存储服务。
  • RBD(CephBlockDevice):Ceph块存储。
  • ScaleIOVolumes:DellEMC的存储设备。
  • StorageOS:StorageOS提供的存储服务。
  • VsphereVolume:VMWare提供的存储系统。

2.2 PV配置参数

  • 存储能力(Capacity)
描述存储设备具备的能力,目前仅支持对存储空间的设置(storage=xx),未来可能加入IOPS、吞吐率等指标的设置。
  • 存储卷模式(VolumeMode)
Kubernetes从1.13版本开始引入存储卷类型的设置(volumeMode=xxx),可选项包括Filesystem(文件系统)和Block(块设备),默认值为Filesystem。目前有以下PV类型支持块设备类型:
    • AWSElasticBlockStore
    • AzureDisk
    • FC
    • GCEPersistentDisk
    • iSCSI
    • Localvolume
    • RBD(CephBlockDevice)
    • VsphereVolume(alpha)
示例1:使用块设备的PV定义。
[root@k8smaster01 study]# vi blockpv01.yaml
  1 apiVersion: v1
  2 kind PersistentVolume
  3 metadata:
  4   name: block-pv
  5 spec:
  6   capacity:
  7     storage: 10Gi
  8   accessNodes:
  9   - ReadWriteOnce
 10   persistentVolumeReclaimPolicy: Retain
 11   volumeMode: Block
 12   fc:
 13     targetWWNs: ["50060e801049cfd1"]
 14     lun: 0
 15     readOnly: false
 16 
  • 访问模式(Access Modes)
对PV进行访问模式的设置,用于描述用户的应用对存储资源的访问权限,访问模式如下:
    • ReadWriteOnce(RWO):读写权限,并且只能被单个Node挂载。
    • ReadOnlyMany(ROX):只读权限,允许被多个Node挂载。
    • ReadWriteMany(RWX):读写权限,允许被多个Node挂载。
某些PV可能支持多种访问模式,但PV在挂载时只能使用一种访问模式,多种访问模式不能同时生效。
  • 存储类别(Class)PV
可以设定其存储的类别,通过storageClassName参数指定一个StorageClass资源对象的名称。具有特定类别的PV只能与请求了该类别的PVC进行绑定。未设定类别的PV则只能与不请求任何类别的PVC进行绑定。
  • 回收策略(ReclaimPolicy)
通过PV定义中的persistentVolumeReclaimPolicy字段进行设置,可选项保留(Retain),回收(Recycle)和删除(Delete)。
    • 保留:保留数据,需要手工处理。
    • 回收空间:简单清除文件的操作(例如执行rm-rf/thevolume/*命令)。
    • 删除:与PV相连的后端存储完成Volume的删除操作(如AWSEBS、GCEPD、AzureDisk、OpenStackCinder等设备的内部Volume清理)。
目前,只有NFS和HostPath两种类型的存储支持Recycle策略;
AWSEBS、GCEPD、Azure Disk和Cinder volumes支持Delete策略。
  • 挂载参数(MountOptions)
在将PV挂载到一个Node上时,根据后端存储的特点,可能需要设置额外的挂载参数,可以根据PV定义中的mountOptions字段进行设置。
示例2:对一个类型为gcePersistentDisk的PV设置挂载参数。
[root@k8smaster01 study]# vi gccpv01.yaml
  1 apiVersion: "v1"
  2 kind: "PersistentVolume"
  3 metadata:
  4   name: gce-disk-1
  5 spec:
  6   capacity:
  7     storage: "10Gi"
  8   accessModes:
  9   - "ReadWriteOnce"
 10   mountOptions:
 11   - hard
 12   - nolock
 13   - nfsvers=3
 14   gcePersistentDisk:
 15     fsType: "ext4"
 16     pdName: "gce-disk-1"
 17 
提示:以下PV类型支持设置挂载参数:
    • AWSElasticBlockStore
    • AzureDisk
    • AzureFile
    • CephFS
    • Cinder(OpenStackblockstorage)
    • GCEPersistentDisk
    • Glusterfs
    • NFS
    • QuobyteVolumes
    • RBD(CephBlockDevice)
    • StorageOS
    • VsphereVolume
    • iSCSI
  • 节点亲和性(NodeAffinity)
PV可以设置节点亲和性来限制只能通过某些Node访问Volume,可以在PV定义中的nodeAffinity字段进行设置。使用这些Volume的Pod将被调度到满足条件的Node上。
示例3:
[root@k8smaster01 study]# vi affpv01.yaml
  1 apiVersion: v1
  2 kind: PersistentVolume
  3 metadata:
  4   name: example-local-pv
  5 spec:
  6   capacity:
  7     storage: 5Gi
  8   accessModes:
  9   - ReadWriteOnce
 10   persistentVolumeReclaimPolicy: Delete
 11   storageClassName: local-storage
 12   local:
 13     path: /mnt/disks/ssd1
 14   nodeAffinity:
 15     required:
 16       nodeSelectorTerms:
 17       - mathExpressions:
 18         - key: kubernetes.io/hostname
 19           operator: In
 20           values:
 21           - my-node
 22 
注意:这个参数仅用于Local类型的存储卷。

三 PVC详解

3.1 PVC使用

PVC作为用户对存储资源的需求申请,主要包括存储空间请求、访问模式、PV选择条件和存储类别等信息的设置。
示例1:申明PVC,具有如下属性:申请8GiB存储空间,访问模式为ReadWriteOnce,PV选择条件为包含标签“release=stable”并且包含条件为“environment In [dev]”的标签,存储类别为“slow”(要求在系统中已存在名为slow的StorageClass)。
[root@k8smaster01 study]# vi myclaim01.yaml
  1 kind: PersistentVolumeClaim
  2 apiVersion: v1
  3 metadata:
  4   name: myclaim
  5 spec:
  6   accessModes:
  7   - ReadWriteOnce
  8   resources:
  9     requests:
 10       storage: 8Gi
 11   storageClassName: slow
 12   selector:
 13     matchLabels:
 14       release: "stable"
 15     matchExpressions:
 16     - {key: enviroment, operator: In, values: [dev] }
 17 

3.2 PVC配置详解

PVC的关键配置参数说明如下:
  • 资源请求(Resources):描述对存储资源的请求,目前仅支持request.storage的设置,即存储空间大小。
  • 访问模式(AccessModes):PVC也可以设置访问模式,用于描述用户应用对存储资源的访问权限。其三种访问模式的设置与PV的设置相同。
  • 存储卷模式(VolumeModes):PVC也可以设置存储卷模式,用于描述希望使用的PV存储卷模式,包括文件系统和块设备。
  • PV选择条件(Selector):通过对LabelSelector的设置,可使PVC对于系统中已存在的各种PV进行筛选。系统将根据标签选出合适的PV与该PVC进行绑定。选择条件可以使用matchLabels和matchExpressions进行设置,如果两个字段都设置了,则Selector的逻辑将是两组条件同时满足才能完成匹配。
  • 存储类别(Class):PVC在定义时可以设定需要的后端存储的类别(通过storageClassName字段指定),以减少对后端存储特性的详细信息的依赖。只有设置了该Class的PV才能被系统选出,并与该PVC进行绑定。PVC也可以不设置Class需求。如果storageClassName字段的值被设置为空(storageClassName=""),则表示该PVC不要求特定的Class,系统将只选择未设定Class的PV与之匹配和绑定。PVC也可以完全不设置storageClassName字段,此时将根据系统是否启用了名为DefaultStorageClass的admissioncontroller进行相应的操作。
  • 未启用DefaultStorageClass:等效于PVC设置storageClassName的值为空(storageClassName=""),即只能选择未设定Class的PV与之匹配和绑定。
  • 启用DefaultStorageClass:要求集群管理员已定义默认的StorageClass。如果在系统中不存在默认的StorageClass,则等效于不启用DefaultStorageClass的情况。如果存在默认的StorageClass,则系统将自动为PVC创建一个PV(使用默认StorageClass的后端存储),并将它们进行绑定。
提示:设置默认StorageClass的方法为,在StorageClass的定义中加上一个annotation“storageclass.kubernetes.io/isdefault-class=true”。如果将多个StorageClass都定义为default,则由于不唯一,系统将无法为PVC创建相应的PV。
注意,PVC和PV都受限于Namespace,PVC在选择PV时受到Namespace的限制,只有相同Namespace中的PV才可能与PVC绑定。Pod在引用PVC时同样受Namespace的限制,只有相同Namespace中的PVC才能挂载到Pod内。当Selector和Class都进行了设置时,系统将选择两个条件同时满足的PV与之匹配。另外,如果资源供应使用的是动态模式,即没有预先定义PV,仅通过StorageClass交给系统自动完成PV的动态创建,那么PVC再设定Selector时,系统将无法为其供应任何存储资源。
在启用动态供应模式的情况下,一旦用户删除了PVC,与之绑定的PV也将根据其默认的回收策略“Delete”被删除。如果需要保留PV(用户数据),则在动态绑定成功后,用户需要将系统自动生成PV的回收策略从“Delete”改成“Retain”。

四 PV和PVC生命周期管理

4.1 PV生命周期

某个PV在生命周期中可能处于以下4个阶段(Phaes)之一。
  • Available:可用状态,还未与某个PVC绑定。
  • Bound:已与某个PVC绑定。
  • Released:绑定的PVC已经删除,资源已释放,但没有被集群回收。
  • Failed:自动资源回收失败。

4.2 PVC生命周期

将PV看作可用的存储资源,PVC则是对存储资源的需求,PV和PVC的相互关系遵循如下所示关系:
clipboard

4.3 资源供应

Kubernetes支持两种资源的供应模式:静态模式(Static)和动态模式(Dynamic),资源供应的目的就是创建好PV。
  1. 静态模式:集群管理员手工创建许多PV,在定义PV时需要将后端存储的特性进行设置。
  2. 动态模式:集群管理员无须手工创建PV,而是通过StorageClass的设置对后端存储进行描述,标记为某种类型。此时要求PVC对存储的类型进行声明,系统将自动完成PV的创建及与PVC的绑定。
注意;PVC可以声明Class为"",说明该PVC禁止使用动态模式。

4.4 资源绑定

在用户定义好PVC之后,系统将根据PVC对存储资源的请求(存储空间和访问模式)在已存在的PV中选择一个满足PVC要求的PV,一旦找到,就将该PV与用户定义的PVC进行绑定,用户的Pod应用就可以使用这个PVC了。
如果在系统中没有满足PVC要求的PV,PVC则会无限期处于Pending状态,直到等到系统管理员创建了一个符合其要求的PV。
PV一旦绑定到某个PVC上,就会被这个PVC独占,不能再与其他PVC进行绑定了。在这种情况下,当PVC申请的存储空间比PV的少时,整个PV的空间就都能够为PVC所用,可能会造成资源的浪费。
如果资源供应使用的是动态模式,则系统在为PVC找到合适的StorageClass后,将自动创建一个PV并完成与PVC的绑定。

4.5 资源使用

Pod使用Volume的定义,将PVC挂载到容器内的某个路径进行使用。Volume的类型为persistentVolumeClaim。在容器应用挂载了一个PVC后,就能被持续独占使用。
不过,多个Pod可以挂载同一个PVC,由应用程序自身考虑多个实例共同访问一块存储空间的问题。

4.6 资源释放

当用户对存储资源使用完毕后,用户可以删除PVC,与该PVC绑定的PV将会被标记为“已释放”,但还不能立刻与其他PVC进行绑定。通过之前PVC写入的数据可能还被留在存储设备上,只有在清除之后该PV才能再次使用。

4.7 资源回收

对于PV,可以设定回收策略,用于设置与之绑定的PVC释放资源之后如何处理遗留数据的问题。只有PV的存储空间完成回收,才能供新的PVC绑定和使用。
静态资源供应模式下,PV、PVC、StorageClass及Pod使用PVC的原理释义说明:
clipboard
动态资源供应模式下,PV、PVC、StorageClass及Pod使用PVC的原理释义说明:
clipboard
提示:更多StorageClass见《044.集群存储-StorageClass》。
更多存储类型参考:https://www.cnblogs.com/Irving/p/9847060.html
posted @ 2020-03-26 12:42  木二  阅读(2517)  评论(0编辑  收藏  举报