存储基础知识

Kubernetes提供了非常丰富的Volume类型，您在ACK可以使用的常用的Volume类型如下：

数据卷（Volume）使用原则

• 一个Pod可以挂载多个数据卷（Volume）。

• 一个Pod可以挂载多种类型的数据卷（Volume）。

• 每个被Pod挂载的Volume卷，可以在不同的容器间共享。

• Kubernetes环境推荐使用PVC和PV方式挂载数据卷（Volume）。

• 虽然单Pod可以挂载多个数据卷（Volume），但是并不建议给一个Pod挂载过多数据卷。

并非所有的Kubernetes数据卷（Volume）具有持久化特性，为了实现持久化的存储，容器存储需依赖于一个远程存储服务。为此Kubernetes引入了PV和PVC两个资源对象，将存储实现的细节从其如何被使用中抽象出来，并解耦存储使用者和系统管理员的职责。PV和PVC的概念如下：

• PV

  • PV是PersistentVolume的缩写，译为持久化存储卷。PV在Kubernetes中代表一个具体存储类型的卷，其对象中定义了具体存储类型和卷参数。即目标存储服务所有相关的信息都保存在PV中，Kubernetes引用PV中的存储信息执行挂载操作。

• PVC

  • PVC是PersistentVolumeClaim的缩写，译为存储声明。PVC是在Kubernetes中一种抽象的存储卷类型，代表了某个具体类型存储的数据卷表达。其设计意图是分离存储与应用编排，将存储细节抽象出来并实现存储的编排。这样Kubernetes中存储卷对象独立于应用编排而单独存在，在编排层面使应用和存储解耦。

PV和PVC使用说明

• PVC和PV的绑定

  PVC与PV是一一对应关系，不能一个PVC挂载多个PV，也不能一个PV挂载多个PVC。为应用配置存储时，需要声明一个存储需求声明（PVC），而Kubernetes会通过最佳匹配的方式选择一个满足PVC需求的PV，并与之绑定。所以从职责上PVC是应用所需要的存储对象，属于应用作用域。PV是存储平面的存储对象，属于整个存储域。

  PVC只有绑定了PV之后才能被Pod使用，而PVC绑定PV的过程即是消费PV的过程，这个过程是有一定规则的，以下规则都满足的PV才能被PVC绑定：

  • VolumeMode：被消费PV的VolumeMode需要和PVC一致。

  • AccessMode：被消费PV的AccessMode需要和PVC一致。

  • StorageClassName：如果PVC定义了此参数，PV必须有相关的参数定义才能进行绑定。

  • LabelSelector：通过标签（labels）匹配的方式从PV列表中选择合适的PV绑定。

  • Size：被消费PV的capacity必须大于或者等于PVC的存储容量需求才能被绑定。

• PV和PVC定义中的size字段

  PVC和PV里面的size字段作用如下：

  • PVC、PV绑定时，会根据各自的size进行筛选。

  • 通过PVC、StorageClass动态创建PV时，有些存储类型会参考PVC的size创建相应大小的PV和后端存储。

  • 对于支持Resize操作的存储类型，PVC的size作为扩容后PV、后端存储的容量值。

  一个PVC、PV的size值只是在执行一些PVC和PV管控操作的时候，作为配置参数来使用。

  真正的存储卷数据流写数据的时候，不会参考PVC和PV的size字段，而是依赖底层存储介质的实际容量。

常见的容器存储数据卷使用方式如下：

• 静态存储卷

  静态存储卷一般是指由管理员创建的PV。所有的数据卷（Volume）都支持创建静态存储卷。

  静态存储卷先由集群管理员分析集群中存储需求，并预先分配一些存储介质（例如云盘、NAS盘等），同时创建对应的PV对象。创建好的PV对象等待PVC来消费。如果负载中定义了PVC需求，Kubernetes会通过相关规则实现PVC和匹配的PV进行绑定，这样就实现了应用对存储服务的访问能力。

• 动态存储卷

  动态存储卷一般是指通过存储插件自动创建的PV。

  动态卷一般由集群管理员配置好后端的存储池，并创建相应的模板（StorageClass），当有PVC需要消费PV的时候，根据PVC定义的需求，并参考StorageClass的存储细节，由存储插件动态创建一个PV。StorageClass的定义如下：

  • StorageClass

    当您声明一个PVC时，如果在PVC中添加了StorageClassName字段，意味着当PVC在集群中找不到匹配的PV时，会根据StorageClassName的定义触发相应的Provisioner插件创建合适的PV供绑定，即创建动态数据卷。

    动态数据卷由Provisioner插件创建，并通过StorageClassName与PVC进行关联。

    StorageClass可译为存储类，表示为一个创建PV存储卷的模板。在PVC触发自动创建PV的过程中，即使用StorageClass对象中的内容进行创建。其内容如下：

    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
      name: alicloud-disk-topology
    parameters:
      type: cloud_ssd
    provisioner: diskplugin.csi.alibabacloud.com
    reclaimPolicy: Delete
    allowVolumeExpansion: true
    volumeBindingMode: WaitForFirstConsumer

    参数	描述
    reclaimPolicy	用来指定创建PV的persistentVolumeReclaimPolicy字段值，支持Delete和Retain。 Delete表示动态创建的PV，在销毁的时候也会自动销毁。 Retain表示动态创建的PV，不会自动销毁，而是由管理员处理。
    allowVolumeExpansion	定义由此存储类创建的PV是否运行动态扩容，默认为false。是否能动态扩容是由底层存储插件来实现的，这里只是一个开关。
    volumeBindingMode	表示动态创建PV的时间，支持Immediate和WaitForFirstConsumer，分别表示立即创建和延迟创建。

  • 延迟绑定

    针对某类存储（例如阿里云云盘）在挂载属性上有所限制，只能挂载相同可用区的数据卷和节点，不在同一个可用区不可以挂载。这种类型的存储卷通常遇到如下问题：

    • 创建了A可用区的数据卷，但是A可用区的节点资源已经耗光，导致Pod启动无法完成挂载。

    • 集群管理员在规划PVC、PV的时候不能确定在哪些可用区创建多个PV来备用。

    StorageClass中的volumeBindingMode字段正是用来解决此问题，如果将volumeBindingMode配置为WaitForFirstConsumer值，则表示存储插件在收到PVC Pending的时候不会立即进行数据卷创建，而是等待这个PVC被Pod消费的时候才执行创建流程。

    说明

    延迟绑定实现原理如下：

    Provisioner在收到PVC Pending状态的时候不会立即进行数据卷创建，而是等待这个PVC被Pod消费。如果有Pod消费此PVC，调度器发现PVC是延迟绑定模式，则继续完成调度功能，且调度器会将调度结果通过patch命令写入PVC的metadata中。当Provisioner发现PVC中写入了调度信息时，会根据调度信息获取创建目标数据卷的位置信息（区域和节点信息），并触发PV的创建流程。

    在多可用区集群环境中，更推荐使用延迟绑定的动态卷方案，目前阿里云ACK集群已经支持上述配置方案。

  动态存储卷的优势

  • 动态存储卷让Kubernetes实现了PV的自动化生命周期管理，PV的创建、删除都通过Provisioner完成。

  • 自动化创建PV对象，减少了配置复杂度和系统管理员的工作量。

  • 动态卷可以实现PVC对存储的需求容量和Provisioner输出的PV容量一致，实现存储容量规划最优。

• 挂载SubPath卷

  Kubernetes提供了volumeMounts.subPath属性配置，可用于指定所引用的卷内的子路径，而不是其根路径。

  说明

  SubPath在Kubernetes的一些版本中存在挂载、卸载不充分的问题，故不建议使用。如果您想要挂载卷的子目录（如NAS、OSS子目录），可以通过阿里云存储CSI原生支持的能力进行挂载。