研发测试场景下，一般追求的是一键快速起环境，横向动态复制，一人一套，随起随用，用完即走。作为使用方，其不用关心实际的物理资源是怎样的，环境起在哪里，只要声明自己的使用需求即可。但作为方案构建者以及 infrastructure 支撑，我们却深知，要想提供更好的解决方案，个中问题还有很多，且颇为不易。
比如在过去，笔者就曾一度困扰于如何优雅的放开本地物理盘给业务使用这个问题，尤其是本地 HDD 数据盘。
这里有个背景，我们的 Kubernetes 研发测试集群是用线上退下来的过保机器搭建，然后七牛又搞云存储，所以我们的机器中很多那种多盘位的存储密集型机器 (比如挂 12 块 4T 的盘)。所以如何更好的利用这些磁盘，就是个问题。
方案之一是把这些盘组成网络存储，然后通过七牛自身的云服务或者 ceph 等系统提供出去，这当然是可行的。不过有些业务其实就想单纯使用物理盘，那该怎么办呢？
纵观 Kubernetes 目前原生提供的几种方案，笔者发现都不完美:
笔者以为，理想中的本地磁盘使用方案，应当是按需申请，空间隔离，且自动化生命周期管理。这样才能既方便终端用户使用，也能减少运维支撑，提高效率。这里的关键技术点有三个:
综合以上三点，我们会发现基于 LVM 或分区技术 +CSI 的实现，当是比较符合上述用户体验的，而TopoLVM就是这样一个项目。
TopoLVM 是基于 LVM 的 Kubernetes 本地化磁盘方案，以 CSI 形式提供给用户使用。目前主要支持以下功能:
整体架构如下:
值得注意的是，在早期版本，为了能够动态感知节点上的剩余存储容量，TopoLVM 设计了个自定义扩展调度器（上图 topolvm-scheduler 部分），方便在 Scheduling 阶段为 Pod 绑定合适的 Node。而在 Kubernetes 1.21 之后，Kubernete 已经原生支持了 Storage Capacity Tracking的能力，这块的实现整体就变的优雅很多，topolvm-Scheduler 也就不再需要了。
当然，要想认知到 TopoLVM 的核心原理，除了了解 CSI 编写规范外，最重要的就是需要了解 LVM 相关技术。而正是因为通过 LVM 能够动态创建 LV，动态扩缩容，TopoLVM 才能支持动态 Provisioning 相关的能力。
不过，虽然作为开源项目 TopoLVM 已基本够用，但丰富度略显不足。而博云近期也开源了他们的云原生本地磁盘管理方案 Carina，看起来更完善一些。
Carina 除了提供基于 LVM 的方案外，还支持裸盘分区方式，以及 IOPS 限制等，功能更加丰富。代码组织规范也更贴合云原生社区的方式，整体非常值得一探。
参考链接
