智汇华云|Kubernetes特性-In-Tree to CSI Volume Migration

Kubernetes是云计算发展演进的一次彻底革命性的突破。如今，已经有越来越多的企业逐渐接受并将自己的核心业务系统迁移到Kubernetes平台。本期智汇华云，华云数据为大家带来Kubernetes特性——In-Tree to CSI Volume Migration。

背景

In-tree

kubernetes早期通过in-tree的方式来为容器提供存储，in-tree可以理解为对接外部存储的plugin的代码集成在kubernetes中，在k8s的代码目录里面我们可以看到大量的关于外部存储的plugin集成的代码k8s.io/pkg/volume。可以通过in-tree的代码与这些外部存储进行对接，这些plugin提供了volume的create/delete/attach/detach/mount/unmount/recyle以及卷监控等volume的管理。In-tree支持20+种volume plugin，例如比较常用的iscsi/nfs/fc/ceph/azure/aws/gce/glusterfs/openstack等等。

CSI

In-tree的方式对于新增一种volume plugin变得很困难，厂商期望在kubernetes中新支持一种volume plugins需要考虑kubernetes的发布过程，另外第三方存储的代码在kubernetes仓库中对于kubernetes稳定性以及测试和维护带来了挑战。所以kubernetes社区提出了CSI规范用于更好的支持其他厂商的外部存储。

CSI定义了一套接口规范，各个外部厂商可以根据自身存储开发自身的CSIDriver插件，来完成对于整个卷生命周期的管理。引入对 CSI 驱动的支持，使得 Kubernetes 和存储后端技术之间的集成工作更易建立和维护，集群管理员可以只选择集群需要的存储驱动。

CSI Volume Migration

CSI Volume Migration特性是支持in-tree定义的PVC&PV资源对象对应的功能可以由外部的对应的CSI插件来替代完成，例如之前集群中使用provision=kubernetes.io/cinder创建的pvc以及pv对象卷的生命周期管理可以由Cinder CSI Plugin来完成，而不是之前in-tree来完成。

为什么需要引入CSI Volume Migration

In-tree方式过渡到csi方式对接外部存储：csi driver越来越普遍以及成熟，可以替代in-tree的方式，对于存储插件的开发者，减少维护in-tree方式的插件，并最终将这些插件从kubernetes仓库的代码中移除。

平滑的过渡：迁移到CSI driver的方式，而不破坏与现有存储 API 类型的 API 兼容性。由特性来实现将in-tree存储 API 翻译成等效的 CSI API，将操作委托给一个替换的 CSI 驱动来完成。之前创建的in-tree的PV/PVC对象可以继续工作，只是实际的工作由in-tree的逻辑实现替代成CSI来驱动完成。未来计划将在 Kubernetes v1.26 和 v1.27 之前移除云提供商提供的in-tree存储插件的代码。

//CSI migrate各个plugin的最新的进展

怎么使用CSI Volume Migration特性

打开CSIMigration以及CSIMigration{provider}的特性开发（1.17）,{provider}是in-tree的cloud provider storage type.

打开InTreePlugin{provider}Unregister，该feature是可注销参数名称中 {provider} 部分所指定的in-tree存储插件。InTreePlugin{provider}Unregister 是一种特性，可以独立于 CSI 迁移功能来启用或禁用。当启用此种特性时，组件将不会把相应的in-tree存储插件注册到支持的列表中。如果集群操作员只启用了这种参数，终端用户将在使用该插件的 PVC时会遇到错误，提示其找不到插件。如果集群操作员不想支持过时的in-tree存储 API，只支持 CSI，那么他们可能希望启用这种特性。在k8s 1.21之前这个feature名称是CSIMigration{provider}Complete，在v1.21版本弃用了CSIMigration{provider}Complete,而是改用InTreePlugin{vendor}Unregister，功能上二者是一致的。

安装对应的csi driver

以openstack-cinder in-tree为例演示

在kubernetes 1.22版本上需要打开如下三个特性

K8s.io/Kubernetes/pkg/features/kube_features.go

// Enables the in-tree storage to CSI Plugin migration feature.

CSIMigration featuregate.Feature = "CSIMigration"

// Enables the OpenStack Cinder in-tree driver to OpenStack Cinder CSI Driver migration feature.

CSIMigrationOpenStack featuregate.Feature = "CSIMigrationOpenStack"

// Disables the OpenStack Cinder in-tree driver.

InTreePluginOpenStackUnregister featuregate.Feature = "InTreePluginOpenStackUnregister"

安装cinder-csi-plugin

查看csinodes，存在annotations

之后创建一个in-tree的pvc，查看cinder-csi-plugin日志，是否是由cinder-csi来完成

如何实现CSI Volume Migration

kubernetes 1.22代码分析主要是针对每个in-tree的插件实现type InTreePlugin interface k8s.io/Kubernetes/staging/src/k8s.io/csi-translation-lib/plugins/in_tree_volume.go

之后在原有的卷调度以及卷生命周期管理的时候，通过各个plugin提供的TranslateInTreexxx函数转换成CSI对象，按照CSI对象的操作流程进行操作。如果是支持迁移的卷类型，则原来的流程将会被忽略。下面是volume调度策略node-limit来看CSI mirgrate特性是如何让用户无感知的迁移的

Nodevolumelimits调度策略主要是限制单个node上相同类型的卷的数量不能超过一定的数量，可以在CSINode里面定义数量的大小。Nodevolumelimits-plugin代码的位置在k8s.io/Kubernetes/pkg/scheduler/framework/plugins/nodevolumelimits/csi.go

Filter（）

filterAttachableVolumes

pl.getCSIDriverInfo(csiNode, pvc)中

获取pvc in-intree对应的csi对象。之后Nodevolumelimits-plugin中去判断node所在的in-tree或者csi对象总的volume的数量有没有超过limit的限制。

总结

CSIMigration可以使得in-tree的pvc&pv可以由csi来管理，但是卷的管理能力只仅限于in-tree本身具备的一些能力，csi中具有的一些高级的功能，例如snapshot等，是没有办法针对in-tree的pvc&pv来进行操作的。

截止k8s 1.24 release，CSIMigration特性处于beta状态，目前支持migration的in-tree插件有GCE/AWS/AzureDisk/AzureFile/vSphere/Openstack/RBD/Portworx，可以看出将所有in-tree的代码从kubernetes代码中剥离出来仍然还有很多工作要做，并且CSIMigration特性引入了很多过渡的代码。同时思考是否可以通过直接convert将in-tree的pvc、pv对象直接转化成csi规范的对象，是不是也是一种更好的思路。