Kubernetes PV/PV/Storagelass

一、Volume 共享存储原理

Kubernetes对于有状态的容器应用或者对数据需要持久化的应用,不仅需要将容器内的目录挂载到宿主机的目录或者emptyDir临时存储卷,而且需要更加可靠的存储来保存应用产生的重要数据,以便容器应用在重建之后,仍然可以使用之前的数据。不过,存储资源和计算资源(PU/内存)的管理方式完全不同。 为了能够屏蔽底层存储实现的细节,让用户方便使用,同时能让管理员方便管理,Kubernetes从v1.0版本就引入了PersistentVolume和PersistentVolumelain两个资源对象来实现对存储的管理子系统

Persisten Volume (PV)是对底层网络存储的抽象,将共享存储定义为一种“资源”,比如节点(Node)也是一种容器应用可以“消费”的资源。PV由管理员进行创建和配置,它与共享存储的具体实现直接相关,例如GlusterFs、iSSI、RBD或GE/AWS公有云提供的共享存储,通过插件式的机制完成与共享存储的对接,以供应用访问和使用

PersistentVolumelaim (PV)则是用户对于存储资源的一个“申请”。就像Pod “消费” Node的资源是一样的,PV会消费PV的资源。PV可以申请特定的存储空间和访问模式。

使用PV“申请”到一定的存储空间仍然不足以满足应用对于存储设备的各种需求。通常应用程序都会对存储设备的特性和性能有不同的要求,包括读写速度、并发性能、数据冗余等更高的要求。

二、PV详解

PV

Volume是定义在Pod上的,属于"计算资源"的一部分,而实际上"网络存储"是相对独立于"计算资源"而存在的一种实体资源

PV(Persistent Volume简称)可以理解成Kubernetes集群中的某个网络存储中对应的一块存储,与Volume相似

1.PV只是网络存储,不属于任何Node,但可以在每个Node上访问 2.PV并不是定义在Pod上,而是独立于Pod之外的定义 3.PV目前支持的类型包括:gcePersistentDisk、AWSElasticBlockStore、AzureFile、AzureDisk、F(Fibre hannel)、Flocker、NFS、iSSI、RBD(Rados Block Device)、ephFS、inder、GlusterFS、VsphereVolume、Quobyte Volumes、VMware Photon、Portworx Volume、ScaleI Volume和HostPath

命名规则及参数解释

使用NFS类型PV定义yaml,声明了需要5Gi的存储空间

  apiVersion: v1
  kind: PersistentVolume
  metadata:
    name: pv0001
  spec:
    capacity:
      storage: 5Gi
    accessModes:
      - ReadWritence
    nfs:
      path: /tmp
      server: 172.17.0.2


nfs.path 设置了挂载点
nfs.server 指定nfs地址

PV作为存储资源,主要包括存储能力、访问模式、存储类型、回收策略、后端存储类型等关键信息的设置。

例子:使用NFS存储 (PV配置)

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

参数解释:

参数 说明
metadata:name 设置pv名称
spec:capacity:storage 设置存储空间
spec:accessModes 访问模式
storagelassName 存储类别,通过storagelassName参数定义一个资源对象的名称。具有特定类型的PV只能与请求了该类别的PV,未设置类别的PV则只能与不请求任何类别的PV绑定
persistentVolumeReclaimPolicy 回收策略(Reclaim Policy 详细下面)
nfs NFS相关配置

回收策略 (Reclaim Policy) 目前支持如下三种回收策略

  • 保留 (Retain) 保留数据,需要手工处理
  • 回收空间 (Recycle) 简单清除文件的操作 (例如执行rm -rf /abcdocker/* 命令)
  • 删除 (Delete) 与PV相连的后端存储完成volume的删除操作 (如AWS EBS、GE PD、Azure Disk、penstack inder等设备的内部volume清理)

目前,只有NFS和HostPath两种类型的存储支持"Recycle"策略;AWS EBS、GE PD、Azure Disk和inder volume支持"Delete"策略

Kubernetes 支持的PV类型如下

  • geePersistentDisk:GE公有云提供的PersistentDisk
  • AWSElasticBlockStore:AWS公有云提供的ElasticBlockStore
  • AzureFile:Azure公有云提供的File
  • AzureDisk:Azure公有云提供的Disk
  • F (Fibre hannel)
  • Flocker
  • NFS:网络问卷存储
  • iSSI
  • RBD (Rados Block Device):eph块存储
  • ephFs
  • inder:penstack inder块存储
  • GlusterFS
  • Vsphere Volume
  • Quobyte Volume
  • Vmware Photon
  • Portworx Volumes
  • ScaleI Volumes
  • HostPath:宿主机目录,仅用于单机测试 每种存储类型都有各自的特点,在使用时需要根据他们各自的参数进行设置

Access Modes(访问模式)

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

访问模式的可选范围如下:

  • [x] ReadWritence:该卷能够以读写模式被加载到一个节点(单Node)上。
  • [x] ReadnlyMany:该卷能够以只读模式加载到多个节点(多Node)上。
  • [x] ReadWriteMany:该卷能够以读写模式被多个节点(Node)同时加载。

在 LI 下,访问模式缩写为:

RW:ReadWritence
RX:ReadnlyMany
RWX:ReadWriteMany

重要!一个卷不论支持多少种访问模式,同时只能以一种访问模式加载。例如一个 GEPersistentDisk 既能支持 ReadWritence ,也能支持 ReadnlyMany。

PV常见状态

1.Available :空闲状态 2.Bound:已经绑定到某个PV 3.Released:对应的PV已经删除,但资源还没有被集群收回 4.Failed:PV自动回收失败


三、PV详解

PersistentVolumelaim (PV) 是用户的一个请求。他跟 Pod 类似。Pod 消费 Node 的资源,PV 消费 PV 的资源。Pod 能够申请特定的资源(PU 和 内存);laim 能够请求特定的尺寸和访问模式(例如可以加载一个读写,以及多个只读实例)

如果某个Pod想申请某种类型的PV,则需要定义一个PersistentVolumelaim(VPS)

PV作为用户对存储资源的需求申请,主要包括存储空间请求、访问模式、PV选择条件和存储类别等信息的设置。

3.1 PV命名规则

kind: PersistentVolumelaim
apiVersion: v1
metadata:
  name: myclaim
spec:
  accessModes:
    - ReadWritence
  resources:
    requests:
      storage: 8Gi

在Pod的Volume中引用PV即可

kind: Pod
apiVersion: v1
metadata:
  name: mypod
spec:
  containers:
    - name: myfrontend
      image: dockerfile/nginx
      volumeMounts:            #####Volume配置
      - mountPath: "/var/www/html"
        name: mypd
  volumes:
    - name: mypd
      persistentVolumelaim: ##########<<引用地方
        claimName: myclaim   ##########<<引用

PV例子演示

kind: PersistentVolumelaim
apiVersion: v1
metadata:
  name: pvc0001
spec:
  accessModes:
    - ReadWritence
  resources:
    requests:
      storage: 5Gi
  storagelassName: slow
  selector:
    matchLabels:
      release: "stable"
    matchExpressions:
      - {key: evironment, operator: In, values: [dev]}

针对PV参数解释

参数 说明
resources 资源请求(Resources)描述对存储资源的请求,目前仅支持request.storage的设置,即存储空间大小
AccessMode 访问模式(Access Modes)PV也可以设置访问模式,用于描述用户应用对存储资源的访问权限。与PV三种模式相同
Selector PV选择条件(Selector)通过Label Selector的设置,可使PV对于系统中已存在的各种PV进行筛选。系统将根据标签选择出合适的PV与该PV进行绑定。选择条件可以使用matchLabels和matchExpressions进行设置。如果两个字段都设置了,则Selector的逻辑将是两组条件同时满足才能完成匹配
lass 存储类别(lass) PV在定义时可以设定需要的后端存储的类别(通过storagelassName字段指定)以降低对后端存储特性的详细信息的依赖。只有设置了该lass的PV才能被系统选出,并与该PV进行绑定

PV也可以不设置lass需求。如果storagelassName字段的值被设置为空(storagelassName=""),则表示该PV不要求特定的lass,系统将只选择未设定lass的PV与之匹配和绑定。PV也可以完全不设置storagelassName字段,此时将根据系统是否启用了名为"DefaultStoragelass"的admission controller进行相应的操作

  • 未启用 DefaultStoragelass:等效于PV设置storagelassName的值为空(storagelassName="")即只能选择未设定lass的PV与之匹配和绑定
  • 启用 DefaultStoragelass:要求集群管理员已定义默认的Storagelass。如果系统中不存在默认的Storagelass,则等效于不启用DefaultStoragelass,则系统将自动为PV创建一个PV(使用默认Storagelass的后端存储),并将它们进行绑定。集群管理员设置Storagelass的方法为,在Storagelass的定义中加上一个annotation "storageclass.kubernetes.io/is-default-class=true"。如果管理员将多个Storagelass都定义为default,则由于不唯一,系统将无法为PV创建相应的PV

小结

  1. 注意,PV和PV都受限于namespace,PV在选择PV时收到namespace的限制,只有相同的namespace中的PV才可能与PV绑定。Pod在引用PV时同样受namespace的限制,只有相同namespace中的PV才能挂载到Pod内

  2. 当Selector和lass都进行了设置时,系统将选择两个条件同时满足的PV与之匹配。

  3. 另外资源供应使用的是动态模式,即管理员没有预先定义PV,仅通过Storagelass交给系统自动完成PV的动态创建,那么PV再设置Selector时,系统将无法为其供应任何存储资源了。

  4. 在启动动态供应模式的情况下,一旦用户删除了PV,与之绑定的PV将会根据其默认的回收策略"Delete"也会被删除。如果需要保留PV (用户数据),则在动态绑定成功后,用户需要将系统自动生成的回收策略从"Dekete" 改成"Retain"

四、PV和PV的生命周期

PV可以看作可用的存储资源,PV则是对存储资源的需求,PV和PV的互相关系遵循如下图 -w794

1.资源供应 (Provisioning) Kubernetes支持两种资源的供应模式:静态模式(Staic)和动态模式(Dynamic)。资源供应的结果就是创建好的PV。

  • 静态模式:集群管理员手工创建许多PV,在定义PV时需要将后端存储的特性进行设置
  • 动态模式:集群管理员无须手工创建PV,而是通过Storagelass的设置对后端存储进行描述,标记为某种 "类型(lass)"。此时要求PV对存储的类型进行声明,系统将自动完成PV的创建及PV的绑定。PV可以声明lass为"",说明该PV禁止使用动态模式

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

3.资源使用 (Using) Pod 使用volume的定义,将PV挂载到容器内的某个路径进行使用。volume的类型为persistentVoulumelaim,在容器应用挂载了一个PV后,就能被持续独占使用。不过,多个Pod可以挂载同一个PV,应用程序需要考虑多个实例共同访问一块存储空间的问题

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

5.资源回收 (Reclaiming) 对于PV,管理员可以设定回收策略(Reclaim Policy)用于设置与之绑定的PV释放资源之后,对于遗留数据如何处理。只有PV的存储空间完成回收,才能供新的PV绑定和使用。

1.静态资源下,通过PV和PV完成绑定,并供Pod使用的存储管理机制 5E6A527BE39D4863E692A0456673F15F

2.动态资源下,通过Storagelass和PV完成资源动态绑定 (系统自动生成PV,并供Pod使用的存储管理机制) -w1059

五、Storagelass

Kubernetes从v1.4版本开始引入了一个新的资源对象Storagelass,用于标记存储资源的特性和性能。到v1.6版本时,Storagelass和动态资源供应的机制得到了完善,实现了存储卷的按需创建,在共享存储的自动化管理进程中能够实现了重要的一步。

通过Storagelass的定义,管理员可以将存储资源定义为某种类别(lass),正如存储设备对于自身的配置描述(Profile),例如 "快速存储" "慢速存储" "有数据冗余" "无数据冗余"等。用户根据Storagelass的描述就能够直观得知各种存储资源的特性,就可以根据应用对存储资源的需求去申请存储资源了。

Storagelass作为对存储资源的抽象定义,对用户设置的PV申请屏蔽后端的细节,一方面减轻用户对于存储资源细节的关注,另一方面也减轻了管理员手工管理PV的工作,由系统自动完成PV的创建和绑定,实现了动态的资源供应。使用基于Storagelass的动态资源供应模式将逐步成为云平台的标准存储配置模式

Storagelass的定义主要包括名称、后端存储的提供者(Provisioner)和后端存储的相关参数配置。Storagelass一旦被创建出来,将无法修改。如需修改,则只能删除原Storagelass的定义重建。

例子演示 我们定义了一个名为test-storageclass,提供者为rbd -w810

Storagelass 对象支持多种类型的存储卷插件来提供 PV,从 Storage lasses 官方文档 provisioner 部分可以看到,它目前支持很多种存储卷类型,其中就有我们熟悉的 eph RBD 类型。

AWSElasticBlockStore
AzureFile
AzureDisk
inder
Flocker
GEPersistentDisk
Glusterfs
PhotonPersistentDisk
Quobyte
RBD
VsphereVolume
PortworxVolume
ScaleI
StorageS

针对上述配置文件,我们对provisioner进行解释

  • 提供者 (Provisioner) 描述存储资源的提供者,也可以看作后端存储驱动。目前Kubernetes支持的Porvisioner都以kubernetes.io开头,也可以自定义后端存储提供者。
  • 参数 (Parameters) 后端存储资源提供者的参数设置,不同的Provisioner包括不同的参数设置。某些参数可以不显示设定,Provisioner将使用其默认值

PV生命周期的各个阶段 (Phase) 某个PV在生命周期中,可能处于以下四个阶段之一

  • Availablie:可用状态,还未与某个PV绑定
  • Bound:已与某个PV绑定
  • Released:绑定的PV已经删除,资源已释放,但没有被集群回收
  • Failed:自动资源回收失败
Copyright © i4t.com 2019 all right reserved,powered by Gitbook该文件修订时间: 2019-04-26 21:31:27

results matching ""

    No results matching ""