概述

本文是 Kubernetes 入门系列的最后一篇了,在开始这篇的内容之前,让我来回顾一下,在使用纯 Docker Container 的时候,如果想要在两个 Container 之间共享一个目录,正常的操作行为是怎样的。

我以前的操作方式是这样的,先运行一个 Container,然后通过 -v 参数关联 Host 中的目录,然后 Container 中的文件操作都会反映到所在的宿主机中;当这个目录被两个 Container 同时挂载的时候,那么就可以简单实现在两个不同的 Container 中共享一个文件。那么,当上 Kubernetes 之后,想要实现类似的需求,又可以如何做呢?

可能看到第 10 篇 ConfigMap 的介绍之后,很正常就会有想通过 ConfigMap 来实现两个 Container 之间的文件(数据)共享,但是,再回顾一下第 10 章中的 ConfigMap 的使用,会发现,在使用 ConfigMap 作为文件挂载入 Container 的时候,我使用到了一种成为 Volume 的资源,而这个 Volume 资源就是我在这个入门最终篇中要介绍的东西了。

什么是 Volume

Volume,在 Linux 中的概念就是一个存储设备或者分区,但是在 Kubernetes 中,Volume 对应于块存储中的块,也可以认为是一个目录,你可以在这个目录中创建子目录,也可以创建出文件。

Kubernetes 中引入 Volume,目的我认为主要有两个:

第一个,现在应该很清楚了,Pod 是一系列 Container 的集合,所以需要有多个 Container 要共享数据;而 Pod 持久化数据的原因是,在 Kubernetes 中,Pod 的数据是临时存储的,如果不特别设置,当 Pod 被 remove 掉之后,数据也就随之被丢弃了,这在生产中是不可接受的。

Volume 怎么用

其实在第 10 篇: 中就已经稍微介绍了 Volume 的使用了,首先,Volume 是作为 Pod 的顶级属性存在的:

Volume Declare

在这里的声明中,标红这段只是一个声明,表示有这么一个 Volume,但是,这个 Volume 要怎么用,谁要用,那么还得在 Container 中声明:

Volume Mount

这里标红的部分就是表示将 Volume 挂载为 Container 中的 /etc/config 目录,相信经常使用 Linux 的同学再熟悉不过了。

Volume 也有类型

看过第 10 章的同学可能就奇怪了,怎么讲来讲去都是 ConfigMap,难道 Volume 就只和 ConfigMap 搭配使用吗?事实上,不是这样的,而且 ConfigMap 只是其中一种比较常见的 Volume 使用方式,除了 ConfigMap,还比较常见的 Volume 类型有:

完整的支持列表可以看:Volume 的类型,其实顾名思义,就是表示 Volume 是由谁或者是怎样的方式来提供的,事实上,这份列表中列举的那么多类型中,大部分都是可以不用存在的,都可以或者说就应该通过 PVC 的方式来使用。PVC 是 Volume 的一种,但是,这里不准备细说 PVC,因为后面我会有专门的存储系列介绍,所以会放在那个系列中介绍。

hostPath 类型示例

我在之前已经不止一次使用 ConfigMap 类型的 Volume 了,可能都已经看麻木了。那么,这一章节,我决定介绍一下 hostPath 的类型,可能你会认为这只是一种在两个 Container 中共享数据的一种方式,事实上,这只对了一半,hostPath 还有一些更高级的使用方式,那就是获取宿主集的信息!

我们知道,在 Linux 中,一切皆文件,所以很多目录下存放着的是系统的运行信息,例如 /run 目录下的进程信息,/sys 目录下的系统信息等,如果将这些目录暴露给 Container 会怎样,其实也不用猜,在介绍 DaemonSet 的时候,我介绍过一种 Prometheus 的 Exporter:Node Exporter,这是我截取的一段配置:

HostPath Volume

可以看到,NodeExporter 挂载了宿主机上的 /proc/sys 目录,这样,就可以在 Pod 中获取宿主机的监控数据,从而暴露给 Prometheus。

小结

相信在看完整个系列的文章之后,对于 Kubernetes 你已经能够尝试一些简单的东西了,而本系列文章就暂告一段落了。当然,这个系列肯定不是结束,事实上,这只是一个开始,因为后面会有若干的系列文章,例如会有:

这些内容,如果你感兴趣的话,不妨继续关注我的博客:https://liqiang.io,这些内容都会在不久之后持续更新!