应用存储和持久化数据卷:核心知识

Posted 果子哥丶

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了应用存储和持久化数据卷:核心知识相关的知识,希望对你有一定的参考价值。

1、Pod Volumes

  • 场景
    • 同一个pod中的某个容器异常退出,kubelet重新拉起来,保证容器之前产生数据没丢
    • 同一个pod的多个容器共享数据
  • 常见类型
    • 本地存储,常用的有 emptydir/hostpath;
    • 网络存储:网络存储当前的实现方式有两种,一种是 in-tree,它的实现的代码是放在 K8s 代码仓库中的,随着k8s对存储类型支持的增多,这种方式会给k8s本身的维护和发展带来很大的负担;而第二种实现方式是 out-of-tree,它的实现其实是给 K8s 本身解耦的,通过抽象接口将不同存储的driver实现从k8s代码仓库中剥离,因此out-of-tree 是后面社区主推的一种实现网络存储插件的方式;
    • Projected Volumes:它其实是将一些配置信息,如 secret/configmap 用卷的形式挂载在容器中,让容器中的程序可以通过POSIX接口来访问配置数据;
  • 使用举例
  • 在多个容器共享同一个卷的时候,为了隔离数据,通过 subPath 来完成这个操作。它会在卷里面建立两个子目录,容器 1 往 cache 下面写的数据其实都写在子目录 cache1 了,容器 2 往 cache 写的目录,其数据最终会落在这个卷里子目录下面的 cache2 下。
  • readOnly 的意思其实就是只读挂载
  • emptyDir 其实是在 pod 创建的过程中会临时创建的一个目录,这个目录随着 pod 删除也会被删除,里面的数据会被清空掉;
  • hostPath 是宿主机上的一个路径,在 pod 删除之后,这个目录还是存在的,它的数据也不会被丢失。

2、Persistent Volumes

  • 存储和计算分离,解耦合pod和volume之间的生命周期的关联
  • yaml文件
    • Capacity:存储对象的大小;
    • AccessModes:使用这个 PV 的方式。它有三种使用方式。
      • ReadWriteOnce 单 node 读写访问;
      • ReadOnlyMany 多个 node 只读访问,是常见的一种数据的共享方式;
      • ReadWriteMany 多个 node 上读写访问。
    • ReclaimPolicy:
      • delete,也就是说 PVC 被删除之后,PV 也会被删除;
      • Retain,就是保留,后面这个 PV 需要管理员来手动处理。
    • StorageClassName:动态 Provisioning 时必须指定的一个字段,指定到底用哪一个模板文件来生成 PV ;
    • NodeAffinity:能被哪些 node 去挂载使用pod 必须要调度到这些能访问 PV 的 node 上,才能使用这块 PV,之后存储拓扑调度会细讲。

3、Persistent Volume Claim

  • 特点
    • PVC是面向对象编程中抽象出来的接口,PV是接口对应的实现
    • 通过kube-controller-manager中的PersistentVolumeController将PVC和PV绑定到一起
    • PVC中声明需要存储的size、access mode(单node还是多node,只读还是可读可写)等
    • 更容易控制安全访问策略
  • 如何匹配PV:用户在提交 PVC 的时候,最重要的两个字段 —— Capacity 和 AccessModes。在提交 PVC 后,k8s 集群中的相关组件是如何去找到合适的 PV 呢?首先它是通过为 PV 建立的 AccessModes 索引找到所有能够满足用户的 PVC 里面的 AccessModes 要求的 PV list,然后根据PVC的 Capacity,StorageClassName, Label Selector 进一步筛选 PV,如果满足条件的 PV 有多个,选择 PV 的 size 最小的,accessmodes 列表最短的 PV,也即最小适合原则。

4、volume Provisioning

static volume Provisioning

  • 概念:先预分配一些存储,即预先创建一些 PV;然后用户提交自己的存储需求(也就是 PVC),k8s 内部相关组件会将 PVC 和 PV 做绑定;之后用户再通过 pod 去使用存储,可通过 PVC 找到相应的 PV。
  • 使用举例
    • 创建PV
    • 创建PVC
    • 各方面符合要求的PVC才能和PV进行绑定(accessModes、storageClassName、volumeMode相同,storage可以比PV小)

dynamic volume provisioning

  • 概念:K8s 集群中的管控组件,会结合 PVC 和 StorageClass 的信息动态,生成用户所需要的存储(PV),将 PVC 和 PV 进行绑定后,pod 就可以使用 PV 了。通过 StorageClass 配置生成存储所需要的存储模板,再结合用户的需求动态创建 PV 对象,做到按需分配。
  • StorageClass:提供了一种描述存储“类”的方法,满足用户不同的服务质量级别、备份策略等
    • 主要包含三个字段:Provisioner、parameters、reclaimpolicy
      • Provisioner:指定配置PV的卷的类型
  • 使用方法
    • 创建PV的模板StorageClass
    • 创建PVC文件,增加一个字段StorageClassName
    • Pod使用该PVC,通过persistentVolumeClaim.claimName

PV的状态流转

  • 当用户在使用完 PVC,将其删除后,这个 PV 就处在 released 状态
  • 当 PV 已经处在 released 状态下,它是没有办法直接回到 available 状态,无法被一个新的 PVC 去做绑定。解决方案:
    • 举例:K8s中的 StatefulSet 管理的 Pod 带存储的迁移。原理:在删除 pod 之后,不要去删除 PVC 对象,这样给 PV 绑定的 PVC 还是存在的,下次 pod 使用的时候,就可以直接通过 PVC 去复用。
    • 新建一个 PV 对象,之前的 released 的 PV 的相关字段的信息填到新的 PV 对象里面,这样的话,这个 PV 就可以结合新的 PVC 了。

5、架构设计

  • csi :container storage interface,两部分组成

    • k8s社区实现:csi-provisioner 和csi-attacher controller
    • 云存储厂商实现:对接云存储厂商的 OpenApi,主要是实现真正的 create/delete/mount/unmount 存储的相关操作,csi-controller-server和csi-node-server。
  • Pod使用PV:

    • 用户在提交 PVC yaml 的时候,首先会在集群中生成一个 PVC 对象,然后 PVC 对象会被 csi-provisioner controller watch到,csi-provisioner 会结合 PVC 对象以及 PVC 对象中声明的 storageClass,通过 GRPC 调用 csi-controller-server,然后,到云存储服务这边去创建真正的存储,并最终创建出来 PV 对象。由集群中的 PV controller 将 PVC 和 PV 对象做 bound 之后,这个 PV 就可以被使用了。
    • 提交 pod 之后,首先会被调度器调度选中某一个合适的node,之后该 node 上面的 kubelet 在创建 pod 流程中会通过首先 csi-node-server 将我们之前创建的 PV 挂载到我们 pod 可以使用的路径,然后 kubelet 开始 create && start pod 中的所有 container。
  • 通过csi使用存储的主要流程

  • 第一个阶段(Create阶段):用户提交完 PVC,由 csi-provisioner 创建存储,并生成 PV 对象,之后 PV controller 将 PVC 及生成的 PV 对象做 bound,bound 之后,create 阶段就完成了;

  • 第二个阶段(attach阶段):之后用户在提交 pod yaml 的时候,首先会被调度选中某一个 合适的node,等 pod 的运行 node 被选出来之后,会被 AD Controller watch 到 pod 选中的 node,它会去查找 pod 中使用了哪些 PV。然后它会生成一个内部的对象叫 VolumeAttachment 对象,从而去触发 csi-attacher去调用csi-controller-server 去做真正的 attache 操作,attach操作调到云存储厂商OpenAPI。这个 attach 操作就是将存储 attach到 pod 将会运行的 node 上面;

  • 第三个阶段(mount阶段):第三个阶段 发生在kubelet 创建 pod的过程中,它在创建 pod 的过程中,首先要去做一个 mount,这里的 mount 操作是为了将已经attach到这个 node 上面那块盘,进一步 mount 到 pod 可以使用的一个具体路径,之后 kubelet 才开始创建并启动容器。

6、应用存储和持久化数据卷:存储快照和拓扑调度

存储快照

  • k8s通过csi snapshotter controller实现存储快照
  • 流程:用户通过volumesnapshot对象来声明,指定volumesnapshotclass对象,然后集群中的controller生产volumesnapshotcontent

利用存储快照恢复数据

  • 通过yaml文件,将.spec.dataSource指定为VolumeSnapshot对象,然后根据pvc生成pv,数据通过volumesnapshotcontent恢复。

拓扑

  • 基本概念:管理的nodes划分的一种位置关系
    • region:标记nodes属于哪个地区
    • zone:available zone,标识跨zone的nodes属于哪个可用区
    • hostname:单机维度

存储拓扑调度

  • k8s创建pod的流程和创建pv的流程,并行独立
    • 需要保障pod最后运行的node,可以访问到存储
  • 解决方案
    • pod调度结果出来后,根据pod的拓扑动态创建pv
    • kube-scheduler为pod选择node节点时,需要考虑pv的nodeAffinity

具体例子1

  • 当用户开始提交 PVC 的时候,pv controller 在看到这个 pvc 的时候,它会找到相应的 storageClass,发现这个 BindingMode 是延迟绑定,它就不会做任何事情。
  • 之后当真正使用这个 pvc 的 pod,在调度的时候,当它恰好调度在符合 pv nodeaffinity 的 node 的上面后,这个 pod 里面所使用的 PVC 才会真正地与 PV 做绑定,这样就保证我 pod 调度到这台 node 上之后,这个 PVC 才与这个 PV 绑定,最终保证的是创建出来的 pod 能访问这块 Local PV

具体例子2

  • 在动态创建 PV 的时候,创建出来的 PV 必须是在这个可用区可以访问的;
  • 因为声明的是延迟绑定,那调度器在发现使用它的 PVC 正好对应的是该 storageclass 的时候,调度 pod 就要选择位于该可用区的 nodes。

相关命令

  • kubectl get volumesnapcontent
  • storageclass 指定BindingMode 为 WaitForFirstConsumer

csi如何实现存储扩展

  • K8s 社区推动实现的 csi controller 部分,也就是这里的 csi-snapshottor controller 以及 csi-provisioner controller,这些主要是通用的 controller 部分;
  • 由特定的云存储厂商用自身 OpenAPI 实现的不同的 csi-plugin 部分,也叫存储的 driver 部分。

以上是关于应用存储和持久化数据卷:核心知识的主要内容,如果未能解决你的问题,请参考以下文章

云原生 | kubernetes 资源对象 - 持久化存储PV,PVC

剑指企业级云原生,阿里云 CNFS 如何破局容器持久化存储困境

『 云原生·Docker』Docker存储

[云原生之DockerDocker容器的存储与迁移

docker知识总结

NeonIO 云原生存储简介与应用