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

Volumes 介绍

Pod Volumes

首先来看一下 Pod Volumes 的使用场景:

以上两个场景,其实都可以借助 Volumes 来很好地解决,接下来首先看一下 Pod Volumes 的常见类型:

  1. 本地存储,常用的有 emptydir/hostpath;
  2. 网络存储:网络存储当前的实现方式有两种,一种是 in-tree,它的实现的代码是放在 K8s 代码仓库中的,随着k8s对存储类型支持的增多,这种方式会给k8s本身的维护和发展带来很大的负担;而第二种实现方式是 out-of-tree,它的实现其实是给 K8s 本身解耦的,通过抽象接口将不同存储的driver实现从k8s代码仓库中剥离,因此out-of-tree 是后面社区主推的一种实现网络存储插件的方式;
  3. Projected Volumes:它其实是将一些配置信息,如 secret/configmap 用卷的形式挂载在容器中,让容器中的程序可以通过POSIX接口来访问配置数据;
  4. PV 与 PVC 就是今天要重点介绍的内容。

Persistent Volumes

avatar

接下来看一下 PV(Persistent Volumes)。既然已经有了 Pod Volumes,为什么又要引入 PV 呢?我们知道 pod 中声明的 volume 生命周期与 pod 是相同的,以下有几种常见的场景:

以上场景中,通过 Pod Volumes 很难准确地表达它的复用/共享语义,对它的扩展也比较困难。因此 K8s 中又引入了 **Persistent Volumes **概念,它可以将存储和计算分离,通过不同的组件来管理存储资源和计算资源,然后解耦 pod 和 Volume 之间生命周期的关联。这样,当把 pod 删除之后,它使用的PV仍然存在,还可以被新建的 pod 复用。

PVC 设计意图

avatar

了解 PV 后,应该如何使用它呢?

用户在使用 PV 时其实是通过 PVC,为什么有了 PV 又设计了 PVC 呢?主要原因是为了简化K8s用户对存储的使用方式,做到职责分离。通常用户在使用存储的时候,只用声明所需的存储大小以及访问模式。

访问模式是什么?其实就是:我要使用的存储是可以被多个node共享还是只能单node独占访问(注意是node level而不是pod level)?只读还是读写访问?用户只用关心这些东西,与存储相关的实现细节是不需要关心的。

通过 PVC 和 PV 的概念,将用户需求和实现细节解耦开,用户只用通过 PVC 声明自己的存储需求。PV是有集群管理员和存储相关团队来统一运维和管控,这样的话,就简化了用户使用存储的方式。可以看到,PV 和 PVC 的设计其实有点像面向对象的接口与实现的关系。用户在使用功能时,只需关心用户接口,不需关心它内部复杂的实现细节。

既然 PV 是由集群管理员统一管控的,接下来就看一下 PV 这个对象是怎么产生的。

Static Volume Provisioning

第一种产生方式:静态产生方式 - 静态 Provisioning。

avatar

静态 Provisioning:由集群管理员事先去规划这个集群中的用户会怎样使用存储,它会先预分配一些存储,也就是预先创建一些 PV;然后用户在提交自己的存储需求(也就是 PVC)的时候,K8s 内部相关组件会帮助它把 PVC 和 PV 做绑定;之后用户再通过 pod 去使用存储的时候,就可以通过 PVC 找到相应的 PV,它就可以使用了。

静态产生方式有什么不足呢?可以看到,首先需要集群管理员预分配,预分配其实是很难预测用户真实需求的。举一个最简单的例子:如果用户需要的是 20G,然而集群管理员在分配的时候可能有 80G 、100G 的,但没有 20G 的,这样就很难满足用户的真实需求,也会造成资源浪费。有没有更好的方式呢?

Dynamic Volume Provisioning

第二种访问方式:动态 Dynamic Provisioning。

avatar

动态供给是什么意思呢?就是说现在集群管理员不预分配 PV,他写了一个模板文件,这个模板文件是用来表示创建某一类型存储(块存储,文件存储等)所需的一些参数,这些参数是用户不关心的,给存储本身实现有关的参数。用户只需要提交自身的存储需求,也就是PVC文件,并在 PVC 中指定使用的存储模板(StorageClass)。

K8s 集群中的管控组件,会结合 PVC 和 StorageClass 的信息动态,生成用户所需要的存储(PV),将 PVC 和 PV 进行绑定后,pod 就可以使用 PV 了。通过 StorageClass 配置生成存储所需要的存储模板,再结合用户的需求动态创建 PV 对象,做到按需分配,在没有增加用户使用难度的同时也解放了集群管理员的运维工作。

用例解读

接下来看一下 Pod Volumes、PV、PVC 及 StorageClass 具体是如何使用的。

Pod Volumes 的使用

avatar

首先来看一下 Pod Volumes 的使用。如上图左侧所示,我们可以在 pod yaml 文件中的 Volumes 字段中,声明我们卷的名字以及卷的类型。声明的两个卷,一个是用的是 emptyDir,另外一个用的是 hostPath,这两种都是本地卷。在容器中应该怎么去使用这个卷呢?它其实可以通过 volumeMounts 这个字段,volumeMounts 字段里面指定的 name 其实就是它使用的哪个卷,mountPath 就是容器中的挂载路径。

这里还有个 subPath,subPath 是什么?

先看一下,这两个容器都指定使用了同一个卷,就是这个 cache-volume。那么,在多个容器共享同一个卷的时候,为了隔离数据,我们可以通过 subPath 来完成这个操作。它会在卷里面建立两个子目录,然后容器 1 往 cache 下面写的数据其实都写在子目录 cache1 了,容器 2 往 cache 写的目录,其数据最终会落在这个卷里子目录下面的 cache2 下。

还有一个 readOnly 字段,readOnly 的意思其实就是只读挂载,这个挂载你往挂载点下面实际上是没有办法去写数据的。

另外emptyDir、hostPath 都是本地存储,它们之间有什么细微的差别呢?emptyDir 其实是在 pod 创建的过程中会临时创建的一个目录,这个目录随着 pod 删除也会被删除,里面的数据会被清空掉;hostPath 顾名思义,其实就是宿主机上的一个路径,在 pod 删除之后,这个目录还是存在的,它的数据也不会被丢失。这就是它们两者之间一个细微的差别。

静态 PV 使用

avatar

接下来再看一下,PV 和 PVC 是怎么使用的。

先看一个静态 PV 创建方式。静态 PV 的话,首先是由管理员来创建的,管理员我们这里以 NAS,就是阿里云文件存储为例。我需要先在阿里云的文件存储控制台上去创建 NAS 存储,然后把 NAS 存储的相关信息要填到 PV 对象中,这个 PV 对象预创建出来后,用户可以通过 PVC 来声明自己的存储需求,然后再去创建 pod。创建 pod 还是通过我们刚才讲解的字段把存储挂载到某一个容器中的某一个挂载点下面。

那么接下来看一下 yaml 怎么写。集群管理员首先是在云存储厂商那边先去把存储创建出来,然后把相应的信息填写到 PV 对象中。

avatar

刚刚创建的阿里云 NAS 文件存储对应的PV,有个比较重要的字段:capacity,即创建的这个存储的大小,accessModes,创建出来的这个存储它的访问方式,我们后面会讲解总共有几种访问方式。

然后有个 ReclaimPolicy,ReclaimPolicy 的意思就是:这块存储在被使用后,等它的使用方 pod 以及 PVC 被删除之后,这个 PV 是应该被删掉还是被保留呢?其实就是PV的回收策略。

接下来看看用户怎么去使用该PV对象。用户在使用存储的时候,需要先创建一个 PVC 对象。PVC 对象里面,只需要指定存储需求,不用关心存储本身的具体实现细节。存储需求包括哪些呢?首先是需要的大小,也就是 resources.requests.storage;然后是它的访问方式,即需要这个存储的访问方式,这里声明为ReadWriteMany,也即支持多node读写访问,这也是文件存储的典型特性。

avatar

上图中左侧,可以看到这个声明:它的 size 和它的access mode,跟我们刚才静态创建这块 PV 其实是匹配的。这样的话,当用户在提交 PVC 的时候,K8s 集群相关的组件就会把 PV 的 PVC bound 到一起。之后,用户在提交 pod yaml 的时候,可以在卷里面写上 PVC声明,在 PVC声明里面可以通过 claimName 来声明要用哪个 PVC。这时,挂载方式其实跟前面讲的一样,当提交完 yaml 的时候,它可以通过 PVC 找到 bound 着的那个 PV,然后就可以用那块存储了。这是静态 Provisioning到被pod使用的一个过程。

动态 PV 使用

然后再看一下动态 Provisioning。动态 Provisioning 上面提到过,系统管理员不再预分配 PV,而只是创建一个模板文件。

avatar

这个模板文件叫 StorageClass,在StorageClass里面,我们需要填的重要信息:第一个是 provisioner,provisioner 是什么?它其实就是说我当时创建 PV 和对应的存储的时候,应该用哪个存储插件来去创建。

这些参数是通过k8s创建存储的时候,需要指定的一些细节参数。对于这些参数,用户是不需要关心的,像这里 regionld、zoneld、fsType 和它的类型。ReclaimPolicy跟我们刚才讲解的 PV 里的意思是一样的,就是说动态创建出来的这块 PV,当使用方使用结束、Pod 及 PVC 被删除后,这块 PV 应该怎么处理,我们这个地方写的是 delete,意思就是说当使用方 pod 和 PVC 被删除之后,这个 PV 也会被删除掉。

接下来看一下,集群管理员提交完 StorageClass,也就是提交创建 PV 的模板之后,用户怎么用,首先还是需要写一个 PVC 的文件。

avatar

PVC 的文件里存储的大小、访问模式是不变的。现在需要新加一个字段,叫 StorageClassName,它的意思是指定动态创建PV的模板文件的名字,这里StorageClassName填的就是上面声明的csi-disk。

在提交完 PVC之后,K8s 集群中的相关组件就会根据 PVC 以及对应的 StorageClass 动态生成这块 PV 给这个 PVC 做一个绑定,之后用户在提交自己的 yaml 时,用法和接下来的流程和前面的静态使用方式是一样的,通过 PVC 找到我们动态创建的 PV,然后把它挂载到相应的容器中就可以使用了。

PV Spec 重要字段解析

接下来,我们讲解一下 PV 的一些重要字段:

avatar

用户在提交 PVC 的时候,最重要的两个字段 —— Capacity 和 AccessModes。在提交 PVC后,k8s集群中的相关组件是如何去找到合适的PV呢?首先它是通过为PV建立的AccessModes索引找到所有能够满足用户的 PVC 里面的 AccessModes 要求的PV list,然后根据PVC的 Capacity,StorageClassName, Label Selector 进一步筛选PV,如果满足条件的PV有多个,选择PV的size最小的,accessmodes列表最短的PV,也即最小适合原则。

PV 状态流转

avatar

接下来我们看一下 PV 的状态流转。首先在创建 PV 对象后,它会处在短暂的pending 状态;等真正的 PV 创建好之后,它就处在 available 状态。

available 状态意思就是可以使用的状态,用户在提交 PVC 之后,被 K8s 相关组件做完 bound(即:找到相应的 PV),这个时候 PV 和 PVC 就结合到一起了,此时两者都处在 bound 状态。当用户在使用完 PVC,将其删除后,这个 PV 就处在 released 状态,之后它应该被删除还是被保留呢?这个就会依赖我们刚才说的 ReclaimPolicy。

这里有一个点需要特别说明一下:当 PV 已经处在 released 状态下,它是没有办法直接回到 available 状态,也就是说接下来无法被一个新的 PVC 去做绑定。如果我们想把已经 released 的 PV 复用,我们这个时候通常应该怎么去做呢? 第一种方式:我们可以新建一个 PV 对象,然后把之前的 released 的 PV 的相关字段的信息填到新的 PV 对象里面,这样的话,这个 PV 就可以结合新的 PVC 了;第二种是我们在删除 pod 之后,不要去删除 PVC 对象,这样给 PV 绑定的 PVC 还是存在的,下次 pod 使用的时候,就可以直接通过 PVC 去复用。K8s中的StatefulSet管理的Pod带存储的迁移就是通过这种方式。

操作演示

接下来,我会在实际的环境中给大家演示一下,静态 Provisioning 以及动态 Provisioning 具体操作方式。

静态 Provisioning 例子

静态 Provisioning 主要用的是阿里云的 NAS 文件存储;动态 Provisioning 主要用了阿里云的云盘。它们需要相应存储插件,插件我已经提前部署在我的 K8s 集群中了(csi-nasplugin*是为了在 k8s 中使用阿里云 NAS 所需的插件,csi-disk*是为了在 k8s 中使用阿里云云盘所需要的插件)。

avatar

我们接下来先看一下静态 Provisioning 的 PV 的 yaml 文件。

avatar

volumeAttributes是我在阿里云nas控制台预先创建的 NAS 文件系统的相关信息,我们主要需要关心的有 capacity 为5Gi; accessModes 为多node读写访问; reclaimPolicy:Retain,也就是当我使用方的 PVC 被删除之后,我这个 PV 是要保留下来的;以及在使用这个卷的过程中使用的driver。

然后我们把对应的 PV 创建出来:

avatar

我们看一下上图 PV 的状态,已经处在 Available,也就是说它已经可以被使用了。

再创建出来 nas-pvc:

avatar

我们看这个时候 PVC 已经新创建出来了,而且也已经和我们上面创建的PV绑定到一起了。我们看一下 PVC 的 yaml 里面写的什么。

avatar

其实很简单 ,就是我需要的大小以及我需要的 accessModes。提交完之后,它就与我们集群中已经存在的 PV 做匹配,匹配成功之后,它就会做 bound。

接下来我们去创建使用 nas-fs 的 pod:

avatar

上图看到,这两个 Pod 都已经处在 running 状态了。

我们先看一下这个 pod yaml:

avatar

pod yaml 里面声明了刚才我们创建出来的PVC对象,然后把它挂载到nas-container容器中的 /data 下面。我们这个 pod 是通过前面课程中讲解 deployment 创建两个副本,通过反亲和性,将两个副本调度在不同的 node 上面。

avatar

上图我们可以看一下,两个Pod所在的宿主机是不一样的。

如下图所示:我们登陆到第一个上面,findmnt 看一下它的挂载信息,这个其实就挂载在我声明的 nas-fs 上,那我们再在下面 touch 个 test.test.test 文件,我们也会登陆到另外一个容器看一下,它有没有被共享。

avatar

我们退出再登陆另外一个 pod(刚才登陆的是第一个,现在登陆第二个)。

如下图所示:我们也 findmnt 一下,可以看到,这两个 pod 的远程挂载路径一样,也就是说我们用的是同一个 NAS PV,我们再看一下刚才创建出来的那个是否存在。

avatar

可以看到,这个也是存在的,就说明这两个运行在不同node上的 pod 共享了同一个 nas 存储。

接下来我们看一下把两个 pod 删掉之后的情况。先删Pod,接着再删一下对应的 PVC(K8s内部对pvc对象由保护机制,在删除pvc对象时如果发现有pod在使用pvc,pvc是删除不掉的),这个可能要稍等一下。

avatar

看一下下图对应的 PVC 是不是已经被删掉了。

avatar

上图显示,它已经被删掉了。再看一下,刚才的 nas PV 还是在的,它的状态是处在 Released 状态,也就是说刚才使用它的 PVC 已经被删掉了,然后它被 released 了。又因为我们 RECLAIN POLICY 是 Retain,所以它这个 PV 是被保留下来的。

动态 Provisioning 例子

接下来我们来看第二个例子,动态 Provisioning 的例子。我们先把保留下来的 PV 手动删掉,可以看到集群中没有 PV了。接下来演示一下动态 Provisioning。

首先,先去创建一个生成 PV 的模板文件,也就是 storageclass。看一下 storageclass 里面的内容,其实很简单。

avatar

如上图所示,我事先指定的是我要创建存储的卷插件(阿里云云盘插件,由阿里云团队开发),这个我们已经提前部署好了;我们可以看到,parameters部分是创建存储所需要的一些参数,但是用户不需要关心这些信息;然后是 reclaimPolicy,也就是说通过这个 storageclass 创建出来的 PV 在给绑定到一起的 PVC 删除之后,它是要保留还是要删除。

avatar

如上图所示:现在这个集群中是没有 PV 的,我们动态提交一个 PVC 文件,先看一下它的 PVC 文件。它的 accessModes-ReadWriteOnce(因为阿里云云盘其实只能是单node读写的,所以我们声明这样的方式),它的存储大小需求是 30G,它的 storageClassName 是 csi-disk,就是我们刚才创建的 storageclass,也就是说它指定要通过这个模板去生成 PV。

avatar

这个 PVC 此时正处在 pending 状态,这就说明它对应的 PV 还在创建过程中。

avatar

稍过一会,我们看到已经有一个新的 PV 生成,这个 PV 其实就是根据我们提交的 PVC 以及 PVC 里面指定的storageclass 动态生成的。之后k8s会将生成的 PV 以及我们提交的 PVC,就是这个 disk PVC 做绑定,之后我们就可以通过创建 pod 来使用了。

再看一下 pod yaml:

avatar

pod yaml 很简单,也是通过 PVC 声明,表明使用这个 PVC。然后是挂载点,下面我们可以创建看一下。

avatar

如下图所示:我们可以大概看一下 Events,首先被调度器调度,调度完之后,接下来会有个 attachdetach controller,它会去做 disk的attach操作,就是把我们对应的 PV 挂载到调度器调度的 node 上,然后Pod对应的容器才能启动,启动容器才能使用对应的盘。

avatar

接下来我会把 PVC 删掉,看一下PV 会不会根据我们的 reclaimPolicy 随之删掉呢?我们先看一下,这个时候 PVC 还是存在的,对应的 PV 也是存在的。

avatar

然后删一下 PVC,删完之后再看一下:我们的 PV 也被删了,也就是说根据 reclaimPolicy,我们在删除 PVC 的同时,PV 也会被删除掉。

avatar

我们的演示部分就到这里了。

架构设计

PV 和 PVC 的处理流程

我们接下来看一下 K8s 中的 PV 和 PVC 体系的完整处理流程。我首先看一下这张图的右下部分里面提到的 csi。

avatar

csi 是什么?csi 的全称是 container storage interface,它是K8s社区后面对存储插件实现(out of tree)的官方推荐方式。csi 的实现大体可以分为两部分:

接下来看一下,当用户提交 yaml 之后,k8s内部的处理流程。用户在提交 PVCyaml 的时候,首先会在集群中生成一个 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。

PV、PVC 以及通过 csi 使用存储流程

我们接下来通过另一张图来更加详细看一下我们 PV、PVC 以及通过 CSI 使用存储的完整流程。

avatar

主要分为三个阶段:

总的来说,有三个阶段:第一个 create 阶段,主要是创建存储;第二个 attach 阶段,就是将那块存储挂载到 node 上面(通常为将存储load到node的/dev下面);第三个 mount 阶段,将对应的存储进一步挂载到 pod 可以使用的路径。这就是我们的 PVC、PV、已经通过CSI实现的卷从创建到使用的完整流程。

结束语

我们今天的内容大概就到这里,下一节我将为大家来分享 Volume Snapshot 以及 Volume Topology-aware Scheduling 相关的知识以及具体处理流程,谢谢大家~

本节总结(需补充)

本节课的主要内容就到此为止了,这里为大家简单总结一下。