CN115357341A - 一种多容器应用管理方法、装置、设备、存储介质 - Google Patents

Abstract

本申请公开了一种多容器应用管理方法、装置、设备、存储介质，涉及计算机技术领域，应用于管理集群，包括：部署用于对多容器应用编排对应的容器资源的编排资源以及控制器；利用控制器下发编排资源至管理集群，以便管理集群利用子编排资源对多容器应用的资源类型进行管理；接收监听子编排资源产生的状态信息，并更新与子编排资源对应的编排资源，实现对多容器应用的管理。通过部署控制器将多容器集群中的应用管理统一到编排资源中，并在每一个集群中通过监听器以及定义的子编排资源实现对容器集群中应用的分布式管理。管理集群下发后只需要接收监听器上报的状态信息即可，减轻了管理集群的管理压力实现对多个容器集群中容器应用的统一编排与管理。

Description

一种多容器应用管理方法、装置、设备、存储介质

技术领域

本发明涉及计算机技术领域，特别涉及一种多容器应用管理方法、装置、设备、存储介质。

背景技术

现实中，客户的容器集群不可能是单一的一个集群，出于安全、成本等的考虑，客户的容器应用可能部署在多个地域的机房、也可能是部署在自己的机房、也可能部署在公有云，这些集群之间可能也存在着网络不通、Kubernetes版本不一致等问题。用单一的集群管理思路去管理不现实。而客户存在着许多要在多个集群中均需要去部署的容器应用，比如在每个集群中可能部署类型的业务系统、监控系统等，现有技术中，在管理较多容器集群时，普通的容器集群管理平台的管理方式为在管理集群中进行多次的创建，但在工作集群较多时该操作非常繁琐，且人工操作容易出错，也无法做到统一的管理，更无法实现跨集群的容器应用编排功能。

综上，如何在多工作集群中对容器应用进行统一的编排，使在多集群环境中下发容器应用时可以获得与单一集群下发应用同样的用户体验是本领域有待解决的技术问题。

发明内容

有鉴于此，本发明的目的在于提供一种多容器应用管理方法、装置、设备、存储介质，能够在多工作集群中对容器应用进行统一的编排，使在多集群环境中下发容器应用时可以获得与单一集群下发应用同样的用户体验。其具体方案如下：

第一方面，本申请公开了一种多容器应用管理方法，应用于管理集群，包括：

部署用于对多容器应用编排对应的容器资源的编排资源以及控制器；

利用所述控制器下发所述编排资源至管理集群，以便所述管理集群利用子编排资源对多容器应用的资源类型进行管理；

接收监听所述子编排资源产生的状态信息，并更新与所述子编排资源对应的所述编排资源，实现对所述多容器应用的管理。

可选的，所述部署用于对多容器应用编排对应的容器资源的编排资源，包括：

部署包含多容器应用的集群信息、token信息、多容器应用的属性信息的编排资源。

可选的，所述部署用于对多容器应用编排对应的容器资源的编排资源，包括：

利用键值对方式部署用于对多容器应用编排对应的容器资源的编排资源。

可选的，所述利用所述控制器下发所述编排资源至管理集群，以便所述管理集群利用子编排资源对多容器应用的资源类型进行管理之前，还包括：

部署包含所述编排资源的属性信息以及对应的多容器应用集群信息的子编排资源。

可选的，所述接收监听所述子编排资源产生的状态信息，包括：

通过agent对监听所述子编排资源产生的状态信息上报至管理集群的控制器。

可选的，所述多容器应用管理方法，还包括：

若控制器监听到编排资源的删除事件请求，则删除对应的所述子编排资源。

可选的，所述删除对应的所述子编排资源过程中，还包括：

通过子编排资源删除多容器应用创建的预设资源信息。

第二方面，本申请公开了一种多容器应用管理装置，应用于管理集群，包括：

编排资源部署模块，用于部署用于对多容器应用编排对应的容器资源的编排资源以及控制器；

资源类型管理模块，用于利用所述控制器下发所述编排资源至管理集群，以便所述管理集群利用子编排资源对多容器应用的资源类型进行管理；

多应用管理模块，用于接收监听所述子编排资源产生的状态信息，并更新与所述子编排资源对应的所述编排资源，实现对所述多容器应用的管理。

第三方面，本申请公开了一种电子设备，包括：

存储器，用于保存计算机程序；

处理器，用于执行所述计算机程序，以实现前述公开的多容器应用管理方法的步骤。

第四方面，本申请公开了一种计算机可读存储介质，用于存储计算机程序；其中，所述计算机程序被处理器执行时实现前述公开的多容器应用管理方法的步骤。

由此可见，本申请公开了一种多容器应用管理方法，应用于管理集群，包括：部署用于对多容器应用编排对应的容器资源的编排资源以及控制器；利用所述控制器下发所述编排资源至管理集群，以便所述管理集群利用子编排资源对多容器应用的资源类型进行管理；接收监听所述子编排资源产生的状态信息，并更新与所述子编排资源对应的所述编排资源，实现对所述多容器应用的管理。可见，通过部署控制器将多容器集群中的应用管理统一到编排资源中，并在每一个集群中通过监听器以及定义的子编排资源实现对容器集群中应用的分布式管理。管理集群下发后只需要接收监听器上报的状态信息即可，减轻了管理集群的管理压力，并只通过部署预先定义的资源类型管理实现了对多个容器集群中容器应用的统一编排与管理。

附图说明

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

图1为本申请公开的一种多容器应用管理方法流程图；

图2为本申请公开的一种具体的多容器应用管理方法流程图；

图3为本申请公开的一种原生K8S集群架构图；

图4为本申请公开的一种K8S集群管理架构图；

图5为本申请公开的一种多容器应用管理装置结构示意图；

图6为本申请公开的一种电子设备结构图。

具体实施方式

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

现实中，客户的容器集群不可能是单一的一个集群，出于安全、成本等的考虑，客户的容器应用可能部署在多个地域的机房、也可能是部署在自己的机房、也可能部署在公有云，这些集群之间可能也存在着网络不通、Kubernetes版本不一致等问题。用单一的集群管理思路去管理不现实。而客户存在着许多要在多个集群中均需要去部署的容器应用，比如在每个集群中可能部署类型的业务系统、监控系统等，现有技术中，在管理较多容器集群时，普通的容器集群管理平台的管理方式为在管理集群中进行多次的创建，但在工作集群较多时该操作非常繁琐，且人工操作容易出错，也无法做到统一的管理，更无法实现跨集群的容器应用编排功能。

为此，本申请公开了一种多容器应用管理方案，能够在多工作集群中对容器应用进行统一的编排，使在多集群环境中下发容器应用时可以获得与单一集群下发应用同样的用户体验。

参照图1所示，本发明实施例公开了一种多容器应用管理方法，应用于管理集群，包括：

步骤S11：部署用于对多容器应用编排对应的容器资源的编排资源以及控制器。

本实施例中，在K8S的容器管理集群中，采用K8S的自定义资源定义的方式，定义一类编排资源，例如：将所述编排资源命名为apps资源，用户如果需要在多个集群中编排对应的容器资源时，只需要在管理集群中创建对应的apps资源即可。其中所述apps资源定义代码如下所示：

其中，所述apps资源定义主要分为两部分，cluster资源主要是定义了该资源需要部署的工作集群信息，工作集群的名称以及token信息。Resource资源则定义了该apps资源中需要部署的资源的类型以及属性。对多个集群中的容器资源编排统一归纳为对一种apps资源的管理，因此，部署包含多容器应用的集群信息、token信息、多容器应用的属性信息的编排资源，可以理解的是，预先记录多容器应用的集群信息、token信息、属性信息可以保证apps资源能够完全掌握名下包含的多容器应用的信息，并且所述属性信息具体可以包括但不限于，所使用的镜像、CPU、内存的大小、副本数量等。

本实施例中，利用键值对方式部署用于对多容器应用编排对应的容器资源的编排资源。可以理解的是，采用键值对的方式部署编排资源，使多容器应用的集群信息、token信息、多容器应用的属性信息统一通过编号对应数据的方式进行逐一匹配部署并保存，以便当直接点击对应的编号直接输出编号对应的数据。

步骤S12：利用所述控制器下发所述编排资源至管理集群，以便所述管理集群利用子编排资源对多容器应用的资源类型进行管理。

本实施例中，所述利用所述控制器下发所述编排资源至管理集群，以便所述管理集群利用子编排资源对多容器应用的资源类型进行管理之前，还包括：部署包含所述编排资源的属性信息以及对应的多容器应用集群信息的子编排资源。可以理解的是，定义了一种需要下发到工作集群中的子编排资源，命名为app资源，该资源属于apps资源的子集，只包含了apps中资源的属性信息以及对应工作集群的集群信息。当定义所述自编排资源之后，利用控制器下发编排资源至管理集群，由于定义的一种apps资源的子集资源，该app资源只包含了对应的apps中的属性信息，并且该app资源为k8s集群原生资源如Deployment、StatefulSet资源的父级资源，其中，Deployment为K8S中一种工作负载类型的原生资源，用来控制K8S中pod资源、容器资源的编排与管理，负责管理无状态资源。StatefulSet为K8S中一种工作负载类型的原生资源，与Deployment平级用来控制K8S中pod资源、容器资源的编排与管理，负责管理有状态资源。由于管理集群控制预先定义的子编排资源对多容器应用的资源类型进行管理，用于对编排资源的管理进行分流，减少编排资源对多容器应用的管理的负载压力。

步骤S13：接收监听所述子编排资源产生的状态信息，并更新与所述子编排资源对应的所述编排资源，实现对所述多容器应用的管理。

本实施例中，通过设置监听器在工作集群被纳管时即被分发到各个工作集群中运行，监听被控制器分发到各工作集群中部署的应用的状态的变化、属性的变化并进实时的上报给管理集群中的控制器。在工作集群中，通过app资源对K8S中原生的资源类型进行管理，将各种集群的工作状态的实时监听放到了每一个集群中的app资源的监听。部署一种多容器集群中统一的容器应用生命周期管理工具。首先，基于K8S中的自定义资源规范，在管理集群以及工作集群定义两级的资源管理规范。定义了一种两级控制器，管理集群控制器负责筛选需要下发的工作集群并下发容器应用信息、工作集群控制器负责接收管理集群下发的app资源，并根据app资源转为工作集群的K8S原生资源与指令。定义了一种监听器，该监听器作用于工作集群，该监听器与管理集群建立反向连接，将工作集群中的app资源的实时信息进行上报，供管理集群控制器进行决策并修改apps资源。

由此可见，本申请公开了一种多容器应用管理方法，应用于管理集群，包括：部署用于对多容器应用编排对应的容器资源的编排资源以及控制器；利用所述控制器下发所述编排资源至管理集群，以便所述管理集群利用子编排资源对多容器应用的资源类型进行管理；接收监听所述子编排资源产生的状态信息，并更新与所述子编排资源对应的所述编排资源，实现对所述多容器应用的管理。可见，通过部署控制器将多容器集群中的应用管理统一到编排资源中，并在每一个集群中通过监听器以及定义的子编排资源实现对容器集群中应用的分布式管理。管理集群下发后只需要接收监听器上报的状态信息即可，减轻了管理集群的管理压力，并只通过部署预先定义的资源类型管理实现了对多个容器集群中容器应用的统一编排与管理。

参照图2所示，本发明实施例公开了一种具体的多容器应用管理方法，相对于上一实施例，本实施例对技术方案作了进一步的说明和优化。具体的：

步骤S21：部署用于对多容器应用编排对应的容器资源的编排资源以及控制器。

本实施例中，设计了一种两级控制器，该控制器负载基于定义的编排资源信息，将在apps中定义的容器资源统一分发创建到对应的工作集群中，并在工作集群中定义了app的控制器进行本层级的指令转换、下发工作。其中，该控制器的布置分为两部分，首先是管理集群控制器，负责向工作集群中进行应用的分发以及管理功能以及接收返回的底层资源的状态变化、属性变化，对管理集群中的资源进行数据同步、业务逻辑处理。其次，工作集群中，负责接收管理集群下发的编排指令，接收到编排指令后进行业务处理并转为当前K8S集群可识别的资源指令，并监听该集群中创建的原生K8S资源的状态变化，对当前集群中创建的容器应用进行生命周期管理。通过部署了一种通用的对统一资源进行编排的资源规范，基于该资源规范，管理集群可以将每个工作集群中分发的资源转化为管理集群中的统一资源进行生命周期管理。在K8S的管理集群定义了一种统一的apps资源，在该资源主要记录了对应的应用需要部署的工作集群的鉴权信息、部署信息，资源的基本属性信息，管理集群中的该资源记录了可能被部署的多个工作集群的鉴权信息。

步骤S22：利用所述控制器下发所述编排资源至管理集群，以便所述管理集群利用子编排资源对多容器应用的资源类型进行管理。

本实施例中，利用部署的控制器下发编排资源至管理集群，然后管理集群利用子编排资源对多容器应用的资源类型进行管理，参照图3所示，为原始K8S集群架构图，ApiServer提供集群管理的REST API接口，包括认证授权、数据校验以及集群状态变更等；提供其他模块之间的数据交互和通信的枢纽，例如：其他模块通过ApiServer查询或修改数据，只有ApiServer才能直接操作etcd，Scheduler在K8S中担任调度器的作用对pod进行调度，其中，调度是指将pod放置到合适的Node节点上，然后对应Node上的Kubelet才能够运行这些pod，调度器通过K8S的watch机制来发现集群中新创建且尚未被调度到Node上的pod。调度器会将发现的每一个未调度的pod调度到一个合适的Node上来运行。调度器会依据预设的调度原则来做出调度选择，ControllerManager是各种Controller的管理者，是集群内部的管理控制中心，用于保证集群中各种资源的状态和用户定义的状态一致，如果出现偏差，则修正资源的状态，Deployment是K8S工作负载控制器，用于更高级层次对象，部署和管理pod，具有应用部署、应用升级、应用实例扩容和缩容、发布失败回滚、应用下线等主要功能，由此可见，原始的K8S集群架构中，对集群中多容器应用的管理属于单一的集群管理，当出现不可抗力因素时，就无法统一管理。

步骤S23：通过agent对监听所述子编排资源产生的状态信息上报至所述管理集群的所述控制器，若所述控制器监听到编排资源的删除事件请求，则删除对应的所述子编排资源。

本实施例中，在监听到创建事件时，控制器会基于apps的描述文件，解析对应的apps资源识别需要部署的集群信息以及属性信息。基于部署的集群信息以及token信息，生成对应的部署集群中的鉴权信息。基于属性信息，生成对应的部署集群中的资源信息，例如：工作负载类型、副本数、所用镜像、cpu、memory等。对应的资源生成后，基于K8S中的API-Server，将资源分发到各工作集群中创建app资源以及app资源下的各种工作负载资源。工作集群中创建对应的资源后，工作集群中的监听器马上对创建的资源进行实时监听，监听其状态、属性的变化，并将资源的状态实时上报给管理集群。管理集群中的控制器对于上报的资源状态进行统一的维护以及展示，管理者可以通过上层的apps资源对下层工作集群中的实际资源进行管理。

本实施例中，所述删除对应的所述子编排资源过程中，还包括：通过子编排资源删除多容器应用创建的预设资源信息。可以理解的是，当管理集群中需要删除对应的apps资源时，控制器会监听到apps资源的删除事件，会基于apps资源，统一删除各工作集群中的app资源，app资源会统一删除各工作集群中的创建的各k8s默认资源。从而实现容器集群中统一的容器应用的删除功能。

本实施例中，将监听器以及二级控制器以K8S原生工作负载的形式部署在工作集群中，当管理集群纳管工作集群时，管理集群会向对应的工作集群中分发对应的监听器、二级控制器并在工作集群中创建自定义资源app。管理集群中的控制器会实时监听apps资源在管理集群中的一切事件，如创建、修改、删除等。参照图4所示，以创建流程为例对集群资源的进一步抽象，将集群作为一种在更高层次下的资源属性，在更高层次对集群中的应用进行统一下发与管理，本方案是对多种集群中管理的整体架构，在工作集群中设置控制器，实现apps资源的下发，同时在在工作集群中设置了对应的控制器与监听器，控制器用于通过app资源对K8S原生资源如Deployment的管理。agent则是将app的数据上报给管理集群的apps-controller，apps-controller根据app信息管理维护对应的apps资源。在该架构中，管理集群通过控制器与apps资源进行交互。控制器通过对apps的解析与管理，实现了对多集群中应用的统一管理。在工作集群中，通过app资源对K8S中原生的资源类型进行管理，将各种集群的工作状态的实时监听放到了每一个集群中的app资源的监听。监听器将每一个工作集群中的app资源的状态的实时变化上报给管理集群的控制器。控制器接收到监听器上报的app资源的状态更新对应的apps资源。同理当管理集群中需要删除对应的apps资源时，控制器会监听到apps资源的删除事件，会基于apps资源，统一删除各工作集群中的app资源，app资源会统一删除各工作集群中的创建的各K8S默认资源。从而实现容器集群中统一的容器应用的删除功能。

步骤S24：更新与所述子编排资源对应的所述编排资源，实现对所述多容器应用的管理。

本实施例中，可以理解的是，当设置的监听器监听每一个工作集群中的app资源的状态的实时变化信息，并将监听到的每一个控制器通过接收到的监听器中上报的app资源的状态更新对应的apps资源，管理集群控制器进行决策并修改apps资源，实现对所述多容器应用的管理。

由此可见，本实施例基于K8S中的自定义资源规范，在管理集群以及工作集群定义两级的资源管理规范。定义了一种两级控制器，管理集群控制器负责筛选需要下发的工作集群并下发容器应用信息、工作集群控制器负责接收管理集群下发的app资源，并根据app资源转为工作集群的K8S原生资源与指令。定义了一种监听器，该监听器作用于工作集群，该监听器与管理集群建立反向连接，将工作集群中的app资源的实时信息进行上报，供管理集群控制器进行决策并修改apps资源，减轻了管理集群的管理压力。

参照图5所示，本发明实施例公开了一种多容器应用管理装置，应用于管理集群，包括：

编排资源部署模块11，用于部署用于对多容器应用编排对应的容器资源的编排资源以及控制器；

资源类型管理模块12，用于利用所述控制器下发所述编排资源至管理集群，以便所述管理集群利用子编排资源对多容器应用的资源类型进行管理；

多应用管理模块13，用于接收监听所述子编排资源产生的状态信息，并更新与所述子编排资源对应的所述编排资源，实现对所述多容器应用的管理。

所述编排资源部署模块11，具体用于设计了一种两级控制器，该控制器负载基于定义的编排资源信息，将在apps中定义的容器资源统一分发创建到对应的工作集群中，并在工作集群中定义了app的控制器进行本层级的指令转换、下发工作。其中，该控制器的布置分为两部分，首先是管理集群控制器，负责向工作集群中进行应用的分发以及管理功能以及接收返回的底层资源的状态变化、属性变化，对管理集群中的资源进行数据同步、业务逻辑处理。其次，工作集群中，负责接收管理集群下发的编排指令，接收到编排指令后进行业务处理并转为当前K8S集群可识别的资源指令，并监听该集群中创建的原生K8S资源的状态变化，对当前集群中创建的容器应用进行生命周期管理。通过部署了一种通用的对统一资源进行编排的资源规范，基于该资源规范，管理集群可以将每个工作集群中分发的资源转化为管理集群中的统一资源进行生命周期管理。在K8S的管理集群定义了一种统一的apps资源，在该资源主要记录了对应的应用需要部署的工作集群的鉴权信息、部署信息，资源的基本属性信息，管理集群中的该资源记录了可能被部署的多个工作集群的鉴权信息。

所述资源类型管理模块12，具体用于利用所述控制器下发所述编排资源至管理集群，以便所述管理集群利用子编排资源对多容器应用的资源类型进行管理之前，还包括：部署包含所述编排资源的属性信息以及对应的多容器应用集群信息的子编排资源。可以理解的是，定义了一种需要下发到工作集群中的子编排资源，命名为app资源，该资源属于apps资源的子集，只包含了apps中资源的属性信息以及对应工作集群的集群信息。当定义所述自编排资源之后，利用控制器下发编排资源至管理集群，由于定义的一种apps资源的子集资源，该app资源只包含了对应的apps中的属性信息，并且该app资源为k8s集群原生资源如Deployment、StatefulSet资源的父级资源，其中，Deployment为K8S中一种工作负载类型的原生资源，用来控制K8S中pod资源、容器资源的编排与管理，负责管理无状态资源。StatefulSet为K8S中一种工作负载类型的原生资源，与Deployment平级用来控制K8S中pod资源、容器资源的编排与管理，负责管理有状态资源。由于管理集群控制预先定义的子编排资源对多容器应用的资源类型进行管理，用于对编排资源的管理进行分流，减少编排资源对多容器应用的管理的负载压力。利用部署的控制器下发编排资源至管理集群，然后管理集群利用子编排资源对多容器应用的资源类型进行管理，ApiServer提供集群管理的RESTAPI接口，包括认证授权、数据校验以及集群状态变更等；提供其他模块之间的数据交互和通信的枢纽，例如：其他模块通过ApiServer查询或修改数据，只有ApiServer才能直接操作etcd，Scheduler在K8S中担任调度器的作用对pod进行调度，其中，调度是指将pod放置到合适的Node节点上，然后对应Node上的Kubelet才能够运行这些pod，调度器通过K8S的watch机制来发现集群中新创建且尚未被调度到Node上的pod。调度器会将发现的每一个未调度的pod调度到一个合适的Node上来运行。调度器会依据预设的调度原则来做出调度选择，ControllerManager是各种Controller的管理者，是集群内部的管理控制中心，用于保证集群中各种资源的状态和用户定义的状态一致，如果出现偏差，则修正资源的状态，Deployment是K8S工作负载控制器，用于更高级层次对象，部署和管理pod，具有应用部署、应用升级、应用实例扩容和缩容、发布失败回滚、应用下线等主要功能，由此可见，原始的K8S集群架构中，对集群中多容器应用的管理属于单一的集群管理，当出现不可抗力因素时，就无法统一管理。

所述多应用管理模块13，具体用于通过设置监听器在工作集群被纳管时即被分发到各个工作集群中运行，监听被控制器分发到各工作集群中部署的应用的状态的变化、属性的变化并进实时的上报给管理集群中的控制器。在工作集群中，通过app资源对K8S中原生的资源类型进行管理，将各种集群的工作状态的实时监听放到了每一个集群中的app资源的监听。部署一种多容器集群中统一的容器应用生命周期管理工具。首先，基于K8S中的自定义资源规范，在管理集群以及工作集群定义两级的资源管理规范。定义了一种两级控制器，管理集群控制器负责筛选需要下发的工作集群并下发容器应用信息、工作集群控制器负责接收管理集群下发的app资源，并根据app资源转为工作集群的K8S原生资源与指令。定义了一种监听器，该监听器作用于工作集群，该监听器与管理集群建立反向连接，将工作集群中的app资源的实时信息进行上报，供管理集群控制器进行决策并修改apps资源。

由此可见，本申请公开了一种多容器应用管理方法，应用于管理集群，包括：部署用于对多容器应用编排对应的容器资源的编排资源以及控制器；利用所述控制器下发所述编排资源至管理集群，以便所述管理集群利用子编排资源对多容器应用的资源类型进行管理；接收监听所述子编排资源产生的状态信息，并更新与所述子编排资源对应的所述编排资源，实现对所述多容器应用的管理。可见，通过部署控制器将多容器集群中的应用管理统一到编排资源中，并在每一个集群中通过监听器以及定义的子编排资源实现对容器集群中应用的分布式管理。管理集群下发后只需要接收监听器上报的状态信息即可，减轻了管理集群的管理压力，并只通过部署预先定义的资源类型管理实现了对多个容器集群中容器应用的统一编排与管理。

在一些具体实施方式中，所述编排资源部署模块11，具体包括：

第一资源部署单元，用于部署包含多容器应用的集群信息、token信息、多容器应用的属性信息的编排资源。

在一些具体实施方式中，所述编排资源部署模块11，具体包括：

方式确定单元，用于利用键值对方式部署用于对多容器应用编排对应的容器资源的编排资源。

在一些具体实施方式中，所述多容器应用管理装置，具体包括：

第二资源部署单元，用于部署包含所述编排资源的属性信息以及对应的多容器应用集群信息的子编排资源。

在一些具体实施方式中，所述多应用管理模块13，具体包括：

上报单元，用于通过agent对监听所述子编排资源产生的状态信息上报至管理集群的控制器。

在一些具体实施方式中，所述多容器应用管理装置，具体包括：

资源删除子模块，用于若控制器监听到编排资源的删除事件请求，则删除对应的所述子编排资源。

在一些具体实施方式中，所述资源删除子模块，具体包括：

信息创建单元，用于通过子编排资源删除多容器应用创建的预设资源信息。

进一步的，本申请实施例还公开了一种电子设备，图6是根据一示例性实施例示出的电子设备20结构图，图中的内容不能认为是对本申请的使用范围的任何限制。

图6为本申请实施例提供的一种电子设备20的结构示意图。该电子设备20，具体可以包括：至少一个处理器21、至少一个存储器22、电源23、通信接口24、输入输出接口25和通信总线26。其中，所述存储器22用于存储计算机程序，所述计算机程序由所述处理器21加载并执行，以实现前述任一实施例公开的多容器应用管理方法中的相关步骤。另外，本实施例中的电子设备20具体可以为电子计算机。

本实施例中，电源23用于为电子设备20上的各硬件设备提供工作电压；通信接口24能够为电子设备20创建与外界设备之间的数据传输通道，其所遵循的通信协议是能够适用于本申请技术方案的任意通信协议，在此不对其进行具体限定；输入输出接口25，用于获取外界输入数据或向外界输出数据，其具体的接口类型可以根据具体应用需要进行选取，在此不进行具体限定。

其中，处理器21可以包括一个或多个处理核心，比如4核心处理器、8核心处理器等。处理器21可以采用DSP(Digital Signal Processing，数字信号处理)、FPGA(Field－Programmable Gate Array，现场可编程门阵列)、PLA(Programmable Logic Array，可编程逻辑阵列)中的至少一种硬件形式来实现。处理器21也可以包括主处理器和协处理器，主处理器是用于对在唤醒状态下的数据进行处理的处理器，也称CPU(Central ProcessingUnit，中央处理器)；协处理器是用于对在待机状态下的数据进行处理的低功耗处理器。在一些实施例中，处理器21可以在集成有GPU(Graphics Processing Unit，图像处理器)，GPU用于负责显示屏所需要显示的内容的渲染和绘制。一些实施例中，处理器21还可以包括AI(Artificial Intelligence，人工智能)处理器，该AI处理器用于处理有关机器学习的计算操作。

另外，存储器22作为资源存储的载体，可以是只读存储器、随机存储器、磁盘或者光盘等，其上所存储的资源可以包括操作系统221、计算机程序222等，存储方式可以是短暂存储或者永久存储。

其中，操作系统221用于管理与控制电子设备20上的各硬件设备以及计算机程序222，以实现处理器21对存储器22中海量数据223的运算与处理，其可以是Windows Server、Netware、Unix、Linux等。计算机程序222除了包括能够用于完成前述任一实施例公开的由电子设备20执行的多容器应用管理方法的计算机程序之外，还可以进一步包括能够用于完成其他特定工作的计算机程序。数据223除了可以包括电子设备接收到的由外部设备传输进来的数据，也可以包括由自身输入输出接口25采集到的数据等。

进一步的，本申请还公开了一种计算机可读存储介质，用于存储计算机程序；其中，所述计算机程序被处理器执行时实现前述公开的多容器应用管理方法。关于该方法的具体步骤可以参考前述实施例中公开的相应内容，在此不再进行赘述。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其它实施例的不同之处，各个实施例之间相同或相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上对本发明所提供的一种多容器应用管理方法、装置、设备、存储介质进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

Claims (10)

1.一种多容器应用管理方法，其特征在于，应用于管理集群，包括：

部署用于对多容器应用编排对应的容器资源的编排资源以及控制器；

利用所述控制器下发所述编排资源至管理集群，以便所述管理集群利用子编排资源对多容器应用的资源类型进行管理；

接收监听所述子编排资源产生的状态信息，并更新与所述子编排资源对应的所述编排资源，实现对所述多容器应用的管理。

2.根据权利要求1所述的多容器应用管理方法，其特征在于，所述部署用于对多容器应用编排对应的容器资源的编排资源，包括：

部署包含多容器应用的集群信息、token信息、多容器应用的属性信息的编排资源。

3.根据权利要求1所述的多容器应用管理方法，其特征在于，所述部署用于对多容器应用编排对应的容器资源的编排资源，包括：

利用键值对方式部署用于对多容器应用编排对应的容器资源的编排资源。

4.根据权利要求1所述的多容器应用管理方法，其特征在于，所述利用所述控制器下发所述编排资源至管理集群，以便所述管理集群利用子编排资源对多容器应用的资源类型进行管理之前，还包括：

部署包含所述编排资源的属性信息以及对应的多容器应用集群信息的子编排资源。

5.根据权利要求1所述的多容器应用管理方法，其特征在于，所述接收监听所述子编排资源产生的状态信息，包括：

通过agent对监听所述子编排资源产生的状态信息上报至管理集群的控制器。

6.根据权利要求1至5任一项所述的多容器应用管理方法，其特征在于，还包括：

若控制器监听到编排资源的删除事件请求，则删除对应的所述子编排资源。

7.根据权利要求6所述的多容器应用管理方法，其特征在于，所述删除对应的所述子编排资源过程中，还包括：

通过子编排资源删除多容器应用创建的预设资源信息。

8.一种多容器应用管理装置，其特征在于，应用于管理集群，包括：

编排资源部署模块，用于部署用于对多容器应用编排对应的容器资源的编排资源以及控制器；

资源类型管理模块，用于利用所述控制器下发所述编排资源至管理集群，以便所述管理集群利用子编排资源对多容器应用的资源类型进行管理；

多应用管理模块，用于接收监听所述子编排资源产生的状态信息，并更新与所述子编排资源对应的所述编排资源，实现对所述多容器应用的管理。

9.一种电子设备，其特征在于，包括：

存储器，用于保存计算机程序；

处理器，用于执行所述计算机程序，以实现如权利要求1至7任一项所述的多容器应用管理方法的步骤。

10.一种计算机可读存储介质，其特征在于，用于存储计算机程序；其中，所述计算机程序被处理器执行时实现如权利要求1至7任一项所述的多容器应用管理方法的步骤。

Images