TopoLVM: 基于LVM的Kubernetes本地持久化方案，容量感知，动态创建PV，轻松使用本地磁盘

研发测试场景下，一般追求的是一键快速起环境，横向动态复制，一人一套，随起随用，用完即走。作为使用方，其不用关心实际的物理资源是怎样的，环境起在哪里，只要声明自己的使用需求即可。但作为方案构建者以及infrastructure支撑，我们却深知，要想提供更好的解决方案，个中问题还有很多，且颇为不易。

比如在过去，笔者就曾一度困扰于如何优雅的放开本地物理盘给业务使用这个问题，尤其是本地HDD数据盘。

这里有个背景，我们的Kubernetes研发测试集群是用线上退下来的过保机器搭建，然后七牛又搞云存储，所以我们的机器中很多那种多盘位的存储密集型机器(比如挂12块4T的盘)。所以如何更好的利用这些磁盘，就是个问题。

方案之一是把这些盘组成网络存储，然后通过七牛自身的云服务或者ceph等系统提供出去，这当然是可行的。不过有些业务其实就想单纯使用物理盘，那该怎么办呢？

纵观Kubernetes目前原生提供的几种方案，笔者发现都不完美:

• Emptydir 非持久化方案，Pod删除，EmptyDir也会被清空。另外Emptydir使用的是rootfs的存储空间，而这个空间有可能是放在在系统盘上的，所以对它的使用当慎之又慎。
• HostPath 持久化方案，但安全风险很高，官方不推荐。另外，从使用角度也不方便。比如作为用户，你首先要清楚知道目标系统的情况，知道具体的盘符和目录位置然后才能在HostPath里正确引用。但现实是从集群安全角度，用户不一定有直接登录机器的权限。另外即使你的Pod占了某个宿主机的目录，也不能排除别人二次占用，或者误操作。所以HostPath的使用场景实际很受限。
• Local Persistent Volume 持久化方案，以PVC/PV的形式来使用本地存储。想法很好，但是不能动态创建PV，对于PV提供者来说，心智负担较高。当然社区现在也有提供Local Static Provisioner，某种程度上简化了这块的心智负担，但是仍然需要预先规划目录或者分区，略显不足。

笔者以为，理想中的本地磁盘使用方案，应当是按需申请，空间隔离，且自动化生命周期管理。这样才能既方便终端用户使用，也能减少运维支撑，提高效率。这里的关键技术点有三个:

• 按需申请 意味着最好以PVC+StorageClass的模式来提供服务，做到PV动态创建。而要实现这点，容量感知 是关键，因为若调度到空间不足的节点上很明显是不合理的。最好能结合PVC申请的容量+Node上的剩余容量，综合选择最优的节点来做绑定。
• 空间隔离 要确保用户申请的空间大小一定是足额的，不被侵占的。从这里看，单纯的把文件系统的目录用作PV但容量上彼此不隔离显然不合适。
• 自动化生命周期管理 动态Provisioning是强需。

综合以上三点，我们会发现基于 LVM或分区技术+CSI 的实现，当是比较符合上述用户体验的，而TopoLVM就是这样一个项目。

地址: https://github.com/topolvm/topolvm

TopoLVM是基于LVM的Kubernetes本地化磁盘方案，以CSI形式提供给用户使用。目前主要支持以下功能:

• 动态Provisioning
• 支持原生数据块卷（Raw Block Volume）
• Volume伸缩

整体架构如下:

值得注意的是，在早期版本，为了能够动态感知节点上的剩余存储容量，TopoLVM设计了个自定义扩展调度器（上图topolvm-scheduler部分），方便在Scheduling阶段为Pod绑定合适的Node。而在Kubernetes 1.21之后，Kubernete已经原生支持了 Storage Capacity Tracking的能力，这块的实现整体就变的优雅很多，topolvm-Scheduler也就不再需要了。

当然，要想认知到TopoLVM的核心原理，除了了解CSI编写规范外，最重要的就是需要了解LVM相关技术。而正是因为通过LVM能够动态创建LV，动态扩缩容，TopoLVM才能支持动态Provisioning相关的能力。

不过，虽然作为开源项目TopoLVM已基本够用，但丰富度略显不足。而博云近期也开源了他们的云原生本地磁盘管理方案Carina，看起来更完善一些。

项目地址: https://github.com/carina-io/carina

Carina除了提供基于LVM的方案外，还支持裸盘分区方式，以及IOPS限制等，功能更加丰富。代码组织规范也更贴合云原生社区的方式，整体非常值得一探。