CN110321115B - 一种Pod创建方法及设备 - Google Patents

Abstract

本发明公开了一种Pod创建方法及设备，用于基于Service的需求来进行Pod的创建。该方法包括：接收用户的第一服务Service创建请求，第一Service创建请求用于请求创建第一Service；其中，第一Service创建请求携带需要与第一Service进行关联的M个Pod的信息；根据第一Service创建请求创建第一Service；确定需要与第一Service关联的M个Pod的状态；若M个Pod的状态表明M个Pod中的N个Pod不满足预设的冗余副本要求，则新建N个Pod；和/或，若M个Pod的状态表明M个Pod中的L个Pod尚未创建，则新建L个Pod。

Description

一种Pod创建方法及设备

技术领域

本发明涉及数据技术领域，特别涉及一种容器集(Pod)创建方法及设备。

背景技术

Kubernetes(K8s)是基于Docker的开源容器集群管理系统，Kubernetes可以构建一个容器(Container)的调度服务，以让用户通过Kubernetes系统来进行容器集群的管理。在Kubernetes系统中，用户可操作的表述性状态传递(Representational StateTransfer，REST)对象通常包括三个，即Pod、服务(Service)和冗余控制器(ReplicationController)。Pod是Kubernetes系统最基本的部署调度单元，一个Pod可以包括多个工作于同一Minion的Container，同一个Pod包括的Container拥有相同的网络命名空间网络协议(Internet Protocol，IP)地址以及存储配额。Service是Pod的路由代理抽象，ReplicationController是Pod的复制抽象，Service和Replication Controller都可以通过标签(label)与Pod进行关联。

目前，Pod的创建过程通常如下。用户通过命令行工具(Kubecfg)发起Pod创建请求，Kubecfg将Pod创建请求发送给应用程序编程接口服务(Application ProgrammingInterface Server，ApiServer)，ApiServer再根据Pod创建请求创建一个Pod，并将该Pod的相关信息持久化到键值存储数据库(Etcd)中。调度器(Scheduler)根据不同的scheduler资源调度策略，将新创建的Pod与工作节点(Minion)进行绑定，并将绑定情况更新到Etcd中。当管理器(Kubelet)周期性地向Etcd查询绑定Minion后的Pod并获取后，在对应的Minion上启动该Pod包括的Container，从而完成Pod创建。在Pod创建完成后，用户还可以创建Replication Controller，使得当前系统中的Pod满足冗余(replication)副本要求；另外，用户还可以创建Service，并系统中已存在的Pod与该Service进行关联，从而实现Pod之间的通信。

可见，目前对于Pod的创建均是通过Pod完全创建完成之后，再来将Pod与Service进行关联，那么很有可能存在同一Service之下的多个Pod所绑定的Minion相同，一旦该Minion宕机，则该Service所能提供的服务则会大面积失效，从而降低了Kubernetes系统的可靠性。

发明内容

本发明实施例提供一种Pod创建方法及设备，用于基于Service的需求来进行Pod的创建。

第一方面，提供一种Pod创建方法，该方法包括：接收用户的第一Service创建请求，所述第一Service创建请求用于请求创建第一Service；其中，所述第一Service创建请求携带需要与所述第一Service进行关联的M个Pod的信息，M为正整数；根据所述第一Service创建请求创建所述第一Service；确定需要与所述第一Service关联的M个Pod的状态；若所述M个Pod的状态表明所述M个Pod中的N个Pod不满足预设的冗余副本要求，则新建所述N个Pod；和/或，若所述M个Pod的状态表明所述M个Pod中的L个Pod尚未创建，则新建所述L个Pod；N、L为正整数，且N≤M，L≤M。

在Pod部署之前，首先进行Service的创建，进而根据Service的关联需求来进行Pod的创建，这样针对在Pod创建过程中的Minion绑定时，则能够根据该Service下的Pod进行统一的管理调度，以避免绑定重复的Minion。

可选的，确定需要与所述第一Service关联的M个Pod的状态，包括：

获取所述M个Pod中每个Pod包括的Container的状态，其中，一个Pod包括至少一个Container；根据所述每个Pod包括的Container与所述M个Pod的映射关系确定所述M个Pod中每个Pod的状态。

通过每个Pod包括的Container的状态能够确定该Pod是否存在，以及该Pod的副本数量，进而确定需要与第一Service关联的Pod的状态，即这些Pod是否已经存在，以及这些Pod的副本数量是否满足冗余副本要求，在保证Service需关联的Pod的创建的同时，还可以引入多副本创建过程，以减少多副本创建过程所需的信息交互。

可选的，在确定所述M个Pod中每个Pod是否满足所述冗余副本要求之后，所述方法还包括：

若确定所述M个Pod中的P个Pod满足所述冗余副本要求，则将所述P个Pod的label标记为所述第一Service，以将所述P个Pod与所述第一Service进行关联。

可选的，在新建所述N个Pod，和/或，新建所述L个Pod之后，所述方法还包括：

将所述N个Pod的label标记为所述第一Service，以将所述N个Pod与所述第一Service进行关联；和/或，将所述L个Pod的label标记为所述第一Service，以将所述L个Pod与所述第一Service进行关联。

将满足冗余副本要求的Pod或者新建的Pod的label标记为第一Service，以将这些Pod与第一Service进行关联。

可选的，在新建所述N个Pod，和/或，新建所述L个Pod之后，所述方法还包括：

获取所述M个Pod中的工作节点Minion的分配情况信息，所述分配情况信息用于指示所述M个Pod中已分配Minion的Pod所占用的Minion；根据所述分配情况信息，为所述N个Pod分配与所述已分配Minion的Pod所占用的Minion不同的Minion；和/或，为所述L个Pod分配与所述已分配Minion的Pod所占用的Minion不同的Minion；其中，不同的Pod为其分配不同的Minion，一个Pod对应一个Minion；在为所述N个Pod分配的Minion上启动所述N个Pod包括的Container；和/或，在为所述L个Pod分配的Minion上启动所述L个Pod包括的Container。

在为未绑定Minion的Pod分配Minion时，会基于第一Service下的其他Pod的考虑，为未绑定Minion的Pod分配与其不同的Minion，以避免同一Service下的不同Pod绑定相同的Minion的情况，进而提高系统的可靠性。

第二方面，提供一种Pod创建设备，该设备包括：

接收单元，用于接收用户的第一服务Service创建请求，所述第一Service创建请求用于请求创建第一Service；其中，所述第一Service创建请求携带需要与所述第一Service进行关联的M个Pod的信息，M为正整数；

创建单元，用于根据所述第一Service创建请求创建所述第一Service；

确定单元，用于确定需要与所述第一Service关联的M个Pod的状态；

所述创建单元，还用于若所述M个Pod的状态表明所述M个Pod中的N个Pod不满足预设的冗余副本要求，则新建所述N个Pod；和/或，若所述M个Pod的状态表明所述M个Pod中的L个Pod尚未创建，则新建所述L个Pod；N、L为正整数，且N≤M，L≤M。

可选的，所述确定单元确定需要与所述第一Service关联的M个Pod的状态，具体包括：

获取所述M个Pod中每个Pod包括的容器Container的状态，其中，一个Pod包括至少一个Container；

根据所述每个Pod包括的Container与所述M个Pod的映射关系确定所述M个Pod中每个Pod的状态。

可选的，所述设备还包括第一标记单元；

所述第一标记单元，用于在根据所述每个Pod包括的Container的状态与所述M个Pod的映射关系确定所述M个Pod中每个Pod的状态之后，若确定所述M个Pod中的P个Pod满足所述冗余副本要求，则将所述P个Pod的标签label标记为所述第一Service，以将所述P个Pod与所述第一Service进行关联。

可选的，所述设备还包括第二标记单元；

所述第二标记单元，用于在新建所述N个Pod，和/或，新建所述L个Pod之后，将所述N个Pod的label标记为所述第一Service，以将所述N个Pod与所述第一Service进行关联；和/或，将所述L个Pod的label标记为所述第一Service，以将所述L个Pod与所述第一Service进行关联。

可选的，所述设备还包括分配单元和启动单元；

所述分配单元，用于获取所述M个Pod中的工作节点Minion的分配情况信息，所述分配情况信息用于指示所述M个Pod中已分配Minion的Pod所占用的Minion；

所述分配单元，还用于根据所述分配情况信息，为所述N个Pod分配与所述已分配Minion的Pod所占用的Minion不同的Minion；和/或，为所述L个Pod分配与所述已分配Minion的Pod所占用的Minion不同的Minion；其中，不同的Pod为其分配不同的Minion，一个Pod对应一个Minion；

所述启动单元，用于在为所述N个Pod分配的Minion上启动所述N个Pod包括的Container；和/或，在为所述L个Pod分配的Minion上启动所述L个Pod包括的Container。

对于此设备所实现的功能与第一方面的方法一一对应，因此对于此设备所实现的功能可以参照第一方面的描述，在此不再赘述。

第三方面，提供一种计算机装置，所述装置包括处理器，所述处理器用于执行存储器中存储的计算机程序时实现如第一方面所述的方法的步骤。

第四方面，提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如第一方面所述的方法的步骤。

本发明实施例中的Pod创建方法是基于Service为创建单位的创建方法，即首先进行Service的创建，在Service的创建过程中，基于该Service的需求进行Pod的创建，这样，由于Service的创建会先于新建的Pod的Minion的绑定，那么后续在针对Pod创建过程中的Minion的绑定时，则能够根据该Service下的Pod进行统一的管理调度，以避免绑定重复的Minion。同时，在Service的创建过程中，还考虑到Pod的副本数量是否满足冗余副本要求的情况，不满足冗余副本要求的Pod也会进行Pod的新建，以保证Service下能够有更多的Pod满足冗余副本要求，进一步提高系统的可靠性。

附图说明

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

图1为本发明实施例提供的Pod创建方法的流程示意图；

图2为本发明实施例提供的Replication Controller确定向Apiserver发送Pod创建请求的流程示意图；

图3为本发明实施例提供的Pod创建设备的一种结构示意图；

图4为本发明实施例提供的计算机装置的一种结构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述。

下面结合附图介绍本发明实施例提供的技术方案。

本发明实施例的技术方案可以应用于多种容器集群管理系统，例如Kubernetes系统。在后续的描述中，将结合Kubernetes系统的场景为例对本发明实施例的技术方案进行描述，但需要说明的是，本发明实施例的技术方案不仅仅可以应用于Kubernetes系统，还可以应用与其他需要进行Pod创建的系统中。

下面将对Kubernetes系统中的与本发明实施例相关的一些模块进行描述，当然，以下的模块的功能可以是在现有技术中已经能够实现的功能，也可以是本发明实施例所增加的一些功能。

Kubecfg：命令行工具，用户能够通过Kubecfg与Kubernetes系统进行交互，例如发起Service创建请求或者Pod创建请求等等。

Apiserver：主要用于Service创建请求或者Pod创建请求的执行。

Etcd：键值存储数据库，存储Kubernetes系统中的信息，例如创建的Service的相关信息、创建的Pod的相关信息或者Pod与Minion的绑定信息等等。

控制管理器(Controller Manager)：可以包括端点控制器(EndPointController，EndPoint-C)和冗余控制器(Replication Controller，Replication-C)。EndPoint Controller主要用于Service与Pod节点绑定过程的监控与管理；ReplicationController主要用于pod的多副本的生成与维护。

Scheduler：主要用于根据调度策略对资源进行调度。

Kubelet：主要用于启动Pod包括的Container。

Docker：主要用于实现Container的管理，例如实现Container的创建、更新、删除等功能。

请参见图1，本发明一实施例提供一种Pod创建方法，下面将结合Kubernetes系统的场景对该方法的流程进行描述。

S01：Kubecfg接收用户的第一Service创建请求。

本发明实施例中，用户在需要创建Service或者Pod时，可以向Kubecfg发起Service创建请求。具体的，Service创建请求中可以包括用户想要创建的Service的名称，以及该Service需要关联的M个Pod的名称等，其中，M为正整数，当然，也可以包括其他任何可能的参数，本发明实施例对此不做限制。

例如，用户想要创建第一Service，则用户可以向Kubecfg发起第一Service创建请求，该第一Service创建请求则是用于请求创建第一Service。

S02：Kubecfg调用Apiserver进行第一Service的创建。

Kubecfg对第一Service创建请求进行响应，并调用Apiserver来进行第一Service的创建。其中，Apiserver的功能包括Service创建功能，因而Kubecfg可以调用Apiserver的Service创建功能来执行第一Service的创建。

S03：Apiserver创建第一Service。

Apiserver可以根据第一Service创建请求进行第一Service的创建。例如，第一Service要求的Service的名称为Service1，则Apiserver可以新创建一Service，并将该Service的名称设置为Service1。

在Apiserver创建第一Service之后，为了使得第一Service的相关信息能够得以长久保存，还可以将创建的第一Service的相关信息持久化到Etcd中。

S04：EndPoint Controller询问Apiserver是否有待处理的Service。

在Service创建完成之后，但还未与Pod进行关联，这样的Service即是待处理的Service。具体的，可以通过Controller Manager中的EndPoint Controller周期性的询问Apiserver，以确定是否有待处理的Service。

S05：若确定结果为是，则EndPoint Controller向Replication Controller发送查询消息。

若是EndPoint Controller周期性的询问Apiserver，确定存在待处理的Service，即上述新创建的第一Service，则EndPoint Controller可以向Replication Controller发送查询消息，以请求Replication Controller查询需该Service关联的M个Pod的状态。其中，查询消息用于请求Replication Controller对这M个Pod进行副本检查操作，来确定这M个Pod是否满足冗余副本要求，当然，同时这M个Pod中可能还存在部分Pod并未创建，因而查询消息还可以请求查询哪些Pod还尚未创建。

具体的，为了使得Replication Controller知道需要查询哪些Pod，因此查询消息中可以携带需要待处理的Service关联的M个Pod的信息，例如该信息可以是M个Pod的名称或者其他能够识别Pod的信息。

S06：Replication Controller向Kubelet请求获取M个Pod包括的Container的状态。

本发明实施例中，在获取Container的状态时，可以是获取该系统中所有的Container的状态，当然，也可以只获取这M个Pod包括的Container的状态，本发明实施例对此不做限制。

S07：Kubelet向每个Docker请求获取Container的状态。

本发明实施例中，Docker用于对Container进行管理，因而Kubelet可以从每个Docker获取该Docker所管理的Container的状态。

S08：每个Docker向Replication Controller反馈该Docker管理的Container的状态。

在每个Docker接收到Kubelet的请求之后，则会向Replication Controller反馈该Docker管理的Container的状态。

S09：Replication Controller根据每个Pod包括的Container与M个Pod的映射关系确定M个Pod的状态。

Replication Controller能够根据这些Container的状态确定出M个Pod的状态。具体的，Replication Controller可以根据Container与Pod的映射关系，可以将Pod与Container对应起来，以确定出M个Pod中每个Pod的状态。其中，一个Pod包括的Container的状态可以反映该Pod的状态。例如，若是一个Pod包括的Container均已在Minion上启动，根据Container与Pod的映射关系，那么就可以知道该Pod已经创建完成。另一方面，这样也可以得知一个Pod的副本数量，从而能够确定该Pod的副本数量是否满足副本冗余要求。例如预设的冗余副本要求为2时，一个Pod已满足冗余副本要求，即该Pod至少包括两个副本。以两个副本为例，这两个副本分别与自身的Container相对应，只要能够从系统得知其相对应的Container已经在Minion上启动，也就能够反推这两个副本已经创建完成，且按照Container与Pod的映射关系，还可以知道该Pod的副本数量为2，从而确定该Pod已满足冗余副本要求。

S10：Replication Controller向Apiserver发送Pod创建请求，Apiserver接收Pod创建请求。

请参见图2，为Replication Controller确定是否向Apiserver发送Pod创建请求的流程示意图。下面以M个Pod中的第一Pod为例对该流程进行描述，其中，第一Pod可以是M个Pod中的任意一个Pod。

S101：确定第一Pod是否已创建。

具体的，Replication Controller获取Container的状态之后，则可以确定第一Pod对应的Container是否已经在Minion上启动，以确定第一Pod是否已经创建。具体如何确定可以参见上述的描述，在此不再赘述。

S102：Replication Controller向Apiserver发送第一Pod创建请求。

若是Replication Controller确定第一Pod不存在相对应的Container，即可以确定这第一Pod尚未创建，则Replication Controller可以向Apiserver发送第一Pod创建请求，以请求Apiserver新建第一Pod。

S103：若确定第一Pod是否创建完成的确定结果为是，Replication Controller确定第一Pod是否满足冗余副本要求。

若是第一Pod已经创建，则Replication Controller可以确定第一Pod的副本数量，进而根据副本数量确定第一Pod是否满足冗余副本要求。其中，冗余副本要求为预先设置好的，具体值可以根据系统的需求进行设置，例如可以设置为2或者3，当然，也可以是其他可能的数值，本发明实施例对此不做限制。

若确定第一Pod是否满足冗余副本要求的确定结果为否，则执行S102。具体的，若Replication Controller确定第一Pod的副本数量不满足冗余副本要求，即对第一Pod进行新建，则Replication Controller也可以向Apiserver发送第一Pod创建请求，以请求Apiserver新建第一Pod。

S104：若确定第一Pod是否满足冗余副本要求的确定结果为是，ReplicationController将第一Pod的label标记为第一Service。

这样，即可以将第一Pod与第一Service进行关联。具体的，由于第一Pod的副本数量为多个，只需要将其中一个副本与第一Service进行关联即可，因而ReplicationController只需要将第一Pod的任意一个副本的label标记为第一Service。这样，当与第一Service关联的这个副本不能使用时，还可以将其他未关联的副本作为备用，进行替换，以保证系统的稳定性。

上述仅以一个Pod的流程为例进行描述，但需要知道的是，在需要新建Pod时，也可以是将第一Service之下的所有Pod执行上述流程之后，最终确定需要新建的Pod，再将新建这些Pod的消息一起发送给Apiserver，以减少Replication Controller与Apiserver的交互次数。例如，Replication Controller最终确定M个Pod中的N个Pod不满足冗余副本要求，以及M个Pod中的L个Pod尚未创建，则Replication Controller可以向Apiserver发送Pod创建请求，请求Apiserver创建这N个Pod以及这L个Pod。当然，Replication Controller最终确定M个Pod中的N个Pod不满足冗余副本要求，则Replication Controller可以向Apiserver发送Pod创建请求，以请求Apiserver创建这N个Pod；或者，M个Pod中的L个Pod尚未创建，则Replication Controller可以向Apiserver发送Pod创建请求，以请求Apiserver创建这这L个Pod。其中，N和L为正整数，且N≤M，L≤M。

请继续参见图1。

S11：Apiserver根据Pod创建请求进行Pod的新建。

Apiserver收到Pod创建请求之后，则可以按照Pod创建请求所要求的进行Pod的创建，另外，在创建完成之后，Apiserver还可以将新建的Pod的label标记为第一Service，并将新建的Pod的相关信息持久化到Etcd中。

S12：Scheduler周期性的询问ApiServer是否有待部署的Pod。

其中，当Pod创建之后，还需要与Minion进行绑定，以在绑定的Minion启动运行，因而可以通过Scheduler周期性的确定是否有需要自身部署Minion的Pod。

S13：若确定有待部署的Pod，则Scheduler获取M个Pod中的Minion的分配情况信息。

在ApiServer向Scheduler反馈存在待部署的Pod时，Scheduler则会获取这些需要部署的Pod的信息，以及当前Minion的资源使用情况，通过这些信息，Scheduler可以知道第一Service下的M个Pod当前的Minion分配情况信息，这样，则可以为N个Pod分配与已分配Minion的Pod所占用的Minion不同的Minion；和/或，为L个Pod分配与已分配Minion的Pod所占用的Minion不同的Minion，以避免分配重复的Minion，进而减少当一个Minion宕机时，第一Service服务大面积失效的可能性，提高系统的稳定性。

具体的，Scheduler得到分配情况信息之后，则可以调用Scheduler调度策略来为待部署的Pod分配Minion。其中，不同的Pod应尽量为其分配不同的Minion，一个Pod对应一个Minion，当然，在无法避免Minion不发生重复时，也可以为多个相同的Pod分配相同的Minion。

S14：Scheduler将为待部署的Pod分配的Minion分配信息发送给ApiServer。

具体的，Minion分配信息可以包括具体为Pod分配的Minion，即需要哪个Minion上启动该Pod包括的Container。ApiServer接收到Minion分配信息之后，还可以将Minion分配信息更新并持久化到Etcd中。

S15：Kubelet询问ApiServer是否存在待启动的Pod。

S16：Kubelet确定存在待启动的Pod，则在为该Pod分配的Minion上启动该Pod包括的Container。

其中，当ApiServer反馈给Kubelet的信息表明当前存在待启动的Pod，即上述已经分配了Minion的Pod时，Kubelet则可以在对应的Minion上通过Docker启动Pod包括的Container。

具体的，如上述为N个Pod分配Minion之后，则可以在为其分配的Minion上分别启动这N个Pod包括的Container；和/或，为L个Pod分配Minion之后，则可以在为其分配的Minion上分别启动这L个Pod包括的Container。

下面，将以一具体的例子对本发明实施例的技术方案进行描述。

同样以Kubernetes系统为例，在该Kubernetes系统中，已存在已创建完成的Pod2和Pod3。其中，预设的冗余副本要求为2，Pod2满足冗余副本要求，Pod3不满足冗余副本要求。用户希望创建一个Service1，Service1与Pod1、Pod和Pod3关联。那么Service1的创建过程如下。

用户可以通过Kubecfg发起Service1创建请求，Kubecfg对Service1创建请求进行响应，并调用ApiServer创建Service1，ApiServer创建Service1之后，将Service1的相关信息持久化到Etcd中。

当EndPoint Controller周期性的询问ApiServer时，则能够发现当前新建的Service1，并且知晓需要与Service1关联的Pod为Pod1、Pod2和Pod3，则EndPointController向Replication Controller查询消息，请求Replication Controller针对Pod1、Pod2和Pod3进行多副本检查。

Replication Controller向Kubelet请求获取Pod1、Pod2和Pod3的当前状态。Kubelet通过Docker获得状态检测结果，得到Pod1、Pod2和Pod3的当前状态如表1所示。

表1

从表1可见，其中，Pod1当前尚未创建；Pod2已创建且满足冗余副本要求；Pod3已创建，但不满足冗余副本要求，需要对Pod1和Pod3进行新建。因此Replication-Controller将状态检测结果发送给EndPoint Controller，EndPoint Controller向ApiServer发送Pod创建请求，请求ApiServer创建新的Pod1和Pod3，并在Pod创建请求携带将Pod1和Pod3的label标记为Service1的信息；对于满足冗余副本要求的Pod2，EndPoint Controller直接将Pod2的label标记为Service1，由于Pod2包括两个副本，因而EndPoint Controller可以选择其中任意一个进行标记。具体的，EndPoint Controller需要执行的动作如下表2所示。

表2

ApiServer收到Pod创建请求之后，创建Pod1和Pod3之后，将新建的Pod1和Pod3的label标记为Service1，并将Pod1和Pod3的相关信息持久化到Etcd中，至此Service1包括的Pod1、Pod2和Pod3均已创建，但是新创建的Pod1和Pod3还未进行部署，那么在后续的部署过程中，则可以优先为其选择与Pod2不同的Minion，从而避免Service1关联的Pod过多的部署在相同的Minion上，提高系统稳定性。

当Scheduler周期性的询问ApiServer是否有待部署的Pod时，则能够发现Pod1和Pod3还未分配Minion，且Service1下的Pod2目前部署在Minion2上(这里假设将部署在Minion2的这一个副本的label标记为Service1)，则Scheduler可以根据Scheduler调度策略，确定满足Pod1的资源需求的Minion1和满足Pod3资源需求的Minion3，则Scheduler可以将确定的分配信息发送给ApiServer，即将Pod1与Minion1绑定，以及将Pod3与Minion3绑定的分配信息，ApiServer接收到该分配信息后将Pod1与Minion1进行绑定，以及将Pod3与Minion3进行绑定，并将该分配消息持久化到Etcd中。

当Kubelet周期性的询问ApiServer是否有待启动的Pod时，则能够发现已分配Minion后的Pod1和Pod3待启动，因而Kubelet可以分别通知Minion1和Minion3，以通过Docker分别在Minion1上启动Pod1包括的Container，以及在Minion3上启动Pod3包括的Container。最终，创建后的Service1的情况如表3所示。

其中，Service1关联的Pod1和Pod3均是新创建的Pod，当然，也可以是之前已经创建的Pod，例如Pod3，在进行Pod创建之前，已经存在一个副本，也可以将该副本的label标记为Service1。

表3

综上所述，本发明实施例中的Pod创建方法是基于Service为创建单位的创建方法，即首先进行Service的创建，在Service的创建过程中，基于该Service的需求进行Pod的创建，这样，由于Service的创建会先于新建的Pod的Minion的绑定，那么后续在针对Pod创建过程中的Minion的绑定时，则能够根据该Service下的Pod进行统一的管理调度，以避免绑定重复的Minion。同时，在Service的创建过程中，还考虑到Pod的副本数量是否满足冗余副本要求的情况，不满足冗余副本要求的Pod也会进行Pod的新建，以保证Service下能够有更多的Pod满足冗余副本要求，进一步提高系统的可靠性。其中，本发明实施例中同时完成Service与Pod关联，以及Pod的副本检查两个操作，能够减轻网络的负载，进一步提高系统的稳定性。

请参见图3，基于同一发明构思，本发明一实施例提供一种Pod创建设备，该设备包括：

接收单元301，用于接收用户的第一服务Service创建请求，第一Service创建请求用于请求创建第一Service；其中，第一Service创建请求携带需要与第一Service进行关联的M个Pod的信息，M为正整数；

创建单元302，用于根据第一Service创建请求创建第一Service；

确定单元303，用于确定需要与第一Service关联的M个Pod的状态；

创建单元302，还用于若M个Pod的状态表明M个Pod中的N个Pod不满足预设的冗余副本要求，则新建N个Pod；和/或，若M个Pod的状态表明M个Pod中的L个Pod尚未创建，则新建L个Pod；N、L为正整数，且N≤M，L≤M。

可选的，确定单元303确定需要与第一Service关联的M个Pod的状态，具体包括：

获取M个Pod中每个Pod包括的容器Container的状态，其中，一个Pod包括至少一个Container；

根据每个Pod包括的Container与M个Pod的映射关系确定M个Pod中每个Pod的状态。

可选的，设备还包括第一标记单元304；

第一标记单元304，用于在根据每个Pod包括的Container的状态与M个Pod的映射关系确定M个Pod中每个Pod的状态之后，若确定M个Pod中的P个Pod满足冗余副本要求，则将P个Pod的标签label标记为第一Service，以将P个Pod与第一Service进行关联。

可选的，设备还包括第二标记单元305；

第二标记单元305，用于在新建N个Pod，和/或，新建L个Pod之后，将N个Pod的label标记为第一Service，以将N个Pod与第一Service进行关联；和/或，将L个Pod的label标记为第一Service，以将L个Pod与第一Service进行关联。

可选的，设备还包括分配单元306和启动单元307；

分配单元306，用于获取M个Pod中的工作节点Minion的分配情况信息，分配情况信息用于指示M个Pod中已分配Minion的Pod所占用的Minion；

分配单元306，还用于根据分配情况信息，为N个Pod分配与已分配Minion的Pod所占用的Minion不同的Minion；和/或，为L个Pod分配与已分配Minion的Pod所占用的Minion不同的Minion；其中，不同的Pod为其分配不同的Minion，一个Pod对应一个Minion；

启动单元307，用于在为N个Pod分配的Minion上启动N个Pod包括的Container；和/或，在为L个Pod分配的Minion上启动L个Pod包括的Container。

该设备可以用于执行图1所示的实施例所提供的方法，因此，对于该设备的各功能模块所能够实现的功能等可参考图1所示的实施例的描述，不多赘述。其中，第一标记单元304～启动单元307在图3中一并示出，但需要知道的是，第一标记单元304～启动单元307并不是必选的功能模块，因此在图3中以虚线示出。

请参见图4，本发明一实施例还提供一种计算机装置，该计算机装置包括至少一个处理器401，至少一个处理器401用于执行存储器中存储的计算机程序时实现图1所示的实施例提供的Pod创建方法的步骤。

可选的，至少一个处理器401具体可以包括中央处理器(CPU)、特定应用集成电路(application specific integrated circuit，ASIC)，可以是一个或多个用于控制程序执行的集成电路，可以是使用现场可编程门阵列(field programmable gate array，FPGA)开发的硬件电路，可以是基带处理器。

可选的，至少一个处理器401可以包括至少一个处理核心。

可选的，该计算机装置还包括存储器402，存储器402可以包括只读存储器(readonly memory，ROM)、随机存取存储器(random access memory，RAM)和磁盘存储器。存储器402用于存储至少一个处理器401运行时所需的数据。存储器402的数量为一个或多个。其中，存储器402在图4中一并示出，但需要知道的是存储器402不是必选的功能模块，因此在图4中以虚线示出。

基于同一发明构思，本发明实施例提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机指令，当所述计算机指令在计算机上运行时，使得计算机执行如图1所示的方法。

在具体的实施过程中，计算机可读存储介质包括：通用串行总线闪存盘(Universal Serial Bus flash drive，USB)、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的存储介质。

在本发明实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。例如，以上所描述的设备实施例仅仅是示意性的，例如，所述单元或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性或其它的形式。

在本发明实施例中的各功能单元可以集成在一个处理单元中，或者各个单元也可以均是独立的物理模块。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明实施例的技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备，例如可以是个人计算机，服务器，或者网络设备等，或处理器(processor)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：通用串行总线闪存盘(universal serial bus flash drive)、移动硬盘、ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，以上实施例仅用以对本申请的技术方案进行了详细介绍，但以上实施例的说明只是用于帮助理解本发明实施例的方法，不应理解为对本发明实施例的限制。本技术领域的技术人员可轻易想到的变化或替换，都应涵盖在本发明实施例的保护范围之内。

Claims (8)

1.一种容器集Pod创建方法，其特征在于，包括：

接收用户的第一服务创建请求，所述第一服务创建请求用于请求创建第一服务；其中，所述第一服务创建请求携带需要与所述第一服务进行关联的M个Pod的信息，M为正整数；

根据所述第一服务创建请求创建所述第一服务；

确定需要与所述第一服务关联的M个Pod的状态，包括：获取所述M个Pod中每个Pod包括的容器Container的状态，其中，一个Pod包括至少一个Container；根据所述每个Pod包括的Container与所述M个Pod的映射关系确定所述M个Pod中每个Pod的状态；

若所述M个Pod的状态表明所述M个Pod中的N个Pod不满足预设的冗余副本要求，则新建所述N个Pod；和/或，若所述M个Pod的状态表明所述M个Pod中的L个Pod尚未创建，则新建所述L个Pod；N、L为正整数，且N≤M，L≤M。

2.如权利要求1所述的方法，其特征在于，在根据所述每个Pod包括的Container的状态与所述M个Pod的映射关系确定所述M个Pod中每个Pod的状态之后，所述方法还包括：

若确定所述M个Pod中的P个Pod满足所述冗余副本要求，则将所述P个Pod的标签label标记为所述第一服务，以将所述P个Pod与所述第一服务进行关联。

3.如权利要求1所述的方法，其特征在于，在新建所述N个Pod，和/或，新建所述L个Pod之后，所述方法还包括：

将所述N个Pod的label标记为所述第一服务，以将所述N个Pod与所述第一服务进行关联；和/或，将所述L个Pod的label标记为所述第一服务，以将所述L个Pod与所述第一服务进行关联。

4.如权利要求1所述的方法，其特征在于，在新建所述N个Pod，和/或，新建所述L个Pod之后，所述方法还包括：

获取所述M个Pod中的工作节点Minion的分配情况信息，所述分配情况信息用于指示所述M个Pod中已分配Minion的Pod所占用的Minion；

根据所述分配情况信息，为所述N个Pod分配与所述已分配Minion的Pod所占用的Minion不同的Minion；和/或，为所述L个Pod分配与所述已分配Minion的Pod所占用的Minion不同的Minion；其中，不同的Pod为其分配不同的Minion，一个Pod对应一个Minion；

在为所述N个Pod分配的Minion上启动所述N个Pod包括的Container；和/或，在为所述L个Pod分配的Minion上启动所述L个Pod包括的Container。

5.一种Pod创建设备，其特征在于，包括：

接收单元，用于接收用户的第一服务创建请求，所述第一服务创建请求用于请求创建第一服务；其中，所述第一服务创建请求携带需要与所述第一服务进行关联的M个Pod的信息，M为正整数；

创建单元，用于根据所述第一服务创建请求创建所述第一服务；

确定单元，用于确定需要与所述第一服务关联的M个Pod的状态；

所述确定单元，具体用于获取所述M个Pod中每个Pod包括的容器Container的状态，其中，一个Pod包括至少一个Container；根据所述每个Pod包括的Container与所述M个Pod的映射关系确定所述M个Pod中每个Pod的状态；

所述创建单元，还用于若所述M个Pod的状态表明所述M个Pod中的N个Pod不满足预设的冗余副本要求，则新建所述N个Pod；和/或，若所述M个Pod的状态表明所述M个Pod中的L个Pod尚未创建，则新建所述L个Pod；N、L为正整数，且N≤M，L≤M。

6.如权利要求5所述的设备，其特征在于，所述设备还包括分配单元和启动单元；

所述分配单元，用于获取所述M个Pod中的工作节点Minion的分配情况信息，所述分配情况信息用于指示所述M个Pod中已分配Minion的Pod所占用的Minion；

所述分配单元，还用于根据所述分配情况信息，为所述N个Pod分配与所述已分配Minion的Pod所占用的Minion不同的Minion；和/或，为所述L个Pod分配与所述已分配Minion的Pod所占用的Minion不同的Minion；其中，不同的Pod为其分配不同的Minion，一个Pod对应一个Minion；

所述启动单元，用于在为所述N个Pod分配的Minion上启动所述N个Pod包括的Container；和/或，在为所述L个Pod分配的Minion上启动所述L个Pod包括的Container。

7.一种计算机装置，其特征在于，所述装置包括处理器，所述处理器用于执行存储器中存储的计算机程序时实现如权利要求1-4中任一项所述方法的步骤。

8.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1-4中任一项所述方法的步骤。

Images