一直以来，我都在寻找一个私有云下 Kubernetes 存储方案的“最佳实践“，常见如 GlusterFS 的部署方案并不太适合现有的环境，裸机方案需要三台服务器进行集群部署，然而手头并没有多余的机器了，在当前部署 Openstack 的机器上进行部署就更不用想了，这只会增加之后维护的复杂性，特别是服务器的磁盘我并没有进行特别的分区操作，Openstack 的卷存储是直接挂载在 /dev/loop 下，使用的是整个磁盘的空间，引入其他的分布式文件系统可能会与 Cinder 产生冲突。

GlusterFS 的另一种部署方案是在 k8s 集群上进行部署，直接使用 Node 上的存储资源，这要求我必须为虚拟机实例直接分配更多的存储，存储利用率很难保证；而根据使用情况将 Openstack 中的卷挂载到各个实例上，管理起来太过麻烦。

总结下来，存储方案需要满足的最关键的两点：

1. 存储与 kubernetes 环境脱离，保证每个 kubernetes 的 Node 所需 Volume 都很小，PersistentVolume 以动态的形式引入，即实现一个云存储，有利于迁移和提升资源利用率；
2. 直接利用 Openstack 的 Cinder 来提供存储功能，不引入额外复杂度。

相较于 Scheduler Extender ，调度框架通过将所有的调度过程 “插件化“ 。

目前为止，Scheduler Framework 的开发需要重新 build 整个调度器的代码，还不支持一个 “热插拔” 的方式，这与 Scheduler Extender / Multi-scheduler 的 “无侵入“ 的扩展方式是不一样的。