云存储硬核技术内幕——(30) 七位数年终奖背后的故事

在上期《云存储硬核技术内幕——(29) 供给侧改革》中，我们提到，在引入StorageClass以后，容器编排平台kubernetes实现了存储资源的供给侧改革：按照PVC的需求，自动化地从存储提供者的资源池中分配资源，而不是去匹配管理员静态创建的PV，从而大大降低了运维成本，提升了资源使用效率和分配效率。

上一期也遗留了两个问题：

1. 当StorageClass请求不同的存储提供者，如FC SAN存储、Ceph RBD存储、iSCSI存储、NFS存储甚至是GlusterFS等分布式大规模存储，为其分配存储卷的时候，是通过什么样的机制与存储提供者进行交互的呢？
2. 如果我们开发了一款新型的存储产品，怎么样可以让它也接入StorageClass，为容器平台提供存储呢？

实际上，这两个问题是同一个问题。

我们先看第一个。

还是让我们看上期的栗子：

管理员在StorageClass中，用yaml描述了VSphere卷作为存储提供者：

apiVersion: storage.k8s.io/v1

kind: StorageClass
metadata:
  name: fast
provisioner: kubernetes.io/vsphere-volume
parameters:
  diskformat: zeroedthick

也就是说，如果有PVC需要分配来自vsphere-volume的存储资源时，kubernetes会调用vsphere-volume的API分配用以挂载给Pod的存储卷。

这是在什么地方实现的呢？

让我们翻开github上Kubernetes的代码：

https://github.com/kubernetes/kubernetes/tree/master/pkg/volume

这个目录下有一大堆子文件夹：

在vsphere_volume文件夹下，可以看到这个文件：

https://github.com/kubernetes/kubernetes/blob/master/pkg/volume/vsphere_volume/vsphere_volume.go

由于篇幅原因，我们不详解程序代码，有兴趣的同学可以自行研究，Kubernetes是怎么样将前面yaml中给定的参数传递到vsphere系统中的。

实际上，https://github.com/kubernetes/kubernetes/blob/master/pkg/volume/vsphere_volume/这个目录，我们可以视为vsphere为kubernetes提供的驱动程序。无论是通过PV静态创建卷，还是通过StorageClass动态分配卷，kubernetes最终都会调用这些驱动程序，操纵vsphere实现目的。

那么，如果我们引入了一款新的存储，比如腾讯云的CBS (Cloud Block Storage)，怎么样能让Kubernetes可以通过PV或StorageClass创建卷呢？

这个问题我们留到下一期详细解读