[Kubernetes]PV,PVC,StorageClass之间的关系详解

在Kubernetes中,容器化一个应用比较麻烦的地方莫过于对其"状态"的管理,而最多见的"状态",莫过于存储状态.
在[Kubernetes]深刻理解StatefulSet这篇文章中,稍微提了一下PV(Persistent Volume)和PVC(Persistent Volume Claim),这篇文章详细说一说.

大概了解

我先大致说一下整个过程,有一个小小的认识,而后我再详细展开说.
用户提交请求建立Pod时,Kubernetes发现这个Pod声明使用了PVC,这时就须要PersistentVolumeController帮它找一个PV来进行配对.若是有的话呢,就直接进行绑定.可是若是没有呢?就去找对应的StorageClass,帮它新建立一个PV,而后再和PVC进行绑定.可是请注意,此时新建立的PV,只是一个API对象,还须要通过"两阶段"处理变成宿主机上的"持久化Volume"才算是真正有用.这个时候,Pod就能够正常启动,并将相关文档挂载到容器内指定的路径.
我知道你对上面的过程确定有些懵了,别急,我们慢慢把这个过程剖析一下.

持久化Volume

比较难理解的应该就是须要通过"两阶段"处理变成宿主机上的"持久化Volume"这部份内容了.
所谓"持久化Volume",指的就是这个宿主机上的目录,具有"持久性",也就是说:这个目录里面的内容,既不会由于容器的删除而被清理掉,也不会和当前的宿主机进行绑定.这样,当容器被重启或者在其余节点上重建出来以后,仍然可以经过挂载这个Volume来访问到目录里面的内容.
这里面主要有两个关键点:一,不会由于容器的删除而清理掉里面的内容,二,不会和当前的宿主机进行绑定.Kubernetes须要作的工做就是达到这两个目的,从而使得目录具有"持久性".

Kubernetes在这个准备"持久化"宿主机目录的过程当中,咱们能够形象的称为"两阶段处理":
第一阶段:为虚拟机挂载磁盘,把这个阶段称为"Attach".
第二阶段:挂载磁盘以后,若是想要使用,还须要将挂载的磁盘进行格式化处理,并挂载到Volume宿主机目录上,这个阶段称为"Mount",而这个挂载点,正是Volume的宿主机目录.因此,Mount阶段的操做,能够这样来表示:

# 经过 lsblk 命令获取磁盘设备 ID
$ sudo lsblk
# 格式化成 ext4 格式
$ sudo mkfs.ext4 -m 0 -F -E lazy_itable_init=0,lazy_journal_init=0,discard /dev/< 磁盘设备 ID>
# 挂载到挂载点
$ sudo mkdir -p /var/lib/kubelet/pods/<Pod 的 ID>/volumes/kubernetes.io~<Volume 类型 >/<Volume 名字 >
#若是kubelet须要做为client,将远端NFS服务器的目录挂载到Volume的宿主机目录上,则须要执行如下命令:
$ mount -t nfs <NFS 服务器地址 >:/ /var/lib/kubelet/pods/<Pod 的 ID>/volumes/kubernetes.io~<Volume 类型 >/<Volume 名字 >

以上两个阶段完成以后,咱们在这个目录里写入的全部文件,就都会被保存起来,从而实现了对这个Volume宿主机目录的"持久化".(若是给虚拟机扩充过磁盘的话,对这一部份内容应该是比较容易理解的)
可是对于Kubernetes来讲,它是如何定义和区分这两个阶段的呢?
其实很简单,在具体的Volume插件的实现接口上,Kubernetes分别给这两个阶段提供了两种不一样的参数列表:

对于"Attach":Kubernetes提供的可用参数是nodeName,即宿主机名字.

对于"Mount",Kubernetes提供的可用参数是dir,即Volume的宿主机目录.

因此,在具体使用时,只须要根据本身的需求进行选择和实现就能够达到目的了. 这就是Kubernetes的Volume处理机制的相关说明了. 接下来讲说另一个重要的概念:StorageClass

StorageClass

PV这个对象的建立,是由运维人员来完成的,可是在大规模的生产环境中,这实际上是一个很是麻烦的操做.由于在一个大规模的Kubernetes集群里,可能有成千上万个PVC,这就意味着运维人员必须实现建立出这个多个PV,此外,随着项目的须要,会有新的PVC不断被提交,那么运维人员就须要不断的添加新的,知足要求的PV,不然新的Pod就会由于PVC绑定不到PV而致使建立失败.这在自动化中,确定是不能被容许的.
因此,Kubernetes提供了一套能够自动建立PV的机制,即:Dynamic Provisioning.而这个机制的核心在于:StorageClass这个API对象.

StorageClass对象会定义下面两部份内容:

• 1,PV的属性.好比,存储类型,Volume的大小等.
• 2,建立这种PV须要用到的存储插件

有了这两个信息以后,Kubernetes就可以根据用户提交的PVC,找到一个对应的StorageClass,以后Kubernetes就会调用该StorageClass声明的存储插件,进而建立出须要的PV.
可是其实使用起来是一件很简单的事情,你只须要根据本身的需求,编写YAML文件便可,而后使用kubectl create命令执行便可.

最后小结

到这里,讲的就差很少了.
综上所述呢,PVC描述的是Pod想要使用的持久化存储的属性,好比存储的大小,读写权限等.而PV则是一个具体的Volume属性,好比Volume的类型,挂载目录等.而StorageClass的做用,则是充当PV的模板,从而能够动态建立须要的PV.
最后,放一张图片,描述一下概念之间的关系:

些许的碎碎念

最后的最后,写点儿碎碎念.若是看的进去的话,就看看,看不进去,就算了.
今天早上打开手机,收到了一条消息:

在上面介绍StorageClass的时候,我说了,若是想要使用的话,实际上是一件很简单的事情,只须要写一下YAML文件便可.可是背后的原理若是不去深究,不去学习的话,遇到问题的时候,仍是无从下手的.
还记得当时倒腾k8s,一个月的时间就倒腾的差很少了,项目上线的时候,也是有惊无险的撑了下来.因此呢,若是只是达到会用的层次的话,一个月的时间就差很少了.
可是若是想要有所提升,想要在遇到问题时,可以准肯定位,仍是须要再回来补充理论.
作技术,前期的实践当然是不可少,可是后期的理论也要作.绝对不能仅仅停留在会用的层次上面,若是有时间,有精力,最好仍是可以再深刻理解一下背后的原理知识.
这也是我一直坚持的学习方法:基于实践,补充理论.

以上内容来自我学习<深刻剖析Kubernetes>专栏文章以后的一些看法,有偏颇之处,还望指出.
感谢您的阅读~