CN114385349A - 容器组部署方法和装置 - Google Patents

Abstract

公开了一种容器组部署方法和装置。第一工作负载维护容器组缓存池，容器组缓存池中缓存至少一个容器组。响应于创建第二工作负载或第二工作负载的扩容请求，从容器组缓存池中选取容器组，将所获取的容器组绑定到第二工作负载，并移动到第二工作负载中。在进一步的实施例中，当容器组在容器组缓存池中时，在容器组中提前启动容器运行时与函数或应用无关的第一部分。而响应于容器组被移动到第二工作负载，在容器组中启动容器运行时与第二工作负载所对应的函数或应用相关的第二部分。由此，提前由独立于租户函数的第一工作负载维护容器组缓存池，使得当租户需要扩容时可以直接从缓存池中提取已缓存的容器组资源，实现了容器组的高效部署和快速扩容。

Description

容器组部署方法和装置

技术领域

本公开涉及云计算领域，特别涉及容器组的部署方案。

背景技术

随着互联网技术进入云计算时代，“无服务器”(Serverless)架构已成为云原生应用的重要技术组成部分。

而无服务器架构的一项重要技术指标为弹性伸缩，主要表现在两个层面：弹性能力和弹性性能。无服务器架构期望能够从弹性能力和弹性性能两个层面向客户提供良好的体验，以帮助客户实现价值最大化。

弹性伸缩所关注的问题主要是容量规划与实际集群负载间的矛盾。当现有集群的资源无法承载流量压力时，通过调整集群的规模或者资源的分配，来保障系统的稳定性。同样地，在集群负载较低时，尽量降低集群的资源配置，从而减少闲置资源的浪费带来的成本开销。

为了提升弹性能力和弹性性能，容器组(下文中也可以将其称为“Pod”)的高效创建是非常重要的。

在原有的Kubernetes(K8s)的Pod生产流程中，Pod创建流程需要经过多个阶段：Pod创建请求提交(例如提交到etcd系统)、调度、Pod生产、网络初始化、容器数据卷挂载、容器镜像下载、容器启动等。在整个Pod生产过程中，受基础设施调度策略和资源状态的影响较大，导致Pod创建所耗费的时间较长。

另一方面，由于Kubernetes面向终态的设计原则，工作负载(Workload)的模板(Template)及容器组(Pod)的模板中的信息发生变化的时候，都会导致Pod重建。

出于这样的原因，在Kubernetes中做Pod缓存是一件非常困难的事情。这是因为必须在一组函数或者应用具有相同的容器运行时(runtime)而不需要改变容器配置(Spec)上例如环境变量、容器镜像的情况下，才能实现Pod缓存。

目前业界已有的Pod池化方案，主要针对单一应用或者单个函数，创建一批Pod作为缓存池子，这些缓存的Pod只服务于一个函数，其目的是避免引起Pod重建。

图1示意性地示出了一种现有Pod管理方案中Pod、函数实例以及工作负载之间的关系。

如图1所示，Pod池子工作负载维护的Pod池子中缓存有多个Pod(附图中以七边形图形示意性表示Pod)。多个函数实例Fn-A、Fn-B、Fn-C分别从Pod池子中选择Pod来使用。但是这些函数实例都处于同一个工作负载之中。对于各个函数或应用的Pod管理，无法利用Kubernetes已有的工作负载的方式来进行操作，只能通过自定义的标签(Label)来检索与指定函数或应用相关的Pod。当创建池子的工作负载发生变化的时候，分配给多个函数或应用的Pod都将受到对应工作负载变更的影响而发生重建。如果删除了管理这些Pod的工作负载，那么所有的Pod都将被删除。

这样，在多函数、多应用的场景下，几乎无法做到对Pod的有效管理。

因此，仍然需要一种基于K8s架构的通用的池化缓存架构设计和实现，以帮助在Serverless场景下提升应用及函数的弹性性能，做到实例极速启动，帮助用户实现更灵活的计算模型。

发明内容

本公开要解决的一个技术问题是提供一种容器组池化缓存部署方案，其能够实现容器的快速启动。

根据本公开的第一个方面，提供了一种容器组部署方法，包括：第一工作负载维护容器组缓存池，容器组缓存池中缓存至少一个容器组；以及响应于创建第二工作负载或第二工作负载的扩容请求，从容器组缓存池中选取容器组，将所获取的容器组绑定到第二工作负载，并移动到第二工作负载中。

可选地，第一工作负载维护多个容器组缓存池，每个容器组缓存池中缓存的容器组具有相同的资源配置规格，不同容器组缓存池中缓存的容器组具有不同的资源配置规格。从容器组缓存池中选取容器组的步骤可以包括：根据第二工作负载对容器组资源配置规格的需求，从与第二工作负载匹配的容器组缓存池中选取容器组。

可选地，在一个容器组缓存池中的容器组消耗速度较快的情况下，从其它容器组缓存池中调配容器组以补充一个容器组缓存池。

可选地，第一工作负载是针对使用相同镜像的函数或应用构造的通用工作负载。

可选地，第二工作负载是响应于函数或应用的创建而创建的对应于函数或应用的工作负载，函数或应用使用相同镜像。

可选地，该方法还可以包括：当容器组在容器组缓存池中时，在容器组中提前启动容器运行时与函数或应用无关的第一部分；以及/或者响应于容器组被移动到第二工作负载，在容器组中启动容器运行时与第二工作负载所对应的函数或应用相关的第二部分；以及/或者在容器组缓存池中的容器组提前启动容器运行时与函数或应用无关的第一部分之后，使所述容器组中的容器处于待机状态，以等待所述容器组被绑定到第二工作负载从而启动容器运行时与第二工作负载所对应的函数或应用相关的第二部分。

可选地，第一部分包括下述至少一项：容器启动、容器运行时框架初始化部分。

可选地，第二部分包括下述至少一项：环境变量的动态注入、函数或应用的信息或代码加载。

可选地，该方法还可以包括：在容器组缓存池中的容器组提前启动容器运行时的第一部分之后，对容器组中的容器的活性状态和就绪状态进行控制：使得容器满足活性状态要求，而不满足就绪状态要求；或者使得容器既满足活性状态要求，也满足就绪状态要求。

可选地，该方法还可以包括：响应于容器组被绑定到第二工作负载，对容器组进行下述至少一项修改：更新容器组的标签，使得第二工作负载对应的容器组选择器能够检索到该容器组；以及将容器组的属主信息修改为第二工作负载。

可选地，该方法还可以包括：在将所获取的容器组绑定到第二工作负载之后，维护容器组的状态，状态包括：绑定成功、启动成功、失败、删除。其中，绑定成功状态表示已从容器组缓存池中选取出该容器组并被绑定到第二工作负载。启动成功状态表示绑定成功的容器组的容器运行时已启动成功进入就绪状态。失败状态表示绑定成功的容器组的容器运行时启动失败或启动超时，或者启动成功的容器组的容器运行时出错。对于因容器运行时启动失败或启动超时而进入失败状态的容器组，返回绑定成功状态以重新尝试启动容器运行时，对于因容器运行时出错而进入失败状态的容器组，在容器运行时排除故障并恢复就绪状态后，恢复到启动成功状态。删除状态表示容器组要被删除。在绑定成功的容器组的容器运行时多次启动未成功，或者失败状态的容器组的容器运行时未能排除故障的情况下，容器组进入删除状态。

根据本公开的第二个方面，提供了一种容器组部署装置，包括：缓存装置，用于使用第一工作负载维护容器组缓存池，容器组缓存池中缓存至少一个容器组；以及迁移装置，用于响应于创建第二工作负载或第二工作负载的扩容请求，从容器组缓存池中选取容器组，将所获取的容器组绑定到第二工作负载，并移动到第二工作负载中。

可选地，该装置还可以包括：第一启动装置，用于当容器组在容器组缓存池中时，在容器组中提前启动容器运行时与函数或应用无关的第一部分；以及/或者第二启动装置，用于响应于容器组被移动到第二工作负载，在容器组中启动容器运行时与第二工作负载所对应的函数或应用相关的第二部分；以及/或者待机装置，用于在容器组缓存池中的容器组提前启动容器运行时与函数或应用无关的第一部分之后，使容器组中的容器处于待机状态，以等待容器组被绑定到第二工作负载从而启动容器运行时与第二工作负载所对应的函数或应用相关的第二部分。其中，第一工作负载是针对使用相同镜像的函数或应用构造的通用工作负载，第二工作负载是响应于函数或应用的创建而创建的对应于函数或应用的工作负载，函数或应用使用相同镜像。

根据本公开的第三个方面，提供了一种计算设备，包括：处理器；以及存储器，其上存储有可执行代码，当可执行代码被处理器执行时，使处理器执行如上述第一方面所述的方法。

根据本公开的第四个方面，提供了一种计算机程序产品，包括可执行代码，当所述可执行代码被电子设备的处理器执行时，使所述处理器执行如上述第一方面所述的方法。

根据本公开的第五个方面，提供了一种非暂时性机器可读存储介质，其上存储有可执行代码，当可执行代码被电子设备的处理器执行时，使处理器执行如上述第一方面所述的方法。

由此，提供了一种例如可以面向多租户场景的通用池化能力，能够用于多个场景，加速基于Kubernetes场景下的Pod创建，提升Pod启动性能，带来机制弹性能力。提前由独立于租户函数的第一工作负载维护容器组缓存池，使得当租户需要扩容时可以直接从缓存池中提取已缓存的容器组资源，实现了容器组的高效部署和快速扩容。

进一步地，在实施例中，通过提前启动好Pod的容器运行时的通用部分，在需要提供服务或扩容的时候直接使用已缓存Pod资源，并进一步启动容器运行时的个性化部分，达到高效部署和快速扩容的目的。

进一步地，在实施例中，利用不同函数或应用的弹性需求客观差异，实现多个函数或应用的多租模式对缓存资源池的最大利用。同时，针对多个函数或应用，还提供了一种相互隔离的Pod管理方案。

附图说明

通过结合附图对本公开示例性实施方式进行更详细的描述，本公开的上述以及其它目的、特征和优势将变得更加明显，其中，在本公开示例性实施方式中，相同的参考标号通常代表相同部件。

图1示意性地示出了一种现有Pod管理方案中Pod、函数实例以及工作负载之间的关系。

图2是根据本公开的容器组部署方法的示意性流程图。

图3是根据本公开的容器组部署装置的示意性框图。

图4示出了包括不同资源规格的Pod缓存池的示意图。

图5示出了根据本公开进一步实施例的容器组部署方法的示意性流程图。

图6示出了根据本公开进一步实施例的容器组部署装置的示意性框图。

图7示意性地示出了可以用于实施根据本公开的Pod部署方案的系统架构图。

图8示意性地示出了容器运行时的分阶段启动方案。

图9示意性地示出了根据本公开的容器组部署方案所采用的Pod生命周期管理方案。

图10示出了根据本发明一实施例可用于实现上述容器组部署方法的计算设备的结构示意图。

具体实施方式

下面将参照附图更详细地描述本公开的优选实施方式。虽然附图中显示了本公开的优选实施方式，然而应该理解，可以以各种形式实现本公开而不应被这里阐述的实施方式所限制。相反，提供这些实施方式是为了使本公开更加透彻和完整，并且能够将本公开的范围完整地传达给本领域的技术人员。

首先，简要介绍本申请涉及的几个术语。

Kubernetes(简称“K8s”)是一种容器集群管理系统，其提供基于容器的应用编排，应用部署、维护、扩展机制等功能，利用Kubernetes能方便地管理跨机器运行容器化的应用。

容器组(Pod)是Kubernetes创建或部署的最小/最简单的基本单位，一个Pod代表集群上正在运行的一个进程。一个Pod封装一个应用容器(也可以有多个容器)，存储资源、一个独立的网络IP以及管理控制容器运行方式的策略选项。在Kubernetes中，Pod代表的是集群上处于运行状态的一组容器。

工作负载(Workload)是在Kubernetes上运行的应用程序。无论工作负载是单一组件还是由多个一同工作的组件构成，在Kubernetes中，都可以在一组Pod中运行。换句话说，工作负载管理着一组具有统一功能的Pod资源。

容器(Container)作为Pod资源的基本组成单位，负责提供应用程序组件基本的运行环境。Pod负责对一组容器进行编排，定义容器层面基本依赖和生命周期。容器的运行状态共同构成Pod运行状态。

容器运行时(ContainerRuntime)是指用于无服务器计算的运行时，能够基于在线获取的代码或容器中指定位置的文件来创建和运行容器的程序。

Pod池化是指基于Kubernetes不可变基础设施架构，以Pod为最小资源粒度的资源编排，在Serverless场景下，通过提前准备好Pod资源，在需要扩容的时候直接复用已有的Pod资源，提高部署和扩容效率。

下面，参考附图描述根据本公开的容器组(Pod)池化缓存部署方案。

图2是根据本公开的Pod部署方法的示意性流程图。

图3是根据本公开的Pod部署装置的示意性框图。

如图3所示，根据本公开的Pod部署装置100可以包括缓存装置110和迁移装置120。

如图2所示，在步骤S110，例如可以通过缓存装置110，由第一工作负载维护Pod缓存池。Pod缓存池中可以缓存至少一个Pod。

然后，在步骤S120，响应于创建第二工作负载或第二工作负载的扩容请求，例如可以通过迁移装置120，从所述Pod缓存池中选取Pod，将所获取的Pod绑定到第二工作负载，并移动到第二工作负载中。

第一工作负载，也可以称为“池化缓存工作负载”或“池子工作负载”，第一工作负载生产Pod资源，并将其缓存在Pod缓存池中。

第一工作负载是针对使用相同镜像的函数或应用(同一类容器运行时)构造的通用工作负载。第一工作负载不体现与具体函数或应用相关的信息。

使用相同镜像的多个函数或应用发起扩容需求的时候，都会从第一工作负载中选取指定数量的Pod，然后会将选定数量的Pod绑定并移动到函数或应用自己的工作负载(即下文将描述的第二工作负载，也可以称为“函数工作负载”或“应用工作负载”)中。

这样，已经移动到函数或应用自己的第二工作负载中的Pod将不再受第一工作负载所维护的Pod缓存池子的影响。即使Pod缓存池子发生重建也不会影响函数或应用的第二工作负载中Pod的重建。

这里，关于第一工作负载的类型，可以直接使用K8s官方的工作负载如Deployment资源，也可以使用第三方开源，或者自定义的工作负载资源。

第二工作负载，也可以称为“函数工作负载”或“应用工作负载”，是响应于函数或应用的创建而创建的对应于所创建函数或应用的工作负载。这里，所创建函数或应用使用上述第一工作负载所针对的相同镜像。

当创建一个函数，或者发布一个应用的时候，对于指定的应用或函数需要创建指定数量的Pod实例。为此，可以创建一个用于使用池化资源的工作负载，即第二工作负载，来管理真正从缓存池(CachePool)中分配给具体函数或应用的Pod。

该第二工作负载与具体的应用和函数相关。第二工作负载可以包含一些与函数或应用相关的信息，包括函数/应用名、所依赖的运行时信息等。

创建第二工作负载之后，或者收到第二工作负载的扩容请求之后，可以根据第二工作负载对于Pod数量的需求，并根据函数或应用的类型，从与该类型匹配的Pod缓存池子中绑定并移动Pod到当前第二工作负载中。

完成缓存Pod的分配调度之后，可以按照配置(Spec)要求，向指定容器发送请求以要求完成函数或应用的运行。

并且，在完成Pod移动之后，每个函数或应用的第二工作负载分别管理分配给自己的Pod资源。

第二工作负载可以使用自定义的工作负载类型，以便能够提供Pod移动的时候Replicas的一致性。

这里，响应于Pod被绑定到第二工作负载，可以对Pod做一些修改。

首先，可以更新池子中选出的Pod的标签(Labels)，使得第二工作负载对应的Pod选择器能够检索到该Pod。

其次，还可以修改从池子中挑出的Pod的所属资源(OwnerReference)信息，将该Pod的属主(Owner)信息修改为第二工作负载。

另外，为了提高Pod缓存池子的资源利用率和分配速度，还可以采用Pod分级管理的方案。

图4示出了包括不同资源规格的Pod缓存池的示意图。

如图4所示，第一工作负载可以维护多个Pod缓存池，每个Pod缓存池中缓存的Pod可以具有相同的资源配置规格，不同Pod缓存池中缓存的Pod可以具有不同的资源配置规格。可以是一个第一工作负载维护多个Pod缓存池，也可以由多个第一工作负载分别维护多个Pod缓存池。

这样，当要从Pod缓存池中选取Pod时，可以根据第二工作负载对Pod资源配置规格的需求，从与第二工作负载匹配的Pod缓存池中选取Pod。

图4中示出了3种资源规格的Pod缓存池，2C4G(2核4G内存)、1C2G(1核2G内存)、0.5C1G(0.5核1G内存)。

可以将这几个不同资源规格的Pod缓存池子组成一个Pod缓存池集合。

然后，根据整个集合的资源使用情况，动态调整分配给每个工作负载的副本(Replicas)数量。

在一个Pod缓存池中的Pod消耗速度较快的情况下，可以从其它Pod缓存池中调配Pod以补充所述一个Pod缓存池。

如果2C4G的Pod消耗速度比较大，则可以直接通过原地VPA(Pod垂直自动扩缩容)的方式从较小资源规格(例如1C2G)的Pod缓存池中调度Pod来补充大规格的Pod资源，做到Pod的动态调配。

可选地，本公开的池化缓存方案既可以支持单一缓存池，也可以支持多个缓存池级连。每一个缓存池可以像内存分配(Malloc Bin Class)中的Bin一样，分别对应于特定的资源配置规格。

换言之，可以提供两种模式：一种是基于资源原地升级特征前提的单一缓存池模式；另一种是多个资源配置规格的缓存池级连模式。

由此，利用原地VPA可以维护具有统一资源配置规格的单一缓存池，也可以为其它不同资源配置规格的工作负载提供缓存容器，从而提升单一缓存池的利用率。

而且，在节省资源的同时，可以提升Pod缓存命中率。

上文中描述了Pod的缓存和迁移方案。在此基础上，还可以进一步对Pod内容器运行时的部署进行优化。

为了适配Pod池化，加速池化容器运行时的启动，可以使容器运行时能够支持多个启动阶段，尽可能做到分阶段启动，使得与函数或应用无关的部分和与函数或应用相关的部分能够分阶段启动。在Pod在Pod缓存池中的时候可以支持容器运行时与函数或应用无关的第一部分提前启动。当池子中的Pod被分配(或称“绑定”)给具体的函数或应用并从而移动到第二工作负载的时候，再完成容器运行时与具体函数或应用密切相关的启动。

具体说来，函数或应用中有一部分逻辑是通用的，是用通用编程语言实现的，与具体编程语言无关，可以在Pod缓存池中提前启动；另一部分逻辑是与具体函数或应用相关的，并且往往是用与函数或应用对应的编程语言实现的，因此只能在绑定到函数或应用对应的第二工作负载之后才能启动。

为了支持池化的通用性，避免针对每种编程语言的容器运行时分别维护多个各自独立的Pod缓存池，可以在容器镜像内部将容器运行时与具体编程语言无关的通用部分(第一部分)和与具体编程语言相关的部分(第二部分)分成了两个部分。对于Pod缓存池中的Pod，可以提前启动运行时的与具体编程语言无关的第一部分。而在将Pod绑定到具体的函数或应用之后，在第二部分的引导加载程序(bootloader)运行阶段启动运行时与具体编程语言相关的第二部分。这样，Pod缓存池可以为不同编程语言的第二工作负载服务，而不需要为每一种编程语言分别维护一个缓存池。

图5示出了根据本公开进一步实施例的Pod部署方法的示意性流程图。

图5中的步骤S110和S120可以与上文描述的步骤相同。

图6示出了根据本公开进一步实施例的Pod部署装置的示意性框图。

如图6所示，除了上文中已经描述的缓存装置110和迁移装置120，Pod部署装置100还可以包括第一启动装置115、第二启动装置125、待机装置130。

如图5所示，在步骤S115，当Pod在Pod缓存池中时，例如可以通过第一启动装置115，在Pod中提前启动容器运行时的与函数或应用无关的第一部分。

第一部分例如可以是与编程语言无关的部分。函数或应用的部分逻辑是与编程语言无关的逻辑，可以是使用通用编程语言(例如RUST编程语言)实现的。这部分逻辑与函数或应用无关，可以提前启动。

第一部分例如可以包括下述至少一项：容器启动、容器运行时框架初始化部分。

在步骤S125，响应于Pod被绑定到第二工作负载，例如可以通过第二启动装置125，在Pod中启动容器运行时的与第二工作负载所对应的函数或应用相关的第二部分。

第二部分例如可以是包含了很多与函数或应用所使用的编程语言的启动部分，这部分逻辑与函数或应用直接相关，不能在提前启动，需要在绑定到第二工作负载之后再相应启动。

第二部分例如可以包括下述至少一项：环境变量的动态注入、函数或应用的信息或代码加载。

换言之，在Pod缓存池中缓存Pod时，可以提前启动一些跨函数/跨应用、跨语音的通用部分。然后在将Pod移动到第二工作负载的过程中或之后，可以再启动与函数/应用、语音等密切相关的个性化部分。

为了后续选择满足条件的缓存Pod，可以定义多种容器运行时类型，例如针对指定编程语言类型的运行时，以及针对指定函数或应用类型的运行时。

这样，在Pod移动的过程中，可以开始加载一些Pod容器运行时层面的逻辑。对Pod的移动和Pod中容器运行时(Runtime)的运行可以是并发完成的。

例如，针对函数计算的场景，可以将用于函数计算的运行时容器的生命周期分成多个阶段：容器启动阶段、函数运行时框架(Runtime Framework)启动(初始化)阶段、代码加载阶段、代码执行阶段。

可以将这些阶段(部分)分别划分到两个大阶段，即在Pod缓存池子中提前启动(无状态启动)的第一部分和绑定到具体的函数或应用时在启动的第二部分。

首先，在第一个大阶段，在Pod缓存池子中提前无状态启动部分逻辑(或处理/操作)。这部分主要可以包括与具体函数或应用无关的部分，例如容器启动、函数运行时框架初始化部分等。

在完成这个阶段启动之后，容器可以处于一种待机(Standby)状态，以等待第二阶段(第二部分)启动。例如，可以通过待机装置130，在Pod缓存池中的Pod提前启动容器运行时与函数或应用无关的第一部分之后，使Pod中的容器处于待机状态，以等待Pod被绑定到第二工作负载，从而启动容器运行时与第二工作负载所对应的函数或应用相关的第二部分。

在这个状态下，容器可以处于运行(Running)状态。在此基础上，针对基于K8s的活性(Liveness)和就绪(Readiness)状态，可以提供了两个层面的支持：

(1)一种场景是让完成第一阶段的容器必须通过活性状态要求，但可以不通过就绪状态要求；

(2)另一种场景是可以让活性状态要求和就绪状态要求都通过。

换言之，在Pod缓存池中的Pod提前启动容器运行时的第一部分之后，可以对Pod中的容器的活性状态和就绪状态进行控制。可以使得容器满足活性状态要求，而不满足就绪状态要求。或者也可以使得容器既满足活性状态要求，也满足就绪状态要求。

关于这一点，针对各种具体的场景可以做不同的设置。

然后，在第二个大阶段，在将池化Pod绑定到具体函数或应用时，启动另一部分逻辑(或处理/操作)。

当将池化Pod与具体运行实例(函数或应用)绑定的时候，会向容器发起第二大阶段的启动。

例如，可以执行环境变量的动态注入、应用信息/代码的加载等，以配合运行时(Runtime)完成第二大阶段的启动。

至此，已详细描述了根据本公开的Pod池化缓存方案。

图7示意性地示出了可以用于实施根据本公开的Pod部署方案的系统架构图。

如图7所示，第一工作负载维护的多个Pod缓存池中缓存有多个Pod。

缓存池管理器可以对Pod缓存池进行管理。由于Pod缓存池中的Pod可以提前启动部分逻辑，使其处于待机状态，所以Pod缓存池也可以称为“待机Pod缓存池”。

用户创建函数Fn-1、Fn-2、……、Fn-n后，会相应创建对应的第二工作负载。

弹性决策器可以针对每个函数决定分别需要为其分配多少个Pod，由此实现弹性能力。例如如图7所示，为Fn-1分配3个Pod，为Fn-2分配1个Pod，为Fn-n分配2个Pod。

缓存池操作器可以基于弹性决策器的决策结果，对Pod缓存池中缓存的Pod进行调度，以满足弹性决策器决策的要求。通过动态Pod选取通道，将所选取的Pod从Pod缓存池迁移到函数各自对应的第二工作负载中。缓存池操作器还可以对各个第二工作负载进行相应的调和(reconcile)。

运行时管理器可以侦听待机Pod缓存池中个Pod当前的状态，并在上述两个阶段合适的时机，从代码缓存系统提取相应函数对应的代码，以分阶段启动Pod中容器的运行时。

Pod监测控制器可以从弹性决策器获取各函数对应的Pod有关指标，并从相应函数对应的第二工作负载收集相应指标，对Pod进行监测和控制。

缓存池管理器例如可以包括面向终态设计的搬运工作负载控制器(CarrierController)。

搬运工作负载控制器可以实现两项功能：Pod调度扩容和Pod运维移动。

首先，描述Pod调度扩容。

当接收到函数或应用的扩容请求之后，搬运工作负载控制器会获取请求扩容的函数或应用对应的工作负载(第二工作负载)的真实Pod数量和状态。例如可以通过比对搬运工作负载的资源规格(Spec)和该函数或应用对应的第二工作负载所需Pod的真实数量，来确定是否需要扩容。如果是需要扩容的情况，搬运工作负载控制器可以根据一定的调度策略，在待机Pod缓存池中选出指定数量的Pod，以完成扩容请求。

当然，这里也可以先判断Pod缓存池中是否有足够的Pod实例以满足扩容要求。在Pod缓存池中的Pod数量小于扩容所需要的Pod数量的情况下，搬运工作负载控制器可以优先从Pod缓存池中获取目前可用数量的Pod。剩下无法从Pod缓存池中获取到的部分Pod可以通过冷启动的方式来获取，以满足扩容需求。

搬运工作负载控制器从Pod缓存池中选出可用的Pod之后，可以将其与具体的函数或应用对应的第二工作负载进行绑定。

当Pod与具体的函数或应用对应的第二工作负载绑定成功之后，这些Pod虽然还在缓存池中，但是已经属于具体的函数或应用对应的第二工作负载。

运行时管理器中可以包含搬运工作负载代理(Carrier Agent)。在绑定成功之后，搬运工作负载代理可以接管从缓存池中选出的这些具体的Pod，从而完成Pod与函数或应用对应的具体容器运行时的绑定。当搬运工作负载代理完成运行时的绑定，并确认运行时启动完成，且能够正常接受请求之后，整个扩容请求完成。

总体来说，这个过程中完成两件事：Pod和工作负载之间的绑定；以及Pod和函数或应用对应的运行时的绑定。

接下来，描述Pod运维移动。

在将Pod缓存池中的Pod和具体的函数或应用对应的第二工作负载绑定之后，Pod和具体函数或应用对应的第二工作负载便保持一种属主(owner)关系，即该Pod属于该第二工作负载。

至此，虽然从服务的角度已经完成了扩容，但是从运维的角度，这些与函数或应用对应的第二工作负载绑定的Pod还没有从属于函数或应用对应的第二工作负载所在的应用分组。

为了解决Pod缓存池中属于不同函数或应用对应的第二工作负载的Pod运维问题，实现属于不同函数或应用对应的第二工作负载的Pod之间的隔离，可以引入Pod的移动逻辑。即，在Pod与函数或应用对应的第二工作负载确定属主关系之后，从运维角度使绑定后的Pod彻底脱离当前待机Pod缓存池。

换言之，通过将Pod与第二工作负载绑定，两者之间的属主关系已建立好了。在一些情况下，Pod中的运行时甚至可能已经可以开始运行了。然而，考虑到运维和租户隔离等方面的要求，需要将这个Pod移动到指定的函数或应用对应的第二工作负载中。

这样，当Pod缓存池中的Pod与具体的函数或应用对应的第二工作负载发生绑定之后，Pod将被移动到其所属函数或应用自己对应的第二工作负载中，注册到函数或应用自己的应用分组，从而实现运维层面的隔离。

应当理解的是，Pod移动并不需要等到Pod与运行时绑定之后再进行。当Pod和具体函数或应用对应的第二工作负载绑定之后，就可以开始Pod移动。这样Pod移动过程和Pod与容器运行时的绑定过程可以完全并行化，从而更进一步做到让Pod在服务层面(绑定)和运维层面(移动)同时达到可用。

此外，本方案中的搬运工作负载并不依赖于后端待机Pod缓存池。可以按照插件式思路进行设计，使得待机Pod缓存池可以随时进行热插拔。

待机Pod缓存池作为一种资源，在扩容过程中，可以根据当前函数或应用对应的第二工作负载信息进行查询。如果有可用的后端Pod缓存池资源，那么从该可用的后端缓存池中进行扩容。如果没有可用的后端缓存池资源，则可以采用后备方案(fallback)，例如采用常规冷启动方案来进行Pod扩容。

图8示意性地示出了容器运行时的分阶段启动方案。

运行时管理器侦听Pod缓存池中的Pod，并从代码缓存系统提取运行时代码，以分阶段为Pod准备容器运行时。

当函数Fn-1和Fn-n分别从Pod缓存池中选取一个Pod后，对所选取的Pod进行原地(inplace)更新，首先为Pod分别添加从代码缓存系统提取的代码，然后启动运行时。当运行时就绪后，移动到Fn-1和Fn-n对应的工作负载的Pod便可以正常运行相应的函数，实现相应的功能。

本公开提供了一种可以适用于多租户隔离的池化缓存实现方案。其中，将缓存的Pod资源和真正运行函数或应用的Pod隔离开，从而让这两种Pod归属于不同的工作负载。

这样，从池子中分配给函数或应用的Pod会脱离K8s后端池子工作负载的管理。

另一方面，本公开提供了一种通用的池化后端工作负载(第一工作负载)，利用后端工作负载资源配额VPA(Pod的垂直自动伸缩)能力，无需Pod重建，就能够实现多级资源的池化分配。

这样在节省池化资源的同时，还能够提升池子Pod应对不同资源规格的请求，提升池子的资源利用率和缓存命中率。

在原有的Kubernetes Pod生产流程中，其Pod创建流程需要经过多个阶段：调度、Pod生产、容器镜像下载、容器数据卷(Volume)挂载、容器启动等阶段。整个Pod生产过程中，受基础设施调度策略和资源状态的影响较大，导致Pod创建的时间较长。

通过本公开的Pod池化方案，通过Pod容器内运行时改造能够提前创建Pod，启动Pod中的容器。当需要创建Pod的时候，直接使用池子中已创建好的Pod，能够快速实现服务，节省了Pod创建所需要的时间。

本公开利用自定义池化工作负载实现，在实现Pod缓存的基础上，在所缓存的Pod被归属到不同的函数或应用之后，能够将该Pod从原来的缓存池子工作负载中移动到函数或应用自己的工作负载中进行管理。

另外，本公开还在池子缓存层面做了优化，能够提供多级资源规格的缓存池子。不同资源规格的Pod能够通过VPA的方式移动到匹配的池子中，以实现后端池子的资源最大化利用。

通过采用本公开的Pod池化缓存方案，池化缓存的Pod在与具体函数或应用绑定之后，将被挪动到函数或应用自己的工作负载中进行管理，从而与原来负责创建Pod的池子工作负载脱离关系。

由此，将池子中所缓存的Pod资源和真正运行函数或应用的Pod隔离开，使池子中缓存的Pod和真正参与函数或应用逻辑的Pod归属于不同的工作负载。

该方案可以适用于多租户场景。即，多个租户可以共享第一工作负载维护的Pod缓存池子，并分别创建各自的第二工作负载。一旦租户需要资源，可以将从Pod缓存池子中分配的Pod归属到租户各自的工作负载中，相互不受影响。

由此，既可以保持租户间Pod之间的隔离，也可以大大提升后端共享池子的运维灵活性。

另一方面，这种多租户架构能够最大程度利用租户之间弹性差异，实现最大程度的弹性资源高效利用。

而且，这种隔离性在真实的产品层面非常重要。

另外，本公开还进一步提出了一种Pod生命周期管理方案。

在Pod扩容的过程中，期望扩容所需时间在毫秒量级。

然而，现有K8s生命周期管理方案是基于就绪(Readiness)和活性(Liveness)的。就绪是一种同步探测机制，需要贯穿整个Pod生命周期，所以在参数设置方面，探测的时间间隔不可能设置地特别小，一般都是5s至10s的粒度。这样，现有K8s生命周期管理方案不适于毫秒级粒度的状态变化，也就不能支持毫秒量级的扩容需求。

本公开提出的Pod生命周期管理方案不依赖于Pod的就绪，而是使用了自己维护的状态，从而可以实现毫秒级的Pod扩容。

本公开提出的Pod生命周期管理方案从第二工作负载的视角，管理从Pod缓存池中选择Pod，启动容器运行时，并移动到第二工作负载的Pod调用生命周期中，Pod的状态。

图9示意性地示出了根据本公开的容器组部署方法所采用的Pod生命周期管理方案。

如图9所示，本公开的Pod生命周期管理方案可以维护4种状态：绑定成功、启动成功、失败、删除。

首先，描述绑定成功状态。

根据本公开的容器组部署方案，函数或应用对应的第二工作负载不需要从头开始创建Pod，而是从第一工作负载维护的Pod缓存池中选择并调用已经创建并缓存的Pod。如前所述，Pod还在Pod缓存池中时，就可以已经启动容器运行时与函数或应用无关的第一部分(第一阶段)。

这样，当为函数或应用从Pod缓存池中选取了Pod，并将其绑定到函数或应用对应的第二工作负载后，Pod进入绑定成功状态。所谓“绑定”，即在Pod和函数或应用之间建立绑定关系，是指设定Pod对应于或归属于特定的函数或应用，或者Pod被分配或调度给特定的函数或应用。

绑定成功状态表示已经从Pod缓存池中选取到期望的Pod，并且已被绑定到第二工作负载。搬运工作负载代理也是在侦听到这个状态后，才根据绑定的信息开始启动对应Pod中容器运行时与函数或应用相关的第二部分(第二阶段)。

换言之，绑定成功状态表示该Pod虽然尚在Pod缓存池里，但是已经绑定到请求扩容的函数或应用，只是还没有移动到第二工作负载中。也即，该Pod在缓存池里已经调度成功了，从而已经为这个特定函数或应用准备了Pod。换言之，从Pod缓存池中选择了一个Pod分配给该函数或应用并绑定了。

绑定成功状态是从函数或应用的角度，表示已经为该函数或应用“创建”了一个Pod。这里，这个Pod实际上是已经创建好并缓存在Pod缓存池中的，在此，为该函数或应用调度选定了一个Pod。从这个函数或应用的角度看，就像是为其“创建”了一个Pod一样。

移动Pod之前，需要知道往哪里移动。因此，Pod只有在处于绑定成功状态的前提下才能开始移动。

更进一步讲，绑定成功状态表示，在Pod缓存池中找到了一个Pod资源，其可以分配给请求扩容的函数或应用对应的第二工作负载。而对于函数或应用对应的第二工作负载来说，逻辑上就是瞬间为其“创建”了一个Pod。

可以理解的是，根据本公开的Pod缓存部署方案，在第一工作负载提前维护了Pod缓存池的情况下，对于第二工作负载而言，“创建”Pod就是绑定Pod。原本繁杂并耗时的Pod创建工作可以瞬间完成。后续的操作就是容器运行时启动和Pod移动了。

另一方面，在Pod被绑定到函数或应用的同时，就可以开始移动了。绑定和移动可以是个并行异步的过程。这里，绑定成功状态可以理解为一个事件，事件发生之后就开始移动。即，这里可以采用事件驱动机制，“绑定成功”事件驱动进行移动操作。

接下来，描述启动成功状态。

在绑定成功的基础上，当容器运行时启动成功进入就绪状态后，Pod进入启动成功状态。

Pod进入启动成功状态之后，函数或应用可以正常调用该Pod来实现相应的功能。

由于如前所述，Pod还在缓存池中时，就已经提前启动了容器运行时与函数或应用无关的第一部分，这样，在绑定成功之后，只需要启动容器运行时与函数或应用相关的第二部分。由此，进一步缩减了绑定成功后进入启动成功状态的时间。

接下来，描述失败状态。

当绑定成功状态的Pod的容器运行时启动失败，或者容器运行时启动超时，Pod会进入失败状态。对于因容器运行时启动失败/超时而进入失败状态的Pod，可以返回绑定成功状态尝试重新启动容器运行时。

另一方面，当处于启动成功状态的Pod的容器运行时出错时，Pod也会进入失败状态。在容器运行时排除故障并恢复就绪状态后，可以恢复到启动成功状态。

接下来，描述删除状态。

在成功绑定到第二工作负载(绑定成功状态)的Pod多次启动容器运行时都没有成功，例如超出设定的启动失败/启动超时次数上限的情况下，或者因容器运行时出错而进入失败状态的Pod未能排除故障的情况下，可以将该Pod标记为删除状态，以删除该Pod进行重建。

在删除Pod的情况下，可以冷启动新的Pod实例，并使冷启动的新Pod实例进入绑定成功状态。

这里的“删除”表示该Pod要被删除的状态。而具体的删除操作可以由例如搬运工作负载代理在侦测到删除状态后来执行。此时，可以先在搬运工作负载中删除该Pod，然后再在第二工作负载和/或Pod缓存池中删除该Pod。

这里，可以不但从函数或应用对应的第二工作负载中删除该Pod，而且还可以从Pod缓存池中删除该pod。换言之，可以将该Pod彻底销毁了。

Pod销毁之后，对于函数或应用的扩容请求，可以有两个可选处理模式：一种模式例如可以称为“Fallback_To_Cold_Boot(退回冷启动)”，函数或应用的第二工作负载通过冷启动，给自己补充一个Pod；另一种模式例如可以称为“Always_From_CachePool(总是从缓存池获取)”，函数或应用的第二工作负载继续从Pod缓存池里寻找已缓存的可用Pod。

这里，这些状态的变化过程与Pod移动是两个并行的过程。如前所述，Pod移动的前提是Pod被标记为绑定成功状态(即确定了该Pod属于哪个函数或应用)。另外，针对一些特殊函数或应用，也可以设置为只有进入启动成功状态(容器运行时与函数或应用相关的第二部分启动成功)后才能移动Pod。

这样，可以在Pod从处于缓存状态到被移入函数或应用对应的第二工作负载的整个过程中维护该生命周期。

例如，从Pod缓存池中获取到一个Pod后，不需要等到Pod彻底移动到第二工作负载，就可以先判断确定这个Pod是否可用。Pod可用是指Pod绑定成功且容器运行时与函数或应用相关的第二部分启动成功。换言之，本公开可以将是否可用的判断和Pod移动分成两个独立的逻辑来完成。

通常情况下，可以先确定是否可用，再完成Pod移动。

图10示出了根据本发明一实施例可用于实现上述容器组部署方法的计算设备的结构示意图。

参见图10，计算设备1000包括存储器1010和处理器1020。

处理器1020可以是一个多核的处理器，也可以包含多个处理器。在一些实施例中，处理器1020可以包含一个通用的主处理器以及一个或多个特殊的协处理器，例如图形处理器(GPU)、数字信号处理器(DSP)等等。在一些实施例中，处理器1020可以使用定制的电路实现，例如特定用途集成电路(ASIC，Application Specific Integrated Circuit)或者现场可编程逻辑门阵列(FPGA，Field Programmable Gate Arrays)。

存储器1010可以包括各种类型的存储单元，例如系统内存、只读存储器(ROM)，和永久存储装置。其中，ROM可以存储处理器1020或者计算机的其他模块需要的静态数据或者指令。永久存储装置可以是可读写的存储装置。永久存储装置可以是即使计算机断电后也不会失去存储的指令和数据的非易失性存储设备。在一些实施方式中，永久性存储装置采用大容量存储装置(例如磁或光盘、闪存)作为永久存储装置。另外一些实施方式中，永久性存储装置可以是可移除的存储设备(例如软盘、光驱)。系统内存可以是可读写存储设备或者易失性可读写存储设备，例如动态随机访问内存。系统内存可以存储一些或者所有处理器在运行时需要的指令和数据。此外，存储器1010可以包括任意计算机可读存储媒介的组合，包括各种类型的半导体存储芯片(DRAM，SRAM，SDRAM，闪存，可编程只读存储器)，磁盘和/或光盘也可以采用。在一些实施方式中，存储器1010可以包括可读和/或写的可移除的存储设备，例如激光唱片(CD)、只读数字多功能光盘(例如DVD-ROM，双层DVD-ROM)、只读蓝光光盘、超密度光盘、闪存卡(例如SD卡、min SD卡、Micro-SD卡等等)、磁性软盘等等。计算机可读存储媒介不包含载波和通过无线或有线传输的瞬间电子信号。

存储器1010上存储有可执行代码，当可执行代码被处理器1020处理时，可以使处理器1020执行上文述及的容器组部署方法。

上文中已经参考附图详细描述了根据本发明的容器组部署方案。

此外，根据本发明的方法还可以实现为一种计算机程序或计算机程序产品，该计算机程序或计算机程序产品包括用于执行本发明的上述方法中限定的上述各步骤的计算机程序代码指令。

或者，本发明还可以实施为一种非暂时性机器可读存储介质(或计算机可读存储介质、或机器可读存储介质)，其上存储有可执行代码(或计算机程序、或计算机指令代码)，当所述可执行代码(或计算机程序、或计算机指令代码)被电子设备(或计算设备、服务器等)的处理器执行时，使所述处理器执行根据本发明的上述方法的各个步骤。

本领域技术人员还将明白的是，结合这里的公开所描述的各种示例性逻辑块、模块、电路和算法步骤可以被实现为电子硬件、计算机软件或两者的组合。

附图中的流程图和框图显示了根据本发明的多个实施例的系统和方法的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标记的功能也可以以不同于附图中所标记的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

以上已经描述了本发明的各实施例，上述说明是示例性的，并非穷尽性的，并且也不限于所披露的各实施例。在不偏离所说明的各实施例的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。本文中所用术语的选择，旨在最好地解释各实施例的原理、实际应用或对市场中的技术的改进，或者使本技术领域的其它普通技术人员能理解本文披露的各实施例。

Claims (14)

1.一种容器组部署方法，包括：

第一工作负载维护容器组缓存池，所述容器组缓存池中缓存至少一个容器组；以及

响应于创建第二工作负载或第二工作负载的扩容请求，从所述容器组缓存池中选取容器组，将所获取的容器组绑定到第二工作负载，并移动到第二工作负载中。

2.根据权利要求1所述的方法，其中，

第一工作负载维护多个容器组缓存池，每个容器组缓存池中缓存的容器组具有相同的资源配置规格，不同容器组缓存池中缓存的容器组具有不同的资源配置规格，

从所述容器组缓存池中选取容器组的步骤包括：根据第二工作负载对容器组资源配置规格的需求，从与所述第二工作负载匹配的容器组缓存池中选取容器组。

3.根据权利要求2所述的方法，其中，

在一个容器组缓存池中的容器组消耗速度较快的情况下，从其它容器组缓存池中调配容器组以补充所述一个容器组缓存池。

4.根据权利要求1所述的方法，其中，

第一工作负载是针对使用相同镜像的函数或应用构造的通用工作负载；并且/或者

第二工作负载是响应于函数或应用的创建而创建的对应于所述函数或应用的工作负载，所述函数或应用使用所述相同镜像。

5.根据权利要求4所述的方法，还包括：

当容器组在容器组缓存池中时，在所述容器组中提前启动容器运行时与函数或应用无关的第一部分；以及/或者

响应于容器组被绑定到第二工作负载，在所述容器组中启动容器运行时与第二工作负载所对应的函数或应用相关的第二部分；以及/或者

在容器组缓存池中的容器组提前启动容器运行时与函数或应用无关的第一部分之后，使所述容器组中的容器处于待机状态，以等待所述容器组被绑定到第二工作负载从而启动容器运行时与第二工作负载所对应的函数或应用相关的第二部分。

6.根据权利要求5所述的方法，其中，

所述第一部分包括下述至少一项：容器启动、容器运行时框架初始化部分；并且/或者

所述第二部分包括下述至少一项：环境变量的动态注入、函数或应用的信息或代码加载。

7.根据权利要求5所述的方法，还包括：

在容器组缓存池中的容器组提前启动容器运行时的所述第一部分之后，对所述容器组中的容器的活性状态和就绪状态进行控制：

使得容器满足活性状态要求，而不满足就绪状态要求；或者

使得容器既满足活性状态要求，也满足就绪状态要求。

8.根据权利要求1所述的方法，还包括：

响应于容器组被绑定到第二工作负载，对所述容器组进行下述至少一项修改：

更新所述容器组的标签，使得第二工作负载对应的容器组选择器能够检索到该容器组；以及

将所述容器组的属主信息修改为所述第二工作负载。

9.根据权利要求1所述的方法，还包括：

在将所获取的容器组绑定到第二工作负载之后，维护容器组的状态，所述状态包括：绑定成功、启动成功、失败、删除，其中，

绑定成功状态表示已从容器组缓存池中选取出该容器组并被绑定到第二工作负载；

启动成功状态表示绑定成功的容器组的容器运行时已启动成功进入就绪状态；

失败状态表示绑定成功的容器组的容器运行时启动失败或启动超时，或者启动成功的容器组的容器运行时出错，其中，对于因容器运行时启动失败或启动超时而进入失败状态的容器组，返回绑定成功状态以重新尝试启动容器运行时，对于因容器运行时出错而进入失败状态的容器组，在容器运行时排除故障并恢复就绪状态后，恢复到启动成功状态；

删除状态表示容器组要被删除，在绑定成功的容器组的容器运行时多次启动未成功，或者失败状态的容器组的容器运行时未能排除故障的情况下，容器组进入删除状态。

10.一种容器组部署装置，包括：

缓存装置，用于使用第一工作负载维护容器组缓存池，所述容器组缓存池中缓存至少一个容器组；以及

迁移装置，用于响应于创建第二工作负载或第二工作负载的扩容请求，从所述容器组缓存池中选取容器组，将所获取的容器组绑定到第二工作负载，并移动到第二工作负载中。

11.根据权利要求10所述的装置，还包括：

第一启动装置，用于当容器组在容器组缓存池中时，在所述容器组中提前启动容器运行时与函数或应用无关的第一部分；以及/或者

第二启动装置，用于响应于容器组被移动到第二工作负载，在所述容器组中启动容器运行时与第二工作负载所对应的函数或应用相关的第二部分；以及/或者

待机装置，用于在容器组缓存池中的容器组提前启动容器运行时与函数或应用无关的第一部分之后，使所述容器组中的容器处于待机状态，以等待所述容器组被绑定到第二工作负载从而启动容器运行时与第二工作负载所对应的函数或应用相关的第二部分，

其中，第一工作负载是针对使用相同镜像的函数或应用构造的通用工作负载，第二工作负载是响应于函数或应用的创建而创建的对应于所述函数或应用的工作负载，所述函数或应用使用所述相同镜像。

12.一种计算设备，包括：

处理器；以及

存储器，其上存储有可执行代码，当所述可执行代码被所述处理器执行时，使所述处理器执行如权利要求1至9中任何一项所述的方法。

13.一种计算机程序产品，包括可执行代码，当所述可执行代码被电子设备的处理器执行时，使所述处理器执行如权利要求1至9中任何一项所述的方法。

14.一种非暂时性机器可读存储介质，其上存储有可执行代码，当所述可执行代码被电子设备的处理器执行时，使所述处理器执行如权利要求1至9中任何一项所述的方法。

Images