应用存储和持久化数据卷:核心知识
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小)
- 创建PV
dynamic volume provisioning
- 概念:K8s 集群中的管控组件,会结合 PVC 和 StorageClass 的信息动态,生成用户所需要的存储(PV),将 PVC 和 PV 进行绑定后,pod 就可以使用 PV 了。通过 StorageClass 配置生成存储所需要的存储模板,再结合用户的需求动态创建 PV 对象,做到按需分配。
- StorageClass:提供了一种描述存储“类”的方法,满足用户不同的服务质量级别、备份策略等
- 主要包含三个字段:Provisioner、parameters、reclaimpolicy
- Provisioner:指定配置PV的卷的类型
- 主要包含三个字段:Provisioner、parameters、reclaimpolicy
- 使用方法
- 创建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