基于Kubernetes的轨道交通软件应用调度方法

摘要

本发明提供一种基于Kubernetes的轨道交通软件应用调度方法，包括：根据需要布设的各轨道交通软件应用的运行程序，构建各轨道交通软件应用的各对应容器镜像，并发送至Kubernetes服务器集群中master主机；采用Kubernetes副本控制器对象从master拉取各轨道交通软件应用的各对应容器镜像；基于当前所属轨道交通环境和各对应容器镜像采用Kubernetes副本控制器在Kubernetes服务器集群内部署容器化的各轨道交通软件应用。本发明提供的方法，实现硬件资源高利用率和软件高效运行，降低人力成本，解除轨道交通软件应用与硬件之间强耦合，达到软件和硬件的快速平滑升级和扩容的目标。

说明书

技术领域

本发明涉及轨道交通软件应用调度技术领域，尤其涉及一种基于Kubernetes的轨道交通软件应用调度方法。

背景技术

城市轨道交通已成为一座发达城市不可或缺的组成部分。随着智能化技术的发展，各类智能软件技术开始运用到了城市轨道交通的运营与维护方面。但是，由于城市轨道智能化技术还处于发展阶段，智能软件应用的稳定性还有待提高，同时，随着时间的推移，轨道线路产生的庞大数据量会对原有软硬件的正常运行带来考验。因此，在轨道交通智能软件应用平台上引用Kubernetes容器化编排管理技术，能够有效保障软件运行与升级过渡的稳定性。除此之外，Kubernetes容器化编排管理技术还提供了硬件集群接口，这也为后期硬件更换、扩容、软件在节点之间的调度提供了便利，缓解了大数据量对软硬件带来的冲击，进一步保障了城市轨道交通日常的安全运行。

之前，对于一般的城市轨道软件应用技术，存在以下缺陷：

(一)传统的城市轨道软件应用直接部署到服务器上，一般一台主机只能部署1或2个软件应用以防止软件进程之间的干扰，虽然这种做法能够保证各软件的安全运作，但是这将会对服务器资源造成一定的浪费，加大了成本投入。

(二)传统的城市轨道软件应用如果出现故障，需要运维人员做出快速反应进行检查与修复，这种对运维人员的强依赖性十分不利于城市轨道交通软件的智能化发展，它既增加了运维人员的工作压力，也增加了城市轨道交通的运行风险。

(三)传统的城市轨道软件应用一旦部署至某台服务器上，就会对该台服务器的环境和资源产生强依赖性，很难进行迁移扩展工作。

(四)当服务器部件出现故障或数据量庞大时，服务器硬件的更换和升级扩容都会进入及其复杂的工作流程，这可能会导致软件的卸载与重装，需要的人力与时间都是在轨道交通安全运行时无法允许的，因此升级工作只能在非运营时间段进行，升级工作时间段限制较大。

因此，如何避免现有的城市轨道软件应用直接部署到服务器时，由于不同进程之间的相互干扰，造成的硬件资源的浪费，人力成本高，由于对服务器的环境和资源的强依赖，造成的难以迁移扩展以及由于数据量庞大造成的升级扩容耗时长，仍然是本领域技术人员亟待解决的问题。

发明内容

本发明提供一种基于Kubernetes的轨道交通软件应用调度方法，用以解决现有的城市轨道软件应用直接部署到服务器时，由于不同进程之间的相互干扰，造成的硬件资源的浪费，人力成本高，由于对服务器的环境和资源的强依赖，造成的难以迁移扩展以及由于数据量庞大造成的升级扩容耗时长的缺陷，通过在服务器集群上布设Kubernetes容器化编排管理应用，实现服务器集群上安装的各轨道交通软件应用通过进行Kubernetes容器化布设后实现硬件资源的高利用率和软件高效运行，降低人力成本，解除轨道交通软件应用与硬件之间的强耦合，达到软件和硬件的快速平滑升级和扩容的目标。

本发明提供一种基于Kubernetes的轨道交通软件应用调度方法，该方法包括：

根据需要布设的各轨道交通软件应用的运行程序，构建所述各轨道交通软件应用的各对应容器镜像，并发送至Kubernetes服务器集群中的master主机；

采用Kubernetes副本控制器对象从所述master主机拉取所述各轨道交通软件应用的各对应容器镜像；

基于当前所属轨道交通环境和所述各对应容器镜像，采用Kubernetes副本控制器，在所述Kubernetes服务器集群内部署容器化的各轨道交通软件应用。

根据本发明提供的一种基于Kubernetes的轨道交通软件应用调度方法，所述基于当前所属轨道交通环境和所述各对应容器镜像，采用Kubernetes副本控制器，在所述Kubernetes服务器集群内部署容器化的各轨道交通软件应用，包括：

采用Kubernetes副本控制器从所述master主机中拉取所述各对应容器镜像，确定所述各轨道交通软件应用对应的单体pod对象；

所述Kubernetes副本控制器基于当前所属轨道交通环境确定各单体pod对象的数量，基于所述数量对所述单体pod对象进行复制创建；

其中，所述Kubernetes副本控制器的属性文件中包括预先写入所述master主机地址。

根据本发明提供的一种基于Kubernetes的轨道交通软件应用调度方法，若任一轨道交通软件应用为调用组件类型，则创建所述任一轨道交通软件应用的Kubernetes副本控制器的属性文件为deployment.yaml属性文件；

若任一轨道交通软件应用为查看状态类型，则创建所述任一轨道交通软件应用的Kubernetes副本控制器的属性文件为statefulSet.yaml属性文件。

根据本发明提供的一种基于Kubernetes的轨道交通软件应用调度方法，所述当前所属轨道交通环境包括当前所属轨道中采集设备个数、所述采集设备需要采集的物理参数类型个数和所述采集设备采集上报频率中至少一种。

根据本发明提供的一种基于Kubernetes的轨道交通软件应用调度方法，还包括：

构建所述Kubernetes服务器集群的网关对象ambassador；

其中，所述网关对象ambassador用于为所述各轨道交通软件应用提供统一的软件访问入口。

根据本发明提供的一种基于Kubernetes的轨道交通软件应用调度方法，所述构建所述Kubernetes服务器集群的网关对象ambassador，包括：

编辑所述Kubernetes服务器集群的网关对象ambassador的副本控制器属性文件ambassador-deployment.yaml和服务属性文件ambassador-service.yaml，所述ambassador-deployment.yaml中写入所述统一的软件访问入口IP地址，所述ambassador-service.yaml中写入各轨道交通软件应用的port号。

根据本发明提供的一种基于Kubernetes的轨道交通软件应用调度方法，还包括：

当所述各轨道交通软件应用需要消除异常或软件升级时，所述Kubernetes服务器集群中各功能对象基于实时监测的所述各轨道交通软件应用的健康度和硬件节点可用资源调度，调度所述单体pod对象的分布；

当所述Kubernetes服务器集群需要扩容时，基于sealos安装工具中的sealosjoin–master命令或sealos join–node命令将新服务器加入所述Kubernetes服务器集群。

本发明还提供一种基于Kubernetes的轨道交通软件应用调度装置，包括：

构建单元，用于根据需要布设的各轨道交通软件应用的运行程序，构建所述各轨道交通软件应用的各对应容器镜像，并发送至Kubernetes服务器集群中的master主机；

拉取单元，用于采用Kubernetes副本控制器对象从所述master主机拉取所述各轨道交通软件应用的各对应容器镜像；

部署单元，用于基于当前所属轨道交通环境和所述各对应容器镜像，采用Kubernetes副本控制器，在所述Kubernetes服务器集群内部署容器化的各轨道交通软件应用。

本发明还提供一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现如上述任一种所述的基于Kubernetes的轨道交通软件应用调度方法的步骤。

本发明还提供一种非暂态计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现如上述任一种所述的基于Kubernetes的轨道交通软件应用调度方法的步骤。

本发明提供的基于Kubernetes的轨道交通软件应用调度方法，通过根据需要布设的各轨道交通软件应用的运行程序，构建所述各轨道交通软件应用的各对应容器镜像，并发送至Kubernetes服务器集群中的master主机；采用Kubernetes副本控制器对象从所述master主机拉取所述各轨道交通软件应用的各对应容器镜像；基于当前所属轨道交通环境和所述各对应容器镜像，采用Kubernetes副本控制器，在所述Kubernetes服务器集群内部署容器化的各轨道交通软件应用。由于在服务器集群上布设Kubernetes容器化编排管理应用，而且各轨道交通软件应用在Kubernetes服务器集群上布设时还需要考虑当前所属轨道交通环境，判定各软件应用需要处理的数据量是否大，在基于数据量决定各轨道交通软件应用布设时占用的资源量，因此，使用Kubernetes容器化编排管理应用不仅能够解除软件与硬件之间的强耦合，降低人工成本，还能基于各软件应用所运行的环境中的数据量大小进行Kubernetes容器资源的合理分配。因此，本发明提供的方法，实现了硬件资源的高利用率和软件高效运行，降低人力成本，解除轨道交通软件应用与硬件之间的强耦合，达到软件和硬件的快速平滑升级和扩容的目标。

附图说明

为了更清楚地说明本发明或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明提供的基于Kubernetes的轨道交通软件应用调度方法的流程示意图；

图2为本发明提供的statefulSet.yaml属性文件的代码示例图；

图3为本发明提供的基于Kubernetes的轨道交通软件应用调度装置的结构示意图；

图4为本发明提供的基于Kubernetes容器化编排管理的轨道交通智能软件应用运维调度技术总体设计图；

图5为本发明提供的网关对象用于处理软件应用的属性文件示例图；

图6为本发明提供的一种电子设备的实体结构示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将结合本发明中的附图，对本发明中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

现有的城市轨道软件应用直接部署到服务器时，普遍存在由于不同进程之间的相互干扰，造成的硬件资源的浪费，人力成本高，由于对服务器的环境和资源的强依赖，造成的难以迁移扩展以及由于数据量庞大造成的升级扩容耗时长的问题。下面结合图1-图2描述本发明的一种基于Kubernetes的轨道交通软件应用调度方法。图1为本发明提供的基于Kubernetes的轨道交通软件应用调度方法的流程示意图，如图1所示，该方法包括：

步骤110，根据需要布设的各轨道交通软件应用的运行程序，构建所述各轨道交通软件应用的各对应容器镜像，并发送至Kubernetes服务器集群中的master主机。

可选的，本发明提供的基于Kubernetes的轨道交通软件应用调度方法是在某一轨道交通环境中运行的各种轨道交通软件应用进行它们在服务器集群硬件上布设的方法，该轨道交通环境可能是包括多个站点的某一运行场景，也可能是某一轨道线路，还可能是包括多个轨道线路的环境，即所述某一轨道交通环境时基于服务器集群硬件性能决定的，如果硬件性能强，则可以在该服务器集群上布设大量的轨道交通软件应用，覆盖多条线路；而轨道交通环境中运行的各类轨道交通软件应用通常包括：对采集的实时信号进行统计分析风险判断的监测软件、对风险设备进行报警生成维修工单的管理软件，以及对采集的实时信号进行记录生成日志文件以供维护人员可以通过随时查看日志事件获取设备运行情况的日志软件等等。

本发明提供的方法是基于Kubernetes容器化应用中的Docker引擎实现各轨道交通软件应用的容器镜像的构建。其中，Docker引擎是一个开源的应用容器引擎，让开发者可以打包它们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的Linux机器上，也可以实现虚拟化，容器完全使用沙箱机制，互相之间不会有任何接口。

Kubernetes容器化应用中的Docker引擎包括三大组件，容器镜像、容器和镜像中央仓库。容器镜像用来创建Docker容器，一个容器镜像可以包含一个完整的操作系统环境和用户需要的其他应用程序，docker的容器镜像是可读的，一个容器镜像可以创建多个容器。容器是镜像创建的实例，它可以被启动、开始、停止、删除，每个容器都是相互隔离的，保证安全的平台。镜像中央仓库是集中存放容器镜像的场所，镜像中央仓库中包含了多个容器镜像，每个容器镜像设置有不同的标签用以区分，因此，在构建容器镜像之前，需要分析每个轨道交通软件应用的运行程序和操作系统环境，然后根据各个轨道交通软件应用的运行程序和操作系统环境按照Kubernetes容器化应用中的Docker引擎的要求，创建Dockerfile文件，Dockerfile文件是一个文本文件，其内包含了一条条的指令，每一条指令构建容器镜像的其中一层，因此每一条指令的内容，就是描述容器镜像的每层应该如何构建，然后基于Dockerfile文件在Kubernetes容器化应用的Docker引擎中通过docker build命令构建各个轨道交通软件应用对应的容器镜像，并将各个容器镜像推送至服务器集群硬件中的master主机上进行存储，具体地，是在所述master主机上安装registry应用当作Kubernetes服务器集群的镜像中央仓库，然后所述各个容器镜像被push到所述镜像中央仓库中。此处对master主机进行说明，Kubernetes服务器集群采用master-slave架构，作为决策主控功能的master主机的选取方式是筛选出服务器集群中硬件性能最强的主机作为master主机，硬件性能即综合考虑存储容量大小和CPU性能。此处还需要说明的是，创建完容器镜像后，可以选择将容器镜像存储在master主机中的镜像中央仓库也可以不存储，但是由于考虑到轨道交通软件应用的个数众多，单独进行人工部署浪费时间较多，因此，本发明中是利用Kubernetes容器管理集群实现容器镜像的部署，可以大大节约部署花费的时间。

步骤120，采用Kubernetes副本控制器对象从所述master主机拉取所述各轨道交通软件应用的各对应容器镜像。

可选的，在每台Kubernetes服务器集群中的每台主机上都创建daemon.json配置文件，并在该daemon.json配置文件内添加镜像中央仓库的地址与端口号，以确保集群中每台主机都可以访问registry应用的镜像中央仓库。此时，存储于镜像中央仓库的容器镜像相当于各个轨道交通软件应用的模版文件，每台主机要进行各个轨道交通软件应用的部署时首先要从镜像中央仓库中拉取模块，然后依照模版还有对软件计算能力需求复制创建其中的功能容器docker，而Kubernetes应用中docker被加入Kubernetes功能后封装成pod单体。此处需要说明的是，Kubernetes容器化应用是一种容器的管理平台，它将服务器硬件和轨道交通软件应用分隔开，解除前两者之间由于过耦合导致依赖性强使得软件无法移植升级，不能平滑实现硬件扩容的问题。而所述Kubernetes容器化应用作为一个管理平台，具有多个运行的节点，可以分为控制节点和工作节点，控制节点用于容器的集群管理，利用容器镜像将容器化的应用部署在工作节点，其中，这里的工作节点是指服务器集群中的主机，控制节点上也可以进行容器化的应用的部署，Kubernetes容器化应用为开源应用，用于管理服务器集群中多个主机上的容器化的应用。

步骤130，基于当前所属轨道交通环境和所述各对应容器镜像，采用Kubernetes副本控制器，在所述Kubernetes服务器集群内部署容器化的各轨道交通软件应用。

可选的，以从镜像中央仓库拉取的各轨道交通软件应用的容器镜像作为模版，提取各模版中的功能主体进行创建，例如采集数据属于功能主体A、对数据进行解析统计分析属于功能主体B，展示数据也属于一个功能主体C，而通过分析从镜像中央仓库中拉取的两个容器镜像，可以得知轨道交通软件应用1包括三个功能主体A、B和C，而轨道交通软件应用2包括两个功能主体A和B，在服务器集群中各个主机上的轨道交通软件应用的布设时，还需要考虑当前所属轨道交通环境，即环境数据(即用户期望)对每个软件应用中的某个功能主体的性能要求，例如，如果环境中的采集设备数量巨大，那么包括三个功能主体A、B和C的轨道交通软件应用1必然要承载大量采集上来的数据，因此，功能主体A和B的计算量会很大，故对它们的性能要求会非常高，因此，在用Kubernetes副本控制器进行容器化的轨道交通软件应用1的部署时，会增加复制创建的封装有A功能的pod单体的数量，也会增加复制创建的封装有B功能的pod单体的数量。Kubernetes容器化应用根据所述各轨道交通软件应用的硬件需求和功能分类，在Kubernetes服务器集群中选择满足硬件需求且同一功能分类的节点，并在这些节点上创建容器组，基于各轨道交通软件应用的容器镜像，在容器组内创建容器化的各轨道交通软件应用，这里的Kubernetes服务器集群中的各个主机都是Kubernetes容器化应用的节点，用于给Kubernetes容器化应用提供部署的基础。将各个轨道交通软件应用的容器镜像放置在容器组内，基于Kubernetes容器化应用的控制器，监控容器组的创建过程，运行状态等信息，在容器组内形成容器化的轨道交通软件应用后实现暴露应用，然后生成对外的服务接口实现通讯，完成对外发布应用，并进行应用运行的日志管理及状态监控。不同于常规的均匀分配的全自动运行，为了更好地对资源进行管理，根据各轨道交通软件应用的硬件需求和功能分类，将轨道交通软件应用部署在满足硬件需求且同一功能分类的节点，实现各轨道交通软件应用的定向运行。因此，对于上述例子中提到的包括三个功能主体A、B和C的轨道交通软件应用1，以及包括两个功能主体A和B的轨道交通软件应用2，会将多个封装功能主体A的pod单体组成功能A的容器组，并安排在一个主机上运行；同理，将多个封装功能主体B的pod单体组成功能B的容器组，并安排在一个主机上运行，将多个封装功能主体C的pod单体组成功能C的容器组，并安排在一个主机上运行；将轨道交通软件应用部署在满足硬件需求且同一功能分类的节点，实现各轨道交通软件应用的定向运行。

本发明提供的基于Kubernetes的轨道交通软件应用调度方法，通过根据需要布设的各轨道交通软件应用的运行程序，构建所述各轨道交通软件应用的各对应容器镜像，并发送至Kubernetes服务器集群中的master主机；采用Kubernetes副本控制器对象从所述master主机拉取所述各轨道交通软件应用的各对应容器镜像；基于当前所属轨道交通环境和所述各对应容器镜像，采用Kubernetes副本控制器，在所述Kubernetes服务器集群内部署容器化的各轨道交通软件应用。由于在服务器集群上布设Kubernetes容器化编排管理应用，而且各轨道交通软件应用在Kubernetes服务器集群上布设时还需要考虑当前所属轨道交通环境，判定各软件应用需要处理的数据量是否大，在基于数据量决定各轨道交通软件应用布设时占用的资源量，因此，使用Kubernetes容器化编排管理应用不仅解除软件与硬件之间的强耦合，降低人工成本，还能基于各软件应用所运行的环境中的数据量大小进行Kubernetes容器资源的合理分配。因此，本发明提供的方法，实现了硬件资源的高利用率和软件高效运行，降低人力成本，解除轨道交通软件应用与硬件之间的强耦合，达到软件和硬件的快速平滑升级和扩容的目标。

在上述实施例的基础上，该方法中，所述基于当前所属轨道交通环境和所述各对应容器镜像，采用Kubernetes副本控制器，在所述Kubernetes服务器集群内部署容器化的各轨道交通软件应用，包括：

采用Kubernetes副本控制器从所述master主机中拉取所述各对应容器镜像，确定所述各轨道交通软件应用对应的单体pod对象；

所述Kubernetes副本控制器基于当前所属轨道交通环境确定各单体pod对象的数量，基于所述数量对所述单体pod对象进行复制创建；

其中，所述Kubernetes副本控制器的属性文件中包括预先写入所述master主机地址。

可选的，编辑副本控制器属性文件deployment.yaml或statefulSet.yaml属性文件，将属性文件中的镜像拉取地址编辑为中央仓库registry宿主机地址，利用副本编辑器来创建软件应用的单体pod对象，具体地，拉取回各个轨道交通软件应用的容器镜像后，将所述容器镜像作为软件模版进行分析，提取出模版中包含的功能主体，一个功能主体对应一种类型的单体pod对象，然后，Kubernetes副本控制器基于当前所属轨道交通环境确定各单体pod对象的数量，例如轨道交通软件应用1包括三个功能主体A、B和C，采集数据属于功能主体A、对数据进行解析统计分析属于功能主体B，展示数据也属于一个功能主体C，而基于当前所属轨道交通环境获知采集设备数量巨大，那么包括三个功能主体A、B和C的轨道交通软件应用1必然要承载大量采集上来的数据，因此，功能主体A和B的计算量会很大，故对它们的性能要求会非常高，因此，在用Kubernetes副本控制器进行容器化的轨道交通软件应用1的部署时，会增加复制创建的封装有A功能的pod单体的数量，也会增加复制创建的封装有B功能的pod单体的数量。其中，在Kubernetes应用中具体的创建操作可以使用Kubernetes的命令工具kubectl的create或apply命令将Kubernetes各对象通过属性文件创建。

本发明提供的方法，进一步限定了当前所属轨道交通环境因素是如何参与在所述Kubernetes服务器集群内部署容器化的各轨道交通软件应用的，提高本发明提供的调度方法在轨道交通领域应用的特适性，为轨道交通领域的软件部署提供特有的当前所属轨道交通环境的考量因素。

在上述实施例的基础上，该方法中，若任一轨道交通软件应用为调用组件类型，则创建所述任一轨道交通软件应用的Kubernetes副本控制器的属性文件为deployment.yaml属性文件；

若任一轨道交通软件应用为查看状态类型，则创建所述任一轨道交通软件应用的Kubernetes副本控制器的属性文件为statefulSet.yaml属性文件。

可选的，若任一轨道交通软件应用为调用组件类型，即该任一轨道交通软件应用运行时需要软件中各个功能主体的相互调用和交互，即属于调用组件类型软件，例如：采集数据属于功能主体A、对数据进行解析统计分析属于功能主体B，展示数据也属于一个功能主体C，轨道交通软件应用1包括三个功能主体A、B和C，功能主体B进行分析时需要从功能主体A那里拉取采集的数据，而功能主体C进行展示时，又需要从功能主体B那里拉取经过统计分析得到的健康度或者预警信息，因此，轨道交通软件应用1为调用组件类型软件应用。则该调用组件类型的轨道交通软件应用进行其对应副本控制器的配置时，是在deployment.yaml属性文件中写入将镜像拉取地址编辑为中央仓库registry宿主机地址。而若任一轨道交通软件应用为查看状态类型，即该任一轨道交通软件应用运行时不需要功能主体之间的交互和调用，只需要通过软件读取列车运行数据或报警日志数据等等，此时都无需通过Kubernetes容器应用作为中间层进行转换，直接访问服务器集群硬件的对应存储地址然后返回即可，因此，给这类查看状态类型的轨道交通软件应用进行其对应副本控制器的配置时，是在statefulSet.yaml属性文件中写入将镜像拉取地址编辑为中央仓库registry宿主机地址。不同的属性文件体现的是不同类型软件的运行机理。图2为本发明提供的statefulSet.yaml属性文件的代码示例图，如图2所示，在“#容器内挂载点”注释以上的代码行都是对一个名称为“sms-h5-backend”且port号为30003的轨道交通软件应用的属性说明，该软件应用的类型为查看状态类型，因此在“#容器内挂载点”注释以下的代码行都是在说明该软件可能被查看的数据应该从主机中的什么存储位置读取，即对数据读取的路径进行介绍。

本发明提供的方法，明确指出了不同类型软件对应的Kubernetes副本控制器的属性文件，提供了在Kubernetes容器化应用中部署各轨道交通软件应用的准确操作方法。

在上述实施例的基础上，该方法中，所述当前所属轨道交通环境包括当前所属轨道中采集设备个数、所述采集设备需要采集的物理参数类型个数和所述采集设备采集上报频率中至少一种。

可选的，此处进一步限定了当前所属轨道交通环境作为影响轨道交通软件应用在Kubernetes容器化应用中部署时的影响因素时，进行定性定量分析时需要考虑的物理参数类型，因此，基于轨道交通软件应用所处的运行环境，选择了三个物理参数作为可选的直接参考因素：当前所属轨道中采集设备个数、所述采集设备需要采集的物理参数类型个数和/或所述采集设备采集上报频率。由于采集设备数量与需要采集分析采集数据类型的软件需要处理的数据量正相关，采集的物理参数类型个数也与需要采集分析采集数据类型的软件需要处理的数据量正相关，例如，同样都是一个采集设备，若该采集设备仅采集电流强度一种物理参数，而另一个采集设备采集温度、湿度和光照强度三种物理参数，那么连接处理所述另一个采集设备的轨道交通软件应用需要处理的数据量必然会更大，而采集设备的采集上报频率也是与需要采集分析采集数据类型的软件需要处理的数据量正相关，因为频率越高，需要处理的数据量越大，同时对处理高并发的计算性能要求也越高。而此处将当前所属轨道交通环境用当前所属轨道中采集设备个数、所述采集设备需要采集的物理参数类型个数和所述采集设备采集上报频率中至少一种物理参数进行描述，表明该环境可以用多种参数进行衡量，可以是一种，也可以是多种参数综合衡量，当前所属轨道交通环境可以用当前所属轨道中采集设备个数、所述采集设备需要采集的物理参数类型个数或所述采集设备采集上报频率单一参数进行衡量，也可以是两两组合：当前所属轨道中采集设备个数和所述采集设备需要采集的物理参数类型个数、当前所属轨道中采集设备个数和所述采集设备采集上报频率、所述采集设备需要采集的物理参数类型个数或所述采集设备采集上报频率，上述三种两参数组合综合衡量方式，还可以是前所属轨道交通环境可以用当前所属轨道中采集设备个数、所述采集设备需要采集的物理参数类型个数和所述采集设备采集上报频率三种参数进行组合综合衡量的方式。本发明提供的方法，限定了当前所属轨道交通环境作为影响轨道交通软件应用在Kubernetes容器化应用中部署时的影响因素中包括的物理参数类型，实现了定性定量分析交通环境。

在上述实施例的基础上，该方法中，还包括：

构建所述Kubernetes服务器集群的网关对象ambassador；

其中，所述网关对象ambassador用于为所述各轨道交通软件应用提供统一的软件访问入口。

可选的，基于Kubernetes容器化应用的控制器，监控容器组的创建过程，运行状态等信息，在容器组内形成容器化的轨道交通软件应用后实现暴露应用，然后生成对外的服务接口实现通讯，完成对外发布应用，而生成对外服务接口即是通过构建Kubernetes容器化应用中的网关对象ambassador，对该ambassador进行属性配置，使得Kubernetes集群中的各轨道交通软件应用拥有统一的软件访问入口。

本发明提供的方法，限定了在各轨道交通软件应用完成在Kubernetes服务器集群上的部署后，进行发布时对访问入口的设置，将各轨道交通软件应用的访问入口统一成一个地址，并提供了在Kubernetes容器化应用中设置统一地址的准确操作方法。

在上述实施例的基础上，该方法中，所述构建所述Kubernetes服务器集群的网关对象ambassador，包括：

编辑所述Kubernetes服务器集群的网关对象ambassador的副本控制器属性文件ambassador-deployment.yaml和服务属性文件ambassador-service.yaml，所述ambassador-deployment.yaml中写入所述统一的软件访问入口IP地址，所述ambassador-service.yaml中写入各轨道交通软件应用的port号。

可选的，进一步限定了Kubernetes服务器集群的访问方法和Kubernetes服务器集群上运行的各轨道交通软件应用的访问方法，各轨道交通软件应用的统一访问入口通过唯一的IP进行统一，Kubernetes服务器集群上运行的各轨道交通软件应用在所述唯一的IP的基础上再配上各轨道交通软件应用在所属Kubernetes服务器集群中分配的唯一port号。设置方法分别通过上文描述的编辑ambassador-deployment.yaml和ambassador-service.yaml的操作实现。编辑Kubernetes的网关对象副本控制器属性文件ambassador-deployment.yaml和网关应用的服务属性文件ambassador-service.yaml，各轨道交通软件应用提供的服务service的对外暴露端口的方式为NodePort方式。

本发明提供的方法，进一步限定了在各轨道交通软件应用完成在Kubernetes服务器集群上的部署后，进行发布时对各轨道交通软件应用的访问入口的设置，提供了在Kubernetes容器化应用中设置统一地址的准确操作方法。

在上述实施例的基础上，该方法中，当所述各轨道交通软件应用需要消除异常或软件升级时，所述Kubernetes服务器集群中各功能对象基于实时监测的所述各轨道交通软件应用的健康度和硬件节点可用资源调度，调度所述单体pod对象的分布；

当所述Kubernetes服务器集群需要扩容时，基于sealos安装工具中的sealosjoin–master命令或sealos join–node命令将新服务器加入所述Kubernetes服务器集群。

可选的，无论是软件模块出现异常而无法使用，还是软件升级，kubernetes的各类功能对象都能实时的监测每个软件模块的健康情况，并根据硬件节点的承受能力调度应用单体的分布情况，实现了智能化管理的效果。借助于sealos安装工具，只需要使用简易的命令：sealos join--master或sealos join–node命令将新的节点(服务器)加入到Kubernetes集群内，达到方便快捷地实现硬件扩容的效果。

下面对本发明提供的基于Kubernetes的轨道交通软件应用调度装置进行描述，下文描述的基于Kubernetes的轨道交通软件应用调度装置与上文描述的一种基于Kubernetes的轨道交通软件应用调度方法可相互对应参照。

图3为本发明提供的基于Kubernetes的轨道交通软件应用调度装置的结构示意图，如图3所示，该基于Kubernetes的轨道交通软件应用调度装置包括构建单元310、拉取单元320和部署单元340，其中，

所述构建单元310，用于根据需要布设的各轨道交通软件应用的运行程序，构建所述各轨道交通软件应用的各对应容器镜像，并发送至Kubernetes服务器集群中的master主机；

所述拉取单元320，用于采用Kubernetes副本控制器对象从所述master主机拉取所述各轨道交通软件应用的各对应容器镜像；

所述部署单元330，用于基于当前所属轨道交通环境和所述各对应容器镜像，采用Kubernetes副本控制器，在所述Kubernetes服务器集群内部署容器化的各轨道交通软件应用。

本发明提供的基于Kubernetes的轨道交通软件应用调度装置，通过根据需要布设的各轨道交通软件应用的运行程序，构建所述各轨道交通软件应用的各对应容器镜像，并发送至Kubernetes服务器集群中的master主机；采用Kubernetes副本控制器对象从所述master主机拉取所述各轨道交通软件应用的各对应容器镜像；基于当前所属轨道交通环境和所述各对应容器镜像，采用Kubernetes副本控制器，在所述Kubernetes服务器集群内部署容器化的各轨道交通软件应用。由于在服务器集群上布设Kubernetes容器化编排管理应用，而且各轨道交通软件应用在Kubernetes服务器集群上布设时还需要考虑当前所属轨道交通环境，判定各软件应用需要处理的数据量是否大，在基于数据量决定各轨道交通软件应用布设时占用的资源量，因此，使用Kubernetes容器化编排管理应用不仅解除软件与硬件之间的强耦合，降低人工成本，还能基于各软件应用所运行的环境中的数据量大小进行Kubernetes容器资源的合理分配。因此，本发明提供的装置，实现了硬件资源的高利用率和软件高效运行，降低人力成本，解除轨道交通软件应用与硬件之间的强耦合，达到软件和硬件的快速平滑升级和扩容的目标。

在上述实施例的基础上，该装置中，所述部署单元，用于：

采用Kubernetes副本控制器从所述master主机中拉取所述各对应容器镜像，确定所述各轨道交通软件应用对应的单体pod对象；

所述Kubernetes副本控制器基于当前所属轨道交通环境确定各单体pod对象的数量，基于所述数量对所述单体pod对象进行复制创建；

其中，所述Kubernetes副本控制器的属性文件中包括预先写入所述master主机地址。

在上述实施例的基础上，该装置中，

若任一轨道交通软件应用为调用组件类型，则创建所述任一轨道交通软件应用的Kubernetes副本控制器的属性文件为deployment.yaml属性文件；

若任一轨道交通软件应用为查看状态类型，则创建所述任一轨道交通软件应用的Kubernetes副本控制器的属性文件为statefulSet.yaml属性文件。

在上述实施例的基础上，该装置中，

所述当前所属轨道交通环境包括当前所属轨道中采集设备个数、所述采集设备需要采集的物理参数类型个数和所述采集设备采集上报频率中至少一种。

在上述实施例的基础上，该装置中，还包括访问配置单元，用于：

构建所述Kubernetes服务器集群的网关对象ambassador；

其中，所述网关对象ambassador用于为所述各轨道交通软件应用提供统一的软件访问入口。

在上述实施例的基础上，该装置中，所述构建所述Kubernetes服务器集群的网关对象ambassador，包括：

编辑所述Kubernetes服务器集群的网关对象ambassador的副本控制器属性文件ambassador-deployment.yaml和服务属性文件ambassador-service.yaml，所述ambassador-deployment.yaml中写入所述统一的软件访问入口IP地址，所述ambassador-service.yaml中写入各轨道交通软件应用的port号。

在上述实施例的基础上，该装置中，还包括升级扩容单元，用于：

当所述各轨道交通软件应用需要消除异常或软件升级时，所述Kubernetes服务器集群中各功能对象基于实时监测的所述各轨道交通软件应用的健康度和硬件节点可用资源调度，调度所述单体pod对象的分布；

当所述Kubernetes服务器集群需要扩容时，基于sealos安装工具中的sealosjoin–master命令或sealos join–node命令将新服务器加入所述Kubernetes服务器集群。

本发明提供的上述方法中的关键技术为：

1)基于容器化技术。

将每个轨道应用软件模块通过Dockerfile生成对应的容器镜像，通过运行镜像指令让软件应用独立运行在docker容器内，使得每个容器模块有独立的运行环境，减少软件模块之间进程的相互干扰。

2)良好的硬件扩展性。

借助于sealos安装工具，只需要使用简易的命令：sealos join--master或sealosjoin–node命令将新的节点(服务器)加入到Kubernetes集群内，达到硬件扩容的效果。

3)智能、平滑的过渡。

无论是软件模块出现异常而无法使用，还是软件升级，kubernetes的各类功能对象都能实时的监测每个软件模块的健康情况，并根据硬件节点的承受能力调度应用单体的分布情况，实现了智能化管理的效果。

本发明提供的方法实现了以下四个效果：

(一)充分利用轨道交通机房服务器资源，减少轨道交通对运维成本的投入。

(二)减小轨道软件应用对服务器硬件的依赖，方便后期软件的迁移调度与硬件的扩容升级。

(三)尽可能的减少轨道软件应用对运维人员的依赖，实现城市轨道交通软件智能化运维管理。

(四)在面对未来数据量不断增大的趋势下，能够实现城市轨道交通软硬件的快速、平滑升级扩容。

通过以上设计，城市轨道交通软件应用虽寄存于服务器上，但是它有自己的独立运行环境——docker容器，而Kubernetes再将docker容器部署于pod内部，降低了软件应用对服务器的依赖性，软件之间的进程隔离度高，可以在服务器的承受范围内，部署更多的软件应用(服务器的承受能力由Kubernetes对象kube-schedule控制，它可实时监测服务器环境，调配城市轨道软件应用在主机上的分布)，实现了服务器资源的充分利用，简化软件的迁移调度工作。

除此之外，Kubernetes的副本控制器能够根据用户期望的副本数量控制运行服务单体pod，即使某个服务单体出现异常终止运行时，副本控制器能将访问流量迁移至另外一个健康的pod单体上，然后再重启一个健康的服务单体，实现了平滑修复的效果。

下面通过已经将本发明成功应用于某轨道交通项目SMS系统中一个示例对本发明提供的方法部署完成的轨道交通软件应用的运行过程进行说明。图4为本发明提供的基于Kubernetes容器化编排管理的轨道交通智能软件应用运维调度技术总体设计图，如图4所示，当有来自https或http的访问时，ambassador-service对请求的目标ip地址进行校验，若ip地址与本Kubernetes服务器集群对外发布的唯一ip相同，则通过验证，进入ambassador的pod集群，ambassador的pod集群根据镜像中央仓库配置的pod对请求中携带的目标软件端口号进行分析找到该请求的需要访问的目标软件，图5为本发明提供的网关对象用于处理软件应用的属性文件示例图，如图5所示，从代码的第22行开始就是ambassador的pod集群根据镜像中央仓库配置的pod对请求中携带的目标软件端口号进行分析得到的请求中需要访问的目标软件的信息，需要访问的目标软件的端口名称为“hx8s7a”，需要访问的目标软件在该服务器集群中的唯一端口号是30003，需要访问的目标软件的名称是“sms-h5-backend”；根据端口号将该请求转发到对应的轨道交通软件应用i后(假设图4中的访问流程最后转向了轨道交通软件应用i，其中，1≤i≤N)，轨道交通软件应用i的副本控制器再根据镜像中央仓库为轨道交通软件应用i配置的pod对请求进行处理，满足其需求。

图6示例了一种电子设备的实体结构示意图，如图6所示，该电子设备可以包括：处理器(processor)610、通信接口(Communications Interface)620、存储器(memory)630和通信总线640，其中，处理器610，通信接口620，存储器630通过通信总线640完成相互间的通信。处理器610可以调用存储器630中的逻辑指令，以执行基于Kubernetes的轨道交通软件应用调度方法，该方法包括：根据需要布设的各轨道交通软件应用的运行程序，构建所述各轨道交通软件应用的各对应容器镜像，并发送至Kubernetes服务器集群中的master主机；采用Kubernetes副本控制器对象从所述master主机拉取所述各轨道交通软件应用的各对应容器镜像；基于当前所属轨道交通环境和所述各对应容器镜像，采用Kubernetes副本控制器，在所述Kubernetes服务器集群内部署容器化的各轨道交通软件应用。

此外，上述的存储器630中的逻辑指令可以通过软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

另一方面，本发明还提供一种计算机程序产品，所述计算机程序产品包括存储在非暂态计算机可读存储介质上的计算机程序，所述计算机程序包括程序指令，当所述程序指令被计算机执行时，计算机能够执行上述各方法所提供的基于Kubernetes的轨道交通软件应用调度方法，该方法包括：根据需要布设的各轨道交通软件应用的运行程序，构建所述各轨道交通软件应用的各对应容器镜像，并发送至Kubernetes服务器集群中的master主机；采用Kubernetes副本控制器对象从所述master主机拉取所述各轨道交通软件应用的各对应容器镜像；基于当前所属轨道交通环境和所述各对应容器镜像，采用Kubernetes副本控制器，在所述Kubernetes服务器集群内部署容器化的各轨道交通软件应用。

又一方面，本发明还提供一种非暂态计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现以执行上述各实施例提供的基于Kubernetes的轨道交通软件应用调度方法，该方法包括：根据需要布设的各轨道交通软件应用的运行程序，构建所述各轨道交通软件应用的各对应容器镜像，并发送至Kubernetes服务器集群中的master主机；采用Kubernetes副本控制器对象从所述master主机拉取所述各轨道交通软件应用的各对应容器镜像；基于当前所属轨道交通环境和所述各对应容器镜像，采用Kubernetes副本控制器，在所述Kubernetes服务器集群内部署容器化的各轨道交通软件应用。

以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。