智汇华云|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来完成

apiVersion: storage.k8s.io/v1

kind: StorageClass

metadata:

name: csi-sc-cinderplugin

provisioner: kubernetes.io/cinder

---

apiVersion: v1

kind: PersistentVolumeClaim

metadata:

name: csi-pvc-cinderplugin

spec:

accessModes:

- ReadWriteOnce

resources:

requests:

storage: 1Gi

storageClassName: csi-sc-cinderplugin

---

apiVersion: v1

kind: Pod

metadata:

name: nginx

spec:

nodeSelector:

kubernetes.io/hostname: node4

containers:

- image: nginx

imagePullPolicy: IfNotPresent

name: nginx

ports:

- containerPort: 80

protocol: TCP

volumeMounts:

- mountPath: /var/lib/www/html

name: csi-data-cinderplugin

volumes:

- name: csi-data-cinderplugin

persistentVolumeClaim:

claimName: csi-pvc-cinderplugin

readOnly: false

如何实现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

// InTreePlugin handles translations between CSI and in-tree sources in a PV

type InTreePlugin interface {

// TranslateInTreeStorageClassToCSI takes in-tree volume options

// and translates them to a volume options consumable by CSI plugin

TranslateInTreeStorageClassToCSI(sc *storage.StorageClass) (*storage.StorageClass, error)

// TranslateInTreeInlineVolumeToCSI takes a inline volume and will translate

// the in-tree inline volume source to a CSIPersistentVolumeSource

// A PV object containing the CSIPersistentVolumeSource in it's spec is returned

// podNamespace is only needed for azurefile to fetch secret namespace, no need to be set for other plugins.

TranslateInTreeInlineVolumeToCSI(volume *v1.Volume, podNamespace string) (*v1.PersistentVolume, error)

// TranslateInTreePVToCSI takes a persistent volume and will translate

// the in-tree pv source to a CSI Source. The input persistent volume can be modified

TranslateInTreePVToCSI(pv *v1.PersistentVolume) (*v1.PersistentVolume, error)

// TranslateCSIPVToInTree takes a PV with a CSI PersistentVolume Source and will translate

// it to a in-tree Persistent Volume Source for the in-tree volume

// by the `Driver` field in the CSI Source. The input PV object can be modified

TranslateCSIPVToInTree(pv *v1.PersistentVolume) (*v1.PersistentVolume, error)

// CanSupport tests whether the plugin supports a given persistent volume

// specification from the API.

CanSupport(pv *v1.PersistentVolume) bool

// CanSupportInline tests whether the plugin supports a given inline volume

// specification from the API.

CanSupportInline(vol *v1.Volume) bool

// GetInTreePluginName returns the in-tree plugin name this migrates

GetInTreePluginName() string

// GetCSIPluginName returns the name of the CSI plugin that supersedes the in-tree plugin

GetCSIPluginName() string

// RepairVolumeHandle generates a correct volume handle based on node ID information.

RepairVolumeHandle(volumeHandle, nodeID string) (string, error)

}

之后在原有的卷调度以及卷生命周期管理的时候,通过各个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)中

csiSource := pv.Spec.PersistentVolumeSource.CSI

if csiSource == nil {

// We make a fast path for non-CSI volumes that aren't migratable

if !pl.translator.IsPVMigratable(pv) {

return "", ""

}

pluginName, err := pl.translator.GetInTreePluginNameFromSpec(pv, nil)

if err != nil {

klog.V(5).InfoS("Unable to look up plugin name from PV spec", "err", err)

return "", ""

}

if !isCSIMigrationOn(csiNode, pluginName) {

klog.V(5).InfoS("CSI Migration of plugin is not enabled", "plugin", pluginName)

return "", ""

}

csiPV, err := pl.translator.TranslateInTreePVToCSI(pv)

if err != nil {

klog.V(5).InfoS("Unable to translate in-tree volume to CSI", "err", err)

return "", ""

}

if csiPV.Spec.PersistentVolumeSource.CSI == nil {

klog.V(5).InfoS("Unable to get a valid volume source for translated PV", "PV", pvName)

return "", ""

}

csiSource = csiPV.Spec.PersistentVolumeSource.CSI

}

获取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规范的对象,是不是也是一种更好的思路。

(免责声明:本网站内容主要来自原创、合作伙伴供稿和第三方自媒体作者投稿,凡在本网站出现的信息,均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性,但不保证有关资料的准确性及可靠性,读者在使用前请进一步核实,并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏,概不负任何法律责任。
任何单位或个人认为本网站中的网页或链接内容可能涉嫌侵犯其知识产权或存在不实内容时,应及时向本网站提出书面权利通知或不实情况说明,并提供身份证明、权属证明及详细侵权或不实情况证明。本网站在收到上述法律文件后,将会依法尽快联系相关文章源头核实,沟通删除相关内容或断开相关链接。 )