Kubernetes本地存储对比

关于使用本地存储，常规使用方法分为hostPath、local PV（1.14以后GA）以及自研的CSI三种。

工作原理

1. hostPath

   顾名思义，使用的是宿主机上的磁盘和目录，直接将宿主机指定目录挂载给当前宿主机上指定的容器。

2. local PV

   同hostPath，也是使用的宿主机上的磁盘和目录。该功能自1.14后GA，遵从PV和PVC生命周期和管理逻辑。基本原理是预先规划和创建，为每个节点创建PV，用户在使用时声明PVC，由PVC选择合适PV进行绑定。PV的创建、声明和删除等工作需要管理员操作。

3. 本地卷CSI(略)

对比

	hostPath	Local PV	本地卷CSI	云硬盘 CSI
存储资源	本地存储	本地存储	本地存储	CBS
使用方式	volumes[N].hostPath	创建PVC	创建PVC	创建PVC
PV供应	X	静态，手工提前创建	动态，按需创建	动态，按需创建
容量限制	无法限制（依赖于逻辑卷）	无法限制（依赖于逻辑卷）	√	√
卷扩容	无法单独扩容某个hostPath	无法单独扩容某个local PV	√	√
卷漂移	X	X	X	√
Pod漂移时卷的行为	异节点重建目录，如果该节点存在同名目录则复用。可能造成数据紊乱，旧数据残留待清理	需要先解决PV和PVC的绑定关系，然后使PVC重新选择PV（依赖于删除PVC+重建PVC触发重新选择），旧数据残留待清理	配合Operator实现回收站功能，使得新旧PV和PVC均得以保留	跟随Pod漂移
删除应用，清空数据	人工或者脚本，需要清理所有节点同名目录	管理员删除PV，后续操作同hostPath	用户可以通过删除PVC删除PV（根据删除策略）；也可以管理员操作删除PV	用户可以通过删除PVC删除PV（根据删除策略）；也可以管理员操作删除PV
应用存在，删除漂移产生的无效数据	人工或脚本，需要清理除了当前Pod所在节点外其他节点同名目录	同hostPath	配合Operator实现回收站清理功能	不会产生无效数据

总结

hostPath为最原始的本地卷用法，基本功能小于等于local PV，建议慎用于生产。

local PV主要问题在于运维成本较大，卷无法漂移

1. 需要节点本地存储资源丰富，否则存储将成为瓶颈。
2. 提前创建PV资源，不能动态响应创建请求。
3. 无大小控制功能，可能存在同名路径混用，隔离性差
4. 数据清理工作频繁、任务量重
5. 扩容依赖于人为操作，且无法精准扩容
6. 卷无法漂移，寻找旧数据需要配合找到该Pod上一个所在节点

虽然社区有一些方案如local provisioner可以通过单独的local PV使用单独的logic volume来规避问题3和5，但仍不能掩盖local PV在生产大规模使用的问题。

一个典型场景是，当集群有N个工作节点，一个Pod如果漂移N-1次，那么所有节点都将会存储该Pod持久化数据，除了最近一份数据外，至少N-2份为无效数据。如果清理不及时，那么节点上存储资源将被大量消耗，且目录众多，难以匹配归属Pod。如果存在Pod使用的路径同名，可能会造成数据紊乱甚至冲突。

另一个场景是，如果不能够精准限制卷的大小，那么势必需要对Pod置放于哪些节点做事前规划，且可能与其他资源调度冲突，工作量巨大。

部分对IOPS有重度需求的有状态应用才需要本地卷，如mysql，kafka；业界主流是推荐存储和计算分离，调度器不再考虑复杂的存储问题。后续在部分场景保留本地卷的情况下，大部分轻量级的、无状态的应用将广泛使用后端存储作为持久化卷存储，使得应用和部署更加灵活。