Volumes 介绍
Pod Volumes
-
场景一:如果 pod 中的某一个容器在运行时异常退出,被 kubelet 重新拉起之后,如何保证之前容器产生的重要数据没有丢失?
-
场景二:如果同一个 pod 中的多个容器想要共享数据,应该如何去做?
有状态的容器,就需要卷。
根据使用场景,临时文件直接用 host 的形式存到宿主机,非;临时的可以往云盘里存,例如分布式存储系统 CephFS。
Ceph 文件系统或 CephFS 是一个兼容 POSIX 的文件系统,它构建在 Ceph 的分布式对象存储 RADOS 之上。CephFS 致力于为各种应用程序提供最新,多用途,高可用性和高性能的文件存储,包括传统用例(如共享主目录,HPC 暂存空间和分布式工作流共享存储)。
Pod Volumes 的常见类型
-
本地存储,常用的有 emptydir/hostpath;
一个是不指定宿主机目录,交给容器来管理
另一个时指定宿主机目录
-
网络存储:网络存储当前的实现方式有两种
-
Projected Volumes:它其实是将一些配置信息,如 secret/configmap 用卷的形式挂载在容器中,让容器中的程序可以通过POSIX接口来访问配置数据;
Pod Volumes 存在的问题
pod 中声明的 volume 生命周期与 pod 是相同的,以下有几种常见的场景:
-
场景一:pod 重建销毁,如用 Deployment 管理的 pod,在做镜像升级的过程中,新旧 pod 之间如何复用数据?
-
场景二:宿主机宕机的时候,要把上面的 pod 迁移,这个时候 StatefulSet 管理的 pod,其实已经实现了带卷迁移的语义。这时通过 Pod Volumes 显然是做不到的;
宿主机 crash 了,pod 也没了,pod volumes 肯定不存在了
-
场景三:多个 pod 之间,如果想要共享数据,应该如何去声明呢?我们知道,同一个 pod 中多个容器想共享数据,可以借助 Pod Volumes 来解决;当多个 pod 想共享数据时,Pod Volumes 就很难去表达这种语义;
不同场景使用不同级别的资源
-
场景四:如果要想对数据卷做一些功能扩展性,如:snapshot、resize 这些功能,又应该如何去做呢?
Pod Volumes 使用
- subPath:多个容器共享一个卷时,用于隔离数据
Persistent Volumes(PV)
-
将存储和计算分离,通过不同的组件来管理存储资源和计算资源
计算是指动态提供需要的资源,例如新建一个 pod 需要 10g 临时存储,就需要计算哪个存储能提供这个需求。
-
解耦 pod 和 Volume 之间生命周期的关联
PV 状态扭转
当用户在使用完 PVC,将其删除后,这个 PV 就处在 released 状态,这时通过 ReclaimPolicy 决定删除还是保留。
但是即使保留也不能复用这个 PV,因为 PV 已经处在 released 状态下,它是没有办法直接回到 available 状态,也就是说接下来无法被一个新的 PVC 去做绑定。
- 第一种方式:我们可以新建一个 PV 对象,然后把之前的 released 的 PV 的相关字段的信息填到新的 PV 对象里面,这样的话,这个 PV 就可以结合新的 PVC 了;
- 第二种是我们在删除 pod 之后,不要去删除 PVC 对象,这样给 PV 绑定的 PVC 还是存在的,下次 pod 使用的时候,就可以直接通过 PVC 去复用。K8s中的 StatefulSet 管理的 Pod 带存储的迁移就是通过这种方式。
PersistentVolumnClaim(PVC) 设计意图
- 职责拆分,用户在 PVC 里声明需要的存储
- PVC 简化用户对存储的需求,通过 kube-controller-manager 中的 PersistentVolumeController 将 PVC 与合适的 PV bound 在一起,从而满足用户对存储的实际需求
- PVC 像是面向对象编程中抽象出来的接口,PV 是对应的实现
Static Volume Provisioning
提前创建一些 PV,用户提交 PVC 时,k8s 将 PVC 与合适的 PV bound 在一起
创建 PV
-
AccessModes:也是用户需要关心的,就是说我使用这个 PV 的方式。它有三种使用方式。
-
单 node 读写访问;
-
多个 node 只读访问,是常见的一种数据的共享方式;
-
多个 node 上读写访问。
-
-
有多个 PV 满足PVC 里的 Capacity 和 AccessModes 时,选择 PV 的 size 最小的,accessmodes 列表最短的 PV,也即最小适合原则。
accessmodes 为啥是数组,有多个值?
没查到啥
-
ReclaimPolicy: PV 的 PVC 在删除之后,PV 如何处理
- delete,也就是说 PVC 被删除之后,PV 也会被删除;
- Retain,就是保留,保留之后,后面这个 PV 需要管理员来手动处理。
-
NodeAffinity:创建出来的 PV,能被哪些 node 去挂载使用,通过 NodeAffinity 来声明对node的限制,对使用该PV的pod调度限制,pod 必须要调度到这些能访问 PV 的 node 上,才能使用这块 PV
使用 PV
缺点
需求不同,想要与预规划的 PV 匹配上很难。如果制定标准,减少匹配难度,又会造成资源浪费。
Dynamic Volume Provisioning
配置存储模板 StorageClass,在需要 PV 时,提交 PVC,指定模板,动态创建需要的 PV。
创建 StorageClass
使用 PV
- 相对于静态 PV,多了个
StorageClassName
架构设计
PV 和 PVC 的处理流程
- 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 才开始创建并启动容器。
-
csi:container storage interface,它是K8s社区后面对存储插件实现(out of tree)的官方推荐方式。csi 的实现大体可以分为两部分:
-
第一部分是由k8s社区驱动实现的通用的部分,例如 csi-provisioner和 csi-attacher controller;
-
另外一种是由云存储厂商实践的,对接云存储厂商的 OpenApi,主要是实现真正的 create/delete/mount/unmount 存储的相关操作,对应到上图中的csi-controller-server和csi-node-server。
-
其他
docker管理的volume
在Dockerfile里声明 volume,可用于持久化数据,多容器共享数据。这里的volume没有指定宿主机目录,所以是交给docker管理。经测试,这样声明的volume,容器删除后依旧存在。
docker 保持容器运行
提供前台程序,不让容器退出。
docker run -d test-docker-volume sleep infinity
k8s 保持容器运行
containers:
- name: ubuntu
image: ubuntu
command: [ "sleep" ]
args: [ "infinity" ]