29 _ PV、PVC体系是不是多此一举？从本地持久化卷谈起1

file:///C:/Users/qiaochaowen/Desktop/k8s/29%20%20PV%E3%80%81PVC%E4%BD%93%E7%B3%BB%E6%98%AF%E4%B8%8D%E6%98%

…

29 | PV、PVC体系是不是多此一举？从本地持久化卷谈起

29 | PV、PVC体系是不是多此一举？

本地持久化卷谈起。

在上一篇文章中，我为你详细讲解了 PV、PVC 持久化存储体系在 Kubernetes 项

目中的设计和实现原理。而在文章最后的思考题中，我为你留下了这样一个讨论话

题：像 PV、PVC 这样的用法，是不是有“过度设计”的嫌疑？

比如，我们公司的运维人员可以像往常一样维护一套 NFS 或者 Ceph 服务器，根

本不必学习 Kubernetes。而开发人员，则完全可以靠“复制粘贴”的方式，在

Pod 的 YAML 文件里填上 Volumes 字段，而不需要去使用 PV 和 PVC。

file:///C:/Users/qiaochaowen/Desktop/k8s/29%20%20PV%E3%80%81PVC%E4%BD%93%E7%B3%BB%E6%98%AF%E4%B8%8D%E6%98%

…

实际上，如果只是为了职责划分，PV、PVC 体系确实不见得比直接在 Pod 里声

明 Volumes 字段有什么优势。

储了。

也就是说，用户希望 Kubernetes 能够直接使用宿主机上的本地磁盘目录，而不

依赖于远程存储服务，来提供“持久化”的容器 Volume。

这样做的好处很明显，由于这个 Volume 直接使用的是本地磁盘，尤其是 SSD

盘，它的读写性能相比于大多数远程存储来说，要好得多。这个需求对本地物理服

务器部署的私有 Kubernetes 集群来说，非常常见。

所以，Kubernetes 在 v1.10 之后，就逐渐依靠 PV、PVC 体系实现了这个特性。

这个特性的名字叫作：Local Persistent Volume。

不过，首先需要明确的是，Local Persistent Volume 并不适用于所有应用。事

实上，它的适用范围非常固定，比如：高优先级的系统应用，需要在多个不同节点

接下来，我就为你深入讲解一下这个特性。

不难想象，Local Persistent Volume 的设计，主要面临两个难点。

第一个难点在于：如何把本地磁盘抽象成 PV。

可能你会说，Local Persistent Volume，不就等同于 hostPath 加 NodeAffinity

吗？

file:///C:/Users/qiaochaowen/Desktop/k8s/29%20%20PV%E3%80%81PVC%E4%BD%93%E7%B3%BB%E6%98%AF%E4%B8%8D%E6%98%

…

比如，一个 Pod 可以声明使用类型为 Local 的 PV，而这个 PV 其实就是一个

hostPath 类型的 Volume。如果这个 hostPath 对应的目录，已经在节点 A 上被

事先创建好了。那么，我只需要再给这个 Pod 加上一个 nodeAffinity=nodeA，

不就可以使用这个 Volume 了吗？

第二个难点在于：调度器如何保证 Pod 始终能被正确地调度到它所请求的 Local

Persistent Volume 所在的节点上呢？

造成这个问题的原因在于，对于常规的 PV 来说，Kubernetes 都是先调度 Pod

到某个节点上，然后，再通过“两阶段处理”来“持久化”这台机器上的 Volume

目录，进而完成 Volume 目录与容器的绑定挂载。

可是，对于 Local PV 来说，节点上可供使用的磁盘（或者块设备），必须是运维

人员提前准备好的。它们在不同节点上的挂载情况可以完全不同，甚至有的节点可

以没这种磁盘。

所以，这时候，调度器就必须能够知道所有节点与 Local Persistent Volume 对

应的磁盘的关联关系，然后根据这个信息来调度 Pod。

而在我们部署的私有环境中，你有两种办法来完成这个步骤。

第一种，当然就是给你的宿主机挂载并格式化一个可用的本地磁盘，这也是最

常规的操作；

第二种，对于实验环境，你其实可以在宿主机上挂载几个 RAM Disk（内存

盘）来模拟本地磁盘。

接下来，我会使用第二种方法，在我们之前部署的 Kubernetes 集群上进行实

践。