Kubernetes系统平台下Pod数据卷动态挂载方法及装置

技术领域

本申请涉及Pod数据卷动态挂载技术领域，具体涉及一种Kubernetes系统平台下Pod数据卷动态挂载方法及装置。

背景技术

目前，在Kubernetes系统平台下，通常使用hostPath、PV和PVC等技术来解决Kubernetes中Pod的数据卷(即volume)的静态供给需求，使用StorageClass和CSI等技术及组件来解决数据卷的动态供给需求。

无论是静态供给还是动态供给，数据卷总是在Pod启动前准备就绪，而Pod也一定是在数据卷就绪后，才能顺利在计算节点启动并运行。这符合Kubernetes系统平台的现有设计，也符合从早期docker容器到KubernetesPod的技术演进，即容器运行时一旦启动容器，容器内将无法挂载新的数据卷。这一设计的合理性在于，就通常而言，容器内的进程一旦启动，就无需加载新的“本地”数据，无论是文件存储还是块设备，其中，所谓“本地”指的是容器内。

但是，在实际生产中，难免遇到一些并非面向云原生的应用，它们可以在应用进程不重启的情况下，重新加载、读取“本地”数据，而应用在不重启的情况下加载新的数据卷也往往是一些容器平台用户所希望的。

这种不重启应用就加载“本地”数据的需求在Kubernetes系统平台中无法得到满足。因为应用不重启，就意味着KubernetesPod不能重启，而Pod无法在不重新创建的情况下加载新的数据卷。

综上可知，在Kubernetes的现有设计和实现下，想要支持Pod数据卷的动态挂载，可能的方案是由Kubernetes平台管理员允许用户的Pod以hostPath方式挂载计算节点上的系统路径，然后当用户需要时，再将数据卷按网络文件系统的方式挂载到计算节点的系统路径上。但这种方案，面临极大的风险和维护成本，即需要平台管理员将计算节点的部分文件系统细节暴露给容器用户，以及需要平台管理员监督并维护计算节点上的系统路径的使用，以避免多租户场景下不同用户数据卷挂载的可能冲突，还要及时清理数据卷。

发明内容

为此，本申请提供一种Kubernetes系统平台下Pod数据卷动态挂载方法及装置，以解决现有技术存在的用户在Kubernetes系统平台上为Pod动态挂载数据卷时，会暴露平台细节以及维护成本较高的问题。

为了实现上述目的，本申请提供如下技术方案：

第一方面，一种Kubernetes系统平台下Pod数据卷动态挂载方法，包括：

接收用户在控制平面创建的Pod；用户在创建所述Pod时，在所述Pod的元数据annotations字段中写入特定的字符串键值对；

接收用户在控制平面创建的CRD；所述CRD动态建立所述Pod与数据卷之间的动态挂载关系；

通过CRDoperator自动向所述Pod的元数据annotations字段中注入hostPath设置，并更新到所述Pod的元数据annotations字段中；

将更新后的所述Pod的元数据annotations字段通过kube-apiserver通知到监听所述Pod的计算平面；所述计算平面监听到更新后的所述Pod的元数据annotations字段后为所述Pod进行所述数据卷的动态挂载。

作为优选，所述用户在控制平面创建所述Pod时，若设置了hostPath，并且相关路径与所述CRDoperator注入的路径重叠或冲突时，所述CRDoperator会阻止用户创建Pod。

作为优选，所述数据卷为用户在控制平面创建的新数据卷或复用的已有的数据卷。

作为优选，所述计算平面通过CSI-sidecar监听Pod的元数据annotations字段是否更新。

作为优选，所述CSI-sidecar采用监听kube-apiserver的方式。

作为优选，所述CSI-sidecar监听到更新后的所述Pod的元数据annotations字段后为所述Pod进行所述数据卷的动态挂载，具体包括：

若所述Pod被标记为删除，则清理当前节点上特定文件系统路径下的所述Pod相关的已挂载数据卷；

将所述Pod的元数据annotations字段中的字符串键值对信息与当前节点特定文件系统路径下的数据卷挂载记录做对比；

若已有的挂载记录中缺少所述Pod的元数据annotations字段中描述的挂载信息，则为所述Pod进行挂载；

若所述Pod的元数据annotations字段中没有对现存挂载记录的描述，则清除相应的挂载。

第二方面，一种Kubernetes系统平台下Pod数据卷动态挂载装置，包括：

接收模块，用于接收用户在控制平面创建的Pod；用户在创建所述Pod时，在所述Pod的元数据annotations字段中写入特定的字符串键值对；

以及接收用户在控制平面创建的CRD；所述CRD动态建立所述Pod与数据卷之间的动态挂载关系；

注入模块，用于通过CRDoperator自动向所述Pod的元数据annotations字段中注入hostPath设置，并更新到所述Pod的元数据annotations字段中；

通知模块，用于将更新后的所述Pod的元数据annotations字段通过kube-apiserver通知到监听所述Pod的计算平面；所述计算平面监听到更新后的所述Pod的元数据annotations字段后为所述Pod进行所述数据卷的动态挂载。

第三方面，一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现Kubernetes系统平台下Pod数据卷动态挂载方法的步骤。

第四方面，一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现Kubernetes系统平台下Pod数据卷动态挂载的步骤。

相比现有技术，本申请至少具有以下有益效果：

本申请提供了一种Kubernetes系统平台下Pod数据卷动态挂载方法及装置，方法包括：接收用户在控制平面创建的Pod；用户在创建Pod时，在Pod的元数据annotations字段中写入特定的字符串键值对；接收用户在控制平面创建的CRD；CRD动态建立Pod与数据卷之间的动态挂载关系；通过CRDoperator自动向Pod的元数据annotations字段中注入hostPath设置，并更新到Pod的元数据annotations字段中；将更新后的Pod的元数据annotations字段通过kube-apiserver通知到监听Pod的计算平面；计算平面监听到更新后的Pod的元数据annotations字段后为Pod进行数据卷的动态挂载。本申请提供的Kubernetes系统平台下Pod数据卷动态挂载方法及装置，避免了容器平台中计算节点对容器用户的暴露，降低了容器平台管理员的维护成本和容器用户的实用成本。

附图说明

为了更直观地说明现有技术以及本申请，下面给出几个示例性的附图。应当理解，附图中所示的具体形状、构造，通常不应视为实现本申请时的限定条件；例如，本领域技术人员基于本申请揭示的技术构思和示例性的附图，有能力对某些单元(部件)的增/减/归属划分、具体形状、位置关系、连接方式、尺寸比例关系等容易作出常规的调整或进一步的优化。

图1为本申请实施例一提供的一种Kubernetes系统平台下Pod数据卷动态挂载方法流程图；

图2为本申请实施例一提供的一种Kubernetes系统平台下Pod数据卷动态挂载方法的逻辑示意图；

图3为本申请实施例一提供的CRDSpec的伪代码。

具体实施方式

以下结合附图，通过具体实施例对本申请作进一步详述。

在本申请的描述中：除非另有说明，“多个”的含义是两个或两个以上。本申请中的术语“第一”、“第二”、“第三”等旨在区别指代的对象，而不具有技术内涵方面的特别意义(例如，不应理解为对重要程度或次序等的强调)。“包括”、“包含”、“具有”等表述方式，同时还意味着“不限于”(某些单元、部件、材料、步骤等)。

本申请中所引用的如“上”、“下”、“左”、“右”、“中间”等的用语，通常是为了便于对照附图直观理解，而并非对实际产品中位置关系的绝对限定。在未脱离本申请揭示的技术构思的情况下，这些相对位置关系的改变，当亦视为本申请表述的范畴。

实施例一

本实施例提供了一种Kubernetes系统平台下Pod数据卷动态挂载方法，在该方法中，用户只能接触到整个平台的控制平面。用户可以在控制平面操作Volume(即数据卷)、Pod和一种新的CRD(即CustomResourceDefinition，是Kubernetes所支持的一种用于引入第三方资源的扩展模式)，该CRD负责动态建立数据卷与Pod之间的动态挂载关系。

请参阅图1和图2，方法包括：

S1：接收用户在控制平面创建的Pod；用户在创建Pod时，在Pod的元数据annotations字段中写入特定的字符串键值对；

具体的，首先，对于运行中的Pod，修改其Spec中的可变属性会导致当前运行的Pod被销毁，然后按照新的Spec定义创建新的Pod；但是修改Pod元数据部分的标签(即labels)和注解(即annotations)则不会引起Pod的销毁重建。

其次，Pod对象本身是控制平面与计算平面的主要交互信息。当一个Pod需要做数据卷的动态挂载时，为了能让必要信息由控制平面以符合原生的方式传递到计算平面，将数据卷的信息以及挂载点的信息加入到Pod中就成了不二选择。

因此，当用户提交了数据卷到Pod的绑定关系，即动态挂载请求时，需要有一个组件向相关的用户Pod的annotations中注入底层组件可识别的、用于挂载数据卷的必要信息。以此，即达到了传递信息的目的，又避免了对运行中的Pod的影响，避免其被销毁重建。相对而言，不考虑采用labels是因为在Kubernetes系统内，labels广泛用于资源的筛选，具有管理属性。

S2：接收用户在控制平面创建的CRD；CRD动态建立Pod与数据卷之间的动态挂载关系；

具体的，本实施例引入CRD来描述数据卷与Pod之间的动态挂载关系，而非直接让用户在Pod的annotations中写入相关动态挂载信息，是为了降低用户使用成本，以及提高容器平台的整体自动化水平。利用CRD，可以便捷的描述数据卷与Pod之间，多对多的动态绑定关系，以及降低对这些复杂关系的管理。

S3：通过CRDoperator自动向Pod的元数据annotations字段中注入hostPath设置，并更新到Pod的元数据annotations字段中；

具体的，在现有技术的条件下，本实施例并不会凭空将数据卷挂载到已经运行容器的，仍是采用了背景技术中提到的hostPath方式。但区别在于本实施例中，hostPath方式的数据卷用法并不需要用户在创建Pod时指定，而是由CRDoperator(即CRD的控制器)的内部实现会为用户的Pod自动注入必要的hostPath设置。用户需要在创建Pod时，在annotations中加入特定的字符串键值对以开启该功能，也即告诉本实施例方法所涉及的实现，在Pod的后续运行中，可以为其动态加载数据卷。此外，当用户在创建Pod时，如果设置了hostPath，并且相关路径与CRDoperator所注入的路径重叠或冲突时，CRD operator的实现还会阻止这样的用户Pod创建，以保持容器平台整体的一致性和可维护性。

S4：将更新后的Pod的元数据annotations字段通过kube-apiserver通知到监听Pod的计算平面；计算平面监听到更新后的Pod的元数据annotations字段后为Pod进行所述数据卷的动态挂载。

具体的，在计算平面，本实施例方法引入了一个CSI-sidecar组件。CSI是Kubernetes系统下，在计算节点上负责Pod数据卷挂载的组件，而sidecar则是Pod的一种使用模式，即向Pod中加入用于辅助功能的容器，以实现Pod中主容器能力的扩展。

CSI-sidecar作为CSI的补充，主要负责监听(watch)与当前所在节点相关的Pod对象的变化，如果Pod元数据中出现了数据卷动态挂载相关的信息，则为该Pod进行数据卷的动态挂载。

CSI-sidecar采用监听kube-apiserver的方式，与计算节点核心组件kubelet监听kube-apiserver的方式是一致的。该方式降低了Kubernetes系统平台的复杂性，以及kube-apiserver的压力。

本实施例方法没有考虑将动态挂载这一功能用独立的组件实现，是为了避免额外组件带来的平台复杂度；当使用sidecar模式时，天然地，Pod数据卷的静态挂载和动态挂载都将使用相同的容器平台后端存储，并且数据卷绑定到当前节点，以及数据卷的挂载也将采用相同的实现方式。因而这一设计也减小了不同的容器存储支持团队在开发静态挂载和动态挂载时的工作负担。

更具体的，当计算平面的kubelet监听到CRDoperator自动向annotations中具有特定字符串键值对的Pod注入hostPath设置时，会将计算节点本地的特定文件系统路径挂载到容器中。而没有被CRDoperator所处理，以及用户自己也没有设置hostPath的Pod，kubelet则不会为其进行文件系统路径的挂载操作。

当CSI-sidecar监听到与当前节点相关的Pod发生了annotations中动态挂载相关的信息变化时，会对相应的Pod进行处理：

如果Pod被标记为删除，则清理当前节上特定文件系统路径下的、该Pod相关的已挂载数据卷；

将Podannotations中键值对信息与当前节点特定文件系统路径下的数据卷挂载记录做对比，如果已有的挂载记录中缺少Podannotations中描述的挂载信息，则为Pod进行挂载；如果Podannotations中没有对现存挂载记录的描述，则清除相应的挂载。

请参阅图3，图3是描述本实施例方法中涉及的CRDSpec的伪代码描述。其中，用户可以在volumes字段下描述多个数据卷，需要写入必要的数据卷供给服务器的地址以及数据卷的ID等必要信息；同时，用户可以在mounts字段下描述这些定义在当前CRDSpec下的数据卷要挂载到哪些Pods下，需要写入必要信息包括数据卷挂载后的目录名或设备名，以及如何找到这些Pods。CRDSpec采用Kubernetes原生支持的labelSelector机制来进行对Pods的遴选。用户可以写入多组selector来选择Pods，如果这些Pods处于不同的Kubernetesnamespace下，或者这些Pods处于相同的Kubernetesnamespace下，但是它们具有不同的labels。采用这种方式，是的同时为多组Pods进行数据卷的动态挂载成为可能。

本实施例提供的Kubernetes系统平台下Pod数据卷动态挂载方法，结合了现有Kubernetes系统所支持的原生技术手段，避免了额外的消息队列、数据库等分布式系统常用技术方案。所采用的方式方法，能以非侵入式的手段来为Kubernetes系统平台提供Pod数据卷动态挂载的能力，不涉及对Kubernetes源代码的修改，并且所引入的必要实现组件均可以在当前的Kubernetes主流版本中得到支持。

本实施例提供的Kubernetes系统平台下Pod数据卷动态挂载方法，避免了容器平台中计算节点对容器用户的暴露，使得后者可以在不了解计算节点文件系统信息的情况下，使用Kubernetes提供的hostPath方式。而对于容器平台管理员而言，降低了平台的维护成本，保证了平台的一致性；对容器用户而言，采用CRD来支持数据卷与Pod之间的动态挂载关系，在CRDSpec中，用户可以定义数据卷与Pod之间的多对多关系，降低了用户的使用成本。

本实施例提供的Kubernetes系统平台下Pod数据卷动态挂载方法，弥补了现有Kubernetes系统下，对Pod提供数据卷动态挂载的缺失。使得用户Pod可以在运行期间，动态挂载新的数据卷。而相比于现有实现，用户Pod想要挂载新的数据卷，则必须销毁当前的Pod，然后使用新的PodSpec才能达到。并且受限于Kubernetes的工作负载模型，例如Deployment,，StatefulSet等，当用户想要为多组Pod挂载相同的数据卷时，就必须分别修改这些工作负载对象，例如分别修改多组Pod对应的Deployment和/或StatefulSet等。而利用本实施例中的CRD，则只需要修改一个CRD对象，就可以同时为多组Pod进行数据卷的动态挂载。

实施例二

本实施例提供了一种Kubernetes系统平台下Pod数据卷动态挂载装置，包括：

接收模块，用于接收用户在控制平面创建的Pod；用户在创建Pod时，在Pod的元数据annotations字段中写入特定的字符串键值对；

以及接收用户在控制平面创建的CRD；CRD动态建立Pod与数据卷之间的动态挂载关系；

注入模块，用于通过CRDoperator自动向Pod的元数据annotations字段中注入hostPath设置，并更新到Pod的元数据annotations字段中；

通知模块，用于将更新后的Pod的元数据annotations字段通过kube-apiserver通知到监听Pod的计算平面；计算平面监听到更新后的Pod的元数据annotations字段后为Pod进行数据卷的动态挂载。

实施例三

本实施例提供了一种计算机设备，包括存储器和处理器，存储器存储有计算机程序，处理器执行计算机程序时实现Kubernetes系统平台下Pod数据卷动态挂载方法的步骤。

实施例四

本实施例提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现Kubernetes系统平台下Pod数据卷动态挂载方法的步骤。

关于Kubernetes系统平台下Pod数据卷动态挂载装置的具体限定可以参见上文中对于Kubernetes系统平台下Pod数据卷动态挂载方法的限定，在此不再赘述。

以上实施例的各技术特征可以进行任意的组合(只要这些技术特征的组合不存在矛盾)，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述；这些未明确写出的实施例，也都应当认为是本说明书记载的范围。

上文中通过一般性说明及具体实施例对本申请作了较为具体和详细的描述。应当理解，基于本申请的技术构思，还可以对这些具体实施例作出若干常规的调整或进一步的创新；但只要未脱离本申请的技术构思，这些常规的调整或进一步的创新得到的技术方案也同样落入本申请的权利要求保护范围。