基于容器组pod的处理方法及相关系统、存储介质与流程

1.本技术涉及云计算技术领域，尤其涉及一种基于容器组pod的处理方法及相关系统、存储介质。


背景技术：

2.函数即服务(function as a service，faas)，是一种以事件驱动并实现了无服务器计算方法的计算执行模型。其具有完全自动的、有弹性的、且由服务提供者所管理的横向扩展能力，能帮助开发者降低运营成本和开发成本。开发者只需要编写简单的事件处理函数来构建自己的服务，并将此外的事情全交由平台处理，faas用户完全不用考虑缩放，如何提升缩放的敏捷性成为faas平台最大的技术挑战之一。
3.观察业界对faas架构的实践，其中基于容器集群管理系统kubernetes平台的实践，通常利用pod中的容器作为函数执行环境，而pod启动时间通常在3秒以上，因此严重影响了faas的敏捷性。
4.目前，通过创建通用pod池，该通用pod池中存放有预启动的通用pod，在接收到函数请求时，pod池管理微服务从池中获取1个pod并进行业务化流程，进而执行函数。执行完函数后则删除该pod。pod池管理微服务通过在池中补充新的通用pod，以此来降低函数冷启动时延。然而，当函数并发启动，池中预启动pod迅速用完，之后的函数仍需经过pod冷启动流程，因此，函数冷启动时延问题并没有较好的解决。


技术实现要素：

5.本技术公开了一种基于容器组pod的处理方法及相关系统、存储介质，可以有效降低pod冷启动的时延。
6.第一方面，本技术实施例提供一种基于容器组pod的处理方法，包括：第一微服务接收来自第二微服务的获取pod的请求，所述请求携带第一函数的函数元数据；所述第一微服务根据所述第一函数的函数元数据从所述第一微服务管理的pod中获取目标pod的描述信息，所述目标pod的描述信息与所述第一函数的函数元数据匹配，且所述目标pod是曾经运行过函数的pod；所述第一微服务向所述第二微服务返回所述目标pod的描述信息，以响应所述请求。
7.所述第一微服务管理的pod，可以理解为，所述第一微服务具有获取pod的描述信息的权限，以及所述第一微服务可以对pod进行清理、或者调用接口来删除pod等。
8.本技术实施例，第一微服务通过根据第一函数的函数元数据从第一微服务管理的pod中获取与该第一函数的函数元数据匹配的目标pod的描述信息，且该目标pod是曾经运行过函数的pod。采用该手段，通过从曾经运行过函数的pod中得到目标pod，相较于现有技术中对运行过函数的pod直接删除，采用本方案，节省了重新生成pod的时间，有效减少了pod的冷启动时延。
9.另一方面，本方案可以降低函数并发启动时延的同时，还可以控制对系统资源的
总占用量。本方案基于已有的资源管理平台实现通用技术，避免额外的开发维护成本。
10.上述目标pod的描述信息，是指pod资源规格，所属管理者等pod的静态或动态信息，例如为目标pod的cpu大小、内存大小等信息，还可以包括其他信息，本方案对此不做具体限定。
11.上述第一函数的函数元数据，是指描述函数属性，函数运行资源规格等信息的数据，例如为第一函数要求的cpu大小、内存大小等。
12.上述目标pod的描述信息与所述第一函数的函数元数据匹配，可以理解为：目标pod的cpu大小与第一函数要求的cpu大小匹配，目标pod的内存大小与第一函数要求的内存大小匹配。
13.该匹配可以理解为：目标pod的cpu大小不小于所述第一函数要求的cpu大小，目标pod的内存大小不小于所述第一函数要求的内存大小等。
14.作为一种可选的实现方式，所述目标pod为所述第一微服务对所述曾经运行过函数的pod中的函数残留临时文件和内存中的残留数据进行清理得到的。
15.通过对曾经运行过函数的pod中的函数残留临时文件和内存中的残留数据进行清理，以便回收利用该pod，进而在下次启动pod时不需要重新生成新的pod，不需要进行冷启动的流程，有效减少了冷启动的时延。
16.作为一种可选的实现方式，所述方法还包括：所述第一微服务根据所述曾经运行过函数的pod的描述信息，所述第一微服务的状态以及系统总资源占用量中的至少一项，对所述曾经运行过函数的pod进行清理或删除。
17.本方案仅以根据上述信息为例来对所述曾经运行过函数的pod进行清理或删除，其还可以是基于其他信息来对所述曾经运行过函数的pod进行清理或删除，本方案对此不做具体限定。
18.上述根据曾经运行过函数的pod的描述信息，可以基于该pod的类别来确定是否进行清理。具体地，可以是根据该pod的cpu阈值、内存阈值、函数所属用户信息(租户信息)等，当然还可以包括其他信息，本方案对此不做具体限定。
19.上述第一微服务的状态指示所述第一微服务管理的pod的数量、种类以及所述第一微服务管理的pod所占用的总资源中的至少一项。
20.所述系统总资源占用量指示函数运行系统占用的cpu大小、内存大小中的至少一项，其中，所述函数运行系统包括所述第一微服务和所述第二微服务。
21.该函数运行系统还可以包括其他微服务等，本方案对此不做具体限定。
22.例如，该函数运行系统可以是实现无服务器计算的faas系统，其可以是基于kubernetes平台的faas，还可以是基于其他平台的faas。当然，该函数运行系统还可以是其他实现无服务器计算的系统，本方案对此不做具体限定。
23.本方案中所述的占用量等，可以是实际的占用量，也可以是相对的占用量，比如按照百分比来表示等，本方案对此不做具体限定。
24.作为一种可选的实现方式，若不对所述曾经运行过函数的pod进行清理处理，则调用第一接口以删除所述曾经运行过函数的pod。该第一接口可以是kubernetes接口等。
25.作为一种可选的实现方式，当系统总资源占用量小于第一预设值，且所述第一微服务中进行清理得到的pod的数量不大于第二预设值时，所述第一微服务对所述曾经运行
过函数的pod中的函数残留临时文件和内存中的残留数据进行清理。
26.作为一种可选的实现方式，当所述系统总资源占用量大于第一预设值，或所述第一微服务中进行清理得到的pod的数量大于第二预设值时，所述第一微服务调用第一接口以删除所述曾经运行过函数的pod。
27.作为一种可选的实现方式，当达到所述目标pod的存活时长时，所述第一微服务调用第一接口以删除所述目标pod，所述目标pod的存活时长与所述曾经运行过函数的pod的描述信息，所述第一微服务的状态以及系统总资源占用量中的至少一项有关。
28.采用该手段，在达到pod的存活时长时删除该pod，进而防止因pod闲置产生的资源浪费。
29.作为一种可选的实现方式，所述目标pod中存储有所述第一函数的程序代码，以便所述目标pod运行所述第一函数，即执行所述第一函数的程序代码。
30.采用该手段，节省了程序代码即函数包下载的时间，进而节省了pod业务化处理的时间，有效提升了pod业务化的效率。
31.应理解，上述第一函数的程序代码，是指用于实现所述第一函数功能的代码，也就是说，可以用于实现所述第一函数的功能的代码，都可以认为是第一函数的程序代码，本技术对其包括的具体内容和具体实现方式不做限定。例如，可以是该第一函数的源代码，也可以是以接口形式指示该第一函数源代码等。
32.作为一种可选的实现方式，所述目标pod保持接入与第一pod的网络连接。
33.其中，该第一pod先前与所述曾经运行过函数的pod建立有网络连接。采用该手段，以便在需要与第一pod中的第三微服务进行通信时可以直接通信，而不需要重新建立网络连接流程，有效提升了业务处理效率。例如，该第三微服务可以是函数仓库微服务，通过与第一pod中的该函数仓库微服务进行通信，以便下载函数的程序代码等。
34.第二方面，本技术实施例提供一种pod处理装置，包括：接收模块，用于接收来自第二微服务的获取pod的请求，所述请求携带第一函数的函数元数据；获取模块，用于根据所述第一函数的函数元数据从所述装置管理的pod中获取目标pod的描述信息，所述目标pod的描述信息与所述第一函数的函数元数据匹配，且所述目标pod是曾经运行过函数的pod；发送模块，用于向所述第二微服务返回所述目标pod的描述信息，以响应所述请求。
35.本技术实施例，第一微服务通过根据第一函数的函数元数据从第一微服务管理的pod中获取与该第一函数的函数元数据匹配的目标pod的描述信息，且该目标pod是曾经运行过函数的pod。采用该手段，通过从曾经运行过函数的pod中得到目标pod，相较于现有技术中对运行过函数的pod直接删除，采用本方案，节省了重新生成pod的时间，有效减少了pod的冷启动时延。
36.另一方面，本方案可以降低函数并发启动时延的同时，还可以控制对系统资源的总占用量。本方案基于已有的资源管理平台实现通用技术，避免额外的开发维护成本。
37.上述目标pod的描述信息，是指pod资源规格，所属管理者等pod的静态或动态信息，例如为目标pod的cpu大小、内存大小等信息，还可以包括其他信息，本方案对此不做具体限定。
38.上述第一函数的函数元数据，是指描述函数属性，函数运行资源规格等信息的数据，例如为第一函数要求的cpu大小、内存大小等。
39.上述目标pod的描述信息与所述第一函数的函数元数据匹配，可以理解为：目标pod的cpu大小与第一函数要求的cpu大小匹配，目标pod的内存大小与第一函数要求的内存大小匹配。
40.该匹配可以理解为：目标pod的cpu大小不小于所述第一函数要求的cpu大小，目标pod的内存大小不小于所述第一函数要求的内存大小等。
41.作为一种可选的实现方式，所述目标pod为对所述曾经运行过函数的pod中的函数残留临时文件和内存中的残留数据进行清理得到的。
42.通过对曾经运行过函数的pod中的函数残留临时文件和内存中的残留数据进行清理，以便回收利用该pod，进而在下次启动pod时不需要重新生成新的pod，不需要进行冷启动的流程，有效减少了冷启动的时延。
43.作为一种可选的实现方式，所述装置还包括第一处理模块，用于：根据所述曾经运行过函数的pod的描述信息，所述装置的状态以及系统总资源占用量中的至少一项，对所述曾经运行过函数的pod进行清理或删除。
44.作为一种可选的实现方式，所述装置还包括清理模块，用于：当系统总资源占用量小于第一预设值，且所述装置中进行清理得到的pod的数量不大于第二预设值时，对所述曾经运行过函数的pod中的函数残留临时文件和内存中的残留数据进行清理。
45.作为一种可选的实现方式，当所述系统总资源占用量大于第一预设值，或所述装置中进行清理得到的pod的数量大于第二预设值时，调用第一接口以删除所述曾经运行过函数的pod。
46.作为一种可选的实现方式，所述装置还包括第二处理模块，用于：当达到所述目标pod的存活时长时，调用第一接口以删除所述目标pod，所述目标pod的存活时长与所述曾经运行过函数的pod的描述信息，所述装置的状态以及系统总资源占用量中的至少一项有关。
47.作为一种可选的实现方式，所述目标pod中存储有所述第一函数的程序代码，以便所述目标pod运行所述第一函数。
48.作为一种可选的实现方式，所述目标pod保持接入与第一pod的网络连接。
49.第三方面，本技术实施例提供一种基于容器组pod的处理方法，包括：第一微服务接收来自第二微服务的获取pod的请求，所述请求携带第一函数的函数元数据；所述第一微服务根据所述第一函数的函数元数据从所述第一微服务管理的pod中获取目标pod的描述信息，所述目标pod的描述信息与所述第一函数的函数元数据匹配，且所述目标pod是曾经运行过函数的pod；所述第一微服务向所述第二微服务返回所述目标pod的描述信息中的网络地址，以响应所述请求。
50.其中，该第一微服务可以包括第一方面中的第一微服务和第二微服务。
51.本技术实施例，第一微服务通过根据第一函数的函数元数据从第一微服务管理的pod中获取与该第一函数的函数元数据匹配的目标pod的描述信息，且该目标pod是曾经运行过函数的pod。采用该手段，通过从曾经运行过函数的pod中得到目标pod，相较于现有技术中对运行过函数的pod直接删除，采用本方案，节省了重新生成pod的时间，有效减少了pod的冷启动时延。
52.第四方面，本技术实施例提供一种基于容器组pod的处理装置，包括处理器和存储器；其中，所述存储器用于存储程序代码，所述处理器用于调用所述程序代码，以执行如第
一方面任一种可能的实施方式提供的方法和/或第三方面任一种可能的实施方式提供的方法。
53.第五方面，本技术提供了一种计算机存储介质，包括计算机指令，当所述计算机指令在电子设备上运行时，使得所述电子设备执行如第一方面任一种可能的实施方式提供的方法和/或第三方面任一种可能的实施方式提供的方法。
54.第六方面，本技术实施例提供一种计算机程序产品，当计算机程序产品在计算机上运行时，使得计算机执行如第一方面任一种可能的实施方式提供的方法和/或第三方面任一种可能的实施方式提供的方法。
55.可以理解地，上述提供的第二方面所述的装置、第四方面所述的装置、第五方面所述的计算机存储介质或者第六方面所述的计算机程序产品均用于执行第一方面中任一所提供的方法和/或第三方面任一种可能的实施方式提供的方法。因此，其所能达到的有益效果可参考对应方法中的有益效果，此处不再赘述。
附图说明
56.下面对本技术实施例用到的附图进行介绍。
57.图1a是本技术实施例提供的一种pod的示意图；
58.图1b是本技术实施例提供的一种pod的示意图；
59.图2是本技术实施例提供的一种基于容器组pod的处理方法的流程示意图；
60.图3是本技术实施例提供的一种基于容器组pod的处理方法的示意图；
61.图4是本技术实施例提供的一种基于容器组pod的处理方法的示意图；
62.图5是本技术实施例提供的一种基于容器组pod的处理方法的示意图；
63.图6是本技术实施例提供的一种pod处理装置的结构示意图；
64.图7是本技术实施例提供的一种pod处理装置的结构示意图。
具体实施方式
65.下面结合本技术实施例中的附图对本技术实施例进行描述。本技术实施例的实施方式部分使用的术语仅用于对本技术的具体实施例进行解释，而非旨在限定本技术。
66.参照图1a所示，为本技术实施例提供的一种容器组pod的示意图。其中，容器集群管理系统kubernetes平台可以构建容器的部署服务。通常而言，容器container是一种操作系统级别的虚拟化技术，通过操作系统隔离技术，将不同的进程隔离开来。容器技术不同于硬件虚拟化技术，并没有虚拟硬件，容器内部也没有操作系统，只有进程。
67.pod是kubernetes平台的基本部署单位，一个pod由一组工作在同一节点的容器构成。其中，pod为封装了存储资源(volume)、独立网络ip、容器管理策略的容器组。
68.一个pod可以包括多个容器container，逻辑上标识某种应用的一个实例。如一个web应用由前端、后端和数据库三个组件构成，这三个组件运行在各自的容器中，针对这个实例可以对应一个包含三个container的pod。
69.参照图1b所示，pod中可包括：网络名称空间network namespace、挂载卷mounted volume、cpu声明cpu claims、内存声明memory claims、临时文件temporary files、内存中的数据data in memory和与系统服务的连接connection with system service等。
70.其中，网络名称空间network namespace，是实现网络虚拟化的重要功能，它能创建多个隔离的网络空间，它们有独自的网络栈信息。
71.挂载卷mounted volume，其中，卷是pod资源的属性。
72.与系统服务的连接connection with system service，例如与函数仓库微服务的连接等。
73.其中，pod中还可以包括其他的信息，本方案对此不做具体限定。
74.需要说明的是，本技术实施例中的pod的业务化处理specialize，可以理解为：将通用pod业务化为某个函数的执行环境，包含下载加载函数、注入函数环境变量等操作。例如，pod通过下载某函数包(函数代码/程序代码)，将该函数包加载到内存中，通过将函数环境变量注入到函数运行进程，进而业务化为该函数的执行环境。
75.pod的半业务化处理semi
‑
specialize，区别于上述业务化处理，其减少了部分流程。例如，pod无需下载函数包，直接复用存储的已下载的函数包，通过将本地函数包加载到内存中，通过将函数环境变量注入到函数运行进程，进而业务化为该函数的执行环境。
76.需要说明的是，上述业务化处理，还可以包括对pod设置标签等，本方案对此不做具体限定。
77.参照图2所示，是本技术实施例提供的一种基于容器组pod的处理方法的流程示意图。该方法包括步骤201
‑
203，具体如下：
78.201、第一微服务接收来自第二微服务的获取pod的请求，所述请求携带第一函数的函数元数据；
79.该第一微服务可以是指pod池管理微服务，其用于管理pod。
80.所述第一微服务管理的pod，可以理解为，所述第一微服务具有获取pod的描述信息的权限，以及所述第一微服务可以对pod进行清理、或者调用接口来删除pod等。其中，第一微服务可管理有若干个pod。
81.该第二微服务可以是函数实例管理微服务worker manager service，其用于管理函数实例的创建等。
82.上述第一函数可以是faas里面的任意函数等。
83.上述第一函数的函数元数据，是指描述函数属性，函数运行资源规格等信息的数据，例如为第一函数要求的cpu大小、内存大小等。
84.202、所述第一微服务根据所述第一函数的函数元数据从所述第一微服务管理的pod中获取目标pod的描述信息，所述目标pod的描述信息与所述第一函数的函数元数据匹配，且所述目标pod是曾经运行过函数的pod；
85.上述目标pod的描述信息例如为目标pod的cpu大小、内存大小等信息。
86.上述目标pod的描述信息与所述第一函数的函数元数据匹配，可以理解为：目标pod的cpu大小与第一函数要求的cpu大小匹配，目标pod的内存大小与第一函数要求的内存大小匹配。
87.该匹配可以理解为：目标pod的cpu大小不小于所述第一函数要求的cpu大小，目标pod的内存大小不小于所述第一函数要求的内存大小等。
88.上述仅为一种示例，其还可以是其他信息的匹配，本方案对此不做具体限定。
89.作为一种可选的实现方式，第一微服务中管理有通用的pod和回收的pod。
90.其中，通用的pod，可以理解为：未进行业务化处理的pod。
91.回收的pod，可以理解为：根据曾经运行过函数的pod进行清理得到的pod。
92.本方案的上述目标pod即为从回收的pod中获取的。
93.作为一种可选的实现方式，所述目标pod为所述第一微服务对所述曾经运行过函数的pod中的函数残留临时文件和内存中的残留数据进行清理得到的。
94.通过对曾经运行过函数的pod中的函数残留临时文件和内存中的残留数据进行清理，以便回收利用该pod，进而在下次启动pod时不需要重新生成新的pod，不需要进行冷启动的流程，有效减少了冷启动的时延。
95.具体地，第一微服务在pod运行完函数后，重启该已运行完函数的pod中的runtime容器，以便清理该pod的内存中的数据和残留文件等，其中，还包括清理挂载文件系统中的日志文件等函数残留临时文件。
96.上述仅为一种示例，当然还可以采用其他方式来对已运行完函数的pod进行处理，本方案对此不做具体限定。
97.例如，除了对所述已运行完函数的pod中的函数残留临时文件和内存中的残留数据进行清理外，还可以对所述已运行完函数的pod中的网络连接进行清理、对所述已运行完函数的pod中的存储的函数的程序代码进行清理等。采用该手段，可以节省资源。
98.作为一种可选的实现方式，所述第一微服务根据所述曾经运行过函数的pod的描述信息，所述第一微服务的状态以及系统总资源占用量中的至少一项，确定是否对所述曾经运行过函数的pod进行清理处理。
99.本方案的第一微服务可以决策复用或销毁pod，从而调控如回收的pod的总量，维持系统总资源占用量在预设值以下，避免资源浪费。
100.所述第一微服务的状态指示所述第一微服务管理的pod的数量、种类以及所述第一微服务管理的pod所占用的总资源中的至少一项，所述系统总资源占用量指示函数运行系统占用的cpu大小、内存大小中的至少一项，其中，所述函数运行系统包括所述第一微服务和所述第二微服务。
101.上述根据曾经运行过函数的pod的描述信息，可以基于该pod的类别来确定是否进行清理。具体地，可以是根据该pod的cpu阈值、内存阈值、函数所属用户信息(租户信息)等，当然还可以包括其他信息，本方案对此不做具体限定。
102.上述第一微服务的状态，可以是第一微服务包含不同类pod的数量，第一微服务中总资源占用量等信息。
103.上述系统总资源占用量信息，可以是指kubernetes的总资源占用量信息。
104.上述根据所述曾经运行过函数的pod的描述信息，所述第一微服务的状态以及系统总资源占用量中的至少一项，可以是根据其中的任意一项，也可以是其中的任意两项，还可以是根据该三项进行确定，本方案对此不做具体限定。
105.当然，还可以根据其他信息来确定等。如基于预先设定的策略等，当第一微服务中的pod数量达到预设值时，则不再进行回收处理。
106.其中，若不对所述曾经运行过函数的pod进行清理处理，则删除(释放)所述曾经运行过函数的pod。
107.例如，通过调用第一接口进而删除该pod。该第一接口可以是kubernetes接口等。
108.作为一种可选的实现方式，当所述系统总资源占用量大于第一预设值，或所述第一微服务中进行清理得到的pod的数量大于第二预设值时，所述第一微服务调用第一接口以删除所述曾经运行过函数的pod。
109.作为一种可选的实现方式，当达到所述目标pod的存活时长时，所述第一微服务调用第一接口以删除所述目标pod，所述目标pod的存活时长与所述曾经运行过函数的pod的描述信息，所述第一微服务的状态以及系统总资源占用量中的至少一项有关。
110.也就是说，根据上述至少一项信息得出目标pod的存活时长。当超过该存活时长，且该pod未被使用，则将该pod删除，防止因pod闲置产生的资源浪费。
111.该存活时长例如可以是300ms等。当然，其还可以是其他时长，本方案对此不做具体限定。
112.作为一种可选的实现方式，所述目标pod中存储有所述第一函数的程序代码，以便所述目标pod运行所述第一函数。
113.上述第一函数的程序代码，是指用于实现所述第一函数功能的代码，也就是说，可以用于实现所述第一函数的功能的代码，都可以认为是第一函数的程序代码，本技术对其包括的具体内容和具体实现方式不做限定。例如，可以是该第一函数的源代码，也可以是以接口形式指示该第一函数源代码等。
114.具体地，pod中的容器进程来执行第一函数的程序代码。
115.可以理解为：所述曾经运行过函数的pod中存储有已下载的所述第一函数的程序代码，在对该曾经运行过函数的pod进行处理时，未清理该已下载的所述第一函数的程序代码，使得处理后得到的目标pod中保留有该已下载的所述第一函数的程序代码。
116.通过在清理曾经运行过函数的pod时，保留其中已下载的函数的程序代码，使得处理后的pod在下次被使用时，节省了函数包的下载时间，减少了pod业务化处理的时间。采用该手段，在函数申请资源时，提供回收后的pod，利用该pod首次specialize过程生成的资源，只需进行semi
‑
specialize流程，减少pod业务化为函数执行环境的时间。
117.作为一种可选的实现方式，第一微服务通过从管理的pod中获取pod的描述信息与所述第一函数的函数元数据匹配的pod，并从中确定出保留有已下载的所述第一函数的程序代码的pod，以此确定出目标pod。
118.作为一种可选的实现方式，所述目标pod保持接入与第一pod的网络连接。
119.其中，该第一pod先前与所述曾经运行过函数的pod建立有网络连接。采用该手段，以便在需要与第一pod中的第三微服务进行通信时可以直接通信，而不需要重新建立网络连接流程，有效提升了业务处理效率。例如，该第三微服务可以是函数仓库微服务，通过与第一pod中的该函数仓库微服务进行通信，以便下载函数的程序代码。
120.上述仅为一种示例，其还可以保留有其他信息，本方案对此不做具体限定。
121.203、所述第一微服务向所述第二微服务返回所述目标pod的描述信息，以响应所述请求。
122.第一微服务在确定了目标pod后，进而返回目标pod的描述信息，以便第二微服务基于该描述信息管理目标pod，以便目标pod进行业务化处理等。
123.本技术实施例，第一微服务通过根据第一函数的函数元数据从第一微服务管理的pod中获取与该第一函数的函数元数据匹配的目标pod的描述信息，且该目标pod是曾经运
行过函数的pod。采用该手段，通过从曾经运行过函数的pod中得到目标pod，相较于现有技术中对运行过函数的pod直接删除，采用本方案，节省了重新生成pod的时间，有效减少了pod的冷启动时延。
124.另一方面，本方案可以降低函数并发启动时延的同时，还可以控制对系统资源的总占用量。本方案基于已有的资源管理平台实现通用技术，避免额外的开发维护成本。
125.参照图3所示，是本技术实施例提供的一种基于容器组pod的处理方法的示意图。如图3所示，当用户发送函数1的触发请求时，pod池管理微服务从原生资源池native pool中获取目标pod的描述信息，该pod通过下载函数1的函数包，基于函数环境变量进而业务化为函数1对应的执行环境。执行完函数1后，pod池管理微服务判断是否对该pod进行回收。若对该pod进行回收，则对该pod进行清理处理，默认为该回收处理后的该pod置于在延迟释放资源池lazy pool中。
126.当再次接收到函数1的触发请求时，由于有回收后的pod，因此从lazy pool中获取目标pod的描述信息。由于该pod中保留有函数1的函数包，因此不需要再次下载，只需进行半业务化处理，该pod基于函数环境变量进而业务化为函数1对应的执行环境。
127.执行完函数1后，pod池管理微服务判断是否对该pod进行回收。若不需要对该pod进行回收，则pod池管理微服务将该pod进行释放。
128.上述仅为一种示例，其中，当从lazy pool中获取的pod中未存储函数1的函数包时，则pod通过下载函数包，进而触发后续业务化处理。
129.参照图4所示，为本技术实施例提供的一种pod处理方法的流程示意图。该方法包括步骤401
‑
410，具体如下：
130.401、第二微服务向第一微服务发送获取pod的请求，所述请求携带第一函数的函数元数据；
131.该第二微服务可以是函数实例管理微服务worker manager service。
132.上述第一函数的函数元数据可以是第一函数需要的cpu大小、内存大小等。
133.上述第二微服务向第一微服务发送获取pod的请求，以便根据第一微服务提供的pod来执行所述第一函数。
134.上述第一微服务可以是pod池管理微服务。
135.402、所述第一微服务接收所述第二微服务发送的请求，并根据所述第一函数的函数元数据从管理的pod中获取第一pod的描述信息；
136.第一微服务管理有多个nativepod，以便在接收到请求后，从管理的pod中直接获取pod，节省了冷启动的时延。
137.第一微服务接收到所述第二微服务发送的请求后，获取第一pod的描述信息。其中，该第一pod的描述信息与该第一函数的函数元数据匹配。
138.上述第一pod的描述信息为该pod的cpu大小、内存大小等。
139.上述第一pod的描述信息与第一函数的函数元数据匹配，例如，第一pod的cpu大小、内存大小均大于第一函数需要的cpu大小、内存大小。
140.其中，当与第一函数的函数元数据匹配的pod有多个时，可以从中任意选择一个。
141.当然，也可以选择其中最优的pod，该最优的pod可以是该pod的cpu大小、内存大小等于第一函数需要的cpu大小、内存大小等。本方案对此不做具体限制。
142.403、所述第一微服务向所述第二微服务发送所述第一pod的描述信息；
143.404、所述第二微服务接收来自所述第一微服务的所述第一pod的描述信息，进而管理所述第一pod，以便所述pod进行业务化处理；
144.第一微服务中确定了第一pod后，将第一pod的描述信息返回给第二微服务。
145.第二微服务向该第一pod发送业务化specialize所需的信息，例如包括函数信息和函数环境变量。
146.该第一pod基于接收到的函数信息，进而下载第一函数的函数包，然后第一pod中的sidecar容器将第一函数的函数包和函数环境变量发送给runtime容器，其中，runtime容器即函数运行所在容器。runtime容器将第一函数的函数包加载到内存中，并加载函数环境变量，进而将第一pod业务化为第一函数的执行环境。
147.然后第二微服务修改该第一pod的描述信息，例如将其添加上第一函数的标签，以便于对该第一pod进行管理。
148.其中，所述第二微服务接收到所述第一pod的描述信息后，还包括：
149.所述第二微服务向第三微服务发送所述第一pod的网络地址。
150.该第三微服务可以是前端微服务frontend service。其中，该第三微服务基于用户发送的函数1的触发事件event请求，通过确定系统中不存在函数1的实例，则向第二微服务发送获取pod的请求，以便部署函数1的实例。其中，event事件为faas系统中函数的输入值，事件会触发函数开始执行。
151.第三微服务基于第二微服务返回的所述第一pod的网络地址，进而向该第一pod发送执行函数的请求。
152.第一pod接收到该执行函数的请求后，启动进程进行执行。执行完后，向第三微服务返回执行结果。进而第三微服务向用户返回执行结果。
153.405、函数执行完后，所述第一微服务确认是否对所述第一pod进行回收；
154.第一微服务可根据预设的控制策略确定是否回收。
155.该预设的控制策略例如可以是：当系统总资源占用小于80％，且与第一pod同类规格的回收pod数量少于5个，则回收当前pod。
156.当然，还可以是其他控制策略，或者基于其他信息确定是否回收，本方案对此不做具体限定。
157.406、若确认对所述第一pod进行回收，所述第一微服务对所述执行完函数的第一pod进行清理；
158.具体地，可对执行完函数的第一pod执行清理操作，包括：重启第一pod中的runtime容器，用以清理内存中的数据和残留文件；以及通过清理指定路径可以清除函数残留的临时文件，如清理挂载文件系统中的日志文件等。
159.进一步地，还包括设置该清理后的pod的存活时长。例如可以是300s，当超过300s，且该pod未被使用，则销毁该清理后的pod。
160.其中，若不对所述第一pod进行回收，所述第一微服务对所述执行完函数的第一pod进行释放。如，删除该第一pod。
161.407、所述第二微服务向所述第一微服务发送获取pod的请求，所述请求携带所述第一函数的函数元数据；
162.408、所述第一微服务接收所述第二微服务发送的请求，并根据所述第一函数的函数元数据从管理的pod中获取目标pod的描述信息，其中，所述目标pod的描述信息与所述第一函数的函数元数据匹配，且所述目标pod为曾经运行过函数的pod；
163.第一微服务接收到所述第二微服务发送的请求后，从管理的回收的pod中获取目标pod。
164.409、所述第一微服务向所述第二微服务返回所述目标pod的描述信息，以响应所述请求；
165.410、所述第二微服务接收来自所述第一微服务的所述目标pod的描述信息，并基于所述描述信息管理所述目标pod，以便所述目标pod进行半业务化处理；
166.第二微服务基于该描述信息向该目标pod发送半业务化semi
‑
specialize所需的信息，例如包括函数信息和函数环境变量。该目标pod中的sidecar容器将函数信息和函数环境变量发送给runtime容器，其中，runtime容器即函数运行所在容器。runtime容器将函数信息加载到内存中，并加载函数环境变量。
167.然后第二微服务修改该目标pod的描述信息，例如将其添加上第一函数的标签，以便于对该目标pod进行管理。
168.其中，所述第二微服务接收到所述目标pod的描述信息后，还包括：
169.所述第二微服务向第三微服务发送所述目标pod的网络地址。
170.第三微服务基于第二微服务返回的所述目标pod的网络地址，进而向该目标pod发送执行函数的请求。
171.所述目标pod接收到该执行函数的请求后，启动进程进行执行。执行完后，向第三微服务返回执行结果。进而第三微服务向用户返回执行结果。
172.函数执行完后，所述第一微服务确认是否对所述目标pod进行回收。
173.本技术实施例，第一微服务通过对曾经运行过函数的pod进行处理，然后在需要pod时根据第一函数的函数元数据从管理的pod中获取描述信息与该第一函数的函数元数据匹配的目标pod，其中，该目标pod中存储有所述第一函数的程序代码。采用该手段，从曾经运行过函数的pod中得到目标pod，节省了重新生成pod的时间，有效减少了pod的冷启动时延；且，目标pod的描述信息中保留有已下载的所述第一函数的程序代码，进一步节省了函数包下载的时间，有效提升了pod业务化处理的效率。
174.参照图5所示，为本技术实施例提供的一种pod处理方法的示意图。该方法包括步骤501
‑
508，具体如下：
175.501、前端微服务接收用户发送的第一函数的触发请求，该请求携带第一函数的函数元数据；
176.例如，用户想要触发某事件时，向前端微服务发送请求。
177.502、所述前端微服务向函数实例管理微服务发送获取pod的请求；
178.前端微服务查询系统中不存在第一函数的实例，向函数实例管理微服务请求部署一个第一函数的实例worker。
179.503、所述函数实例管理微服务根据所述请求向pod池管理微服务发送获取pod的请求；
180.504、所述pod池管理微服务确定目标pod，并向所述函数实例管理微服务返回该目
标pod的描述信息；
181.其中，pod池管理微服务从根据已执行完函数的pod处理得到的pod中确定出目标pod，该目标pod的描述信息与第一函数的函数元数据匹配。
182.505、所述函数实例管理微服务接收来自所述pod池管理微服务的所述目标pod的描述信息，管理所述目标pod，以便所述目标pod业务化为所述第一函数的执行环境；
183.其中，所述函数实例管理微服务还将所述目标pod的网络地址发送给所述前端微服务，以便所述前端微服务向所述目标pod发送执行第一函数的请求。
184.506、业务化后的pod接收到所述前端微服务发送的执行第一函数的请求后，启动进程以执行所述第一函数。
185.507、执行完函数后，该目标pod向所述前端微服务返回函数执行结果，所述前端微服务将结果返回给用户；
186.508、所述pod池管理微服务对所述目标pod进行处理。
187.该实施例中函数运行系统包括前端微服务、pod池管理微服务和函数实例管理微服务。
188.采用该手段，通过从曾经运行过函数的pod进行处理得到的pod中得到目标pod，节省了重新生成pod的时间，有效减少了pod的冷启动时延，且，目标pod的描述信息中保留有已下载的所述第一函数的程序代码，进一步节省了函数包下载的时间，有效减少了pod业务化处理的时间。
189.参照图6所示，为本技术实施例提供的一种pod处理装置。如图6所示，该装置包括：接收模块601、获取模块602和发送模块603，具体如下：
190.接收模块601，用于接收来自第二微服务的获取pod的请求，所述请求携带第一函数的函数元数据；
191.获取模块602，用于根据所述第一函数的函数元数据从所述装置管理的pod中获取目标pod的描述信息，所述目标pod的描述信息与所述第一函数的函数元数据匹配，且所述目标pod是曾经运行过函数的pod；
192.发送模块603，用于向所述第二微服务返回所述目标pod的描述信息，以响应所述请求。
193.上述目标pod的描述信息，是指pod资源规格，所属管理者等pod的静态或动态信息，例如为目标pod的cpu大小、内存大小等信息，还可以包括其他信息，本方案对此不做具体限定。
194.上述第一函数的函数元数据，是指描述函数属性，函数运行资源规格等信息的数据，例如为第一函数要求的cpu大小、内存大小等。
195.上述目标pod的描述信息与所述第一函数的函数元数据匹配，可以理解为：目标pod的cpu大小与第一函数要求的cpu大小匹配，目标pod的内存大小与第一函数要求的内存大小匹配。
196.该匹配可以理解为：目标pod的cpu大小不小于所述第一函数要求的cpu大小，目标pod的内存大小不小于所述第一函数要求的内存大小等。
197.作为一种可选的实现方式，所述目标pod为对所述曾经运行过函数的pod中的函数残留临时文件和内存中的残留数据进行清理得到的。
198.通过对曾经运行过函数的pod中的函数残留临时文件和内存中的残留数据进行清理，以便回收利用该pod，进而在下次启动pod时不需要重新生成新的pod，不需要进行冷启动的流程，有效减少了冷启动的时延。
199.作为一种可选的实现方式，所述装置还包括第一处理模块，用于：根据所述曾经运行过函数的pod的描述信息，所述装置的状态以及系统总资源占用量中的至少一项，对所述曾经运行过函数的pod进行清理或删除。
200.作为一种可选的实现方式，所述装置还包括清理模块，用于：当系统总资源占用量小于第一预设值，且所述装置中进行清理得到的pod的数量不大于第二预设值时，对所述曾经运行过函数的pod中的函数残留临时文件和内存中的残留数据进行清理。
201.作为一种可选的实现方式，当所述系统总资源占用量大于第一预设值，或所述装置中进行清理得到的pod的数量大于第二预设值时，调用第一接口以删除所述曾经运行过函数的pod。
202.作为一种可选的实现方式，所述装置还包括第二处理模块，用于：当达到所述目标pod的存活时长时，调用第一接口以删除所述目标pod，所述目标pod的存活时长与所述曾经运行过函数的pod的描述信息，所述装置的状态以及系统总资源占用量中的至少一项有关。
203.作为一种可选的实现方式，所述目标pod中存储有所述第一函数的程序代码，以便所述目标pod运行所述第一函数。
204.采用该手段，节省了函数包下载的时间，进而节省了pod业务化处理的时间，有效提升了pod业务化的效率。
205.作为一种可选的实现方式，所述目标pod保持接入与第一pod的网络连接。
206.其中，上述pod处理可参阅前述第一方面提供的任一种实现方式。
207.本技术实施例，第一微服务通过根据第一函数的函数元数据从第一微服务管理的pod中获取与该第一函数的函数元数据匹配的目标pod的描述信息，且该目标pod是曾经运行过函数的pod。采用该手段，通过从曾经运行过函数的pod中得到目标pod，相较于现有技术中对运行过函数的pod直接删除，采用本方案，节省了重新生成pod的时间，有效减少了pod的冷启动时延。
208.另一方面，本方案可以降低函数并发启动时延的同时，还可以控制对系统资源的总占用量。本方案基于已有的资源管理平台实现通用技术，避免额外的开发维护成本。
209.需要说明的是，上述图6所示的接收模块601、获取模块602和发送模块603用于执行上述pod的处理方法的相关步骤。
210.比如接收模块601用于执行步骤201的相关内容，获取模块602用于执行步骤202的相关内容，发送模块603用于执行步骤203的相关内容。
211.在本实施例中，该pod处理装置是以模块的形式来呈现。这里的“模块”可以指特定应用集成电路(application
‑
specific integrated circuit，asic)，执行一个或多个软件或固件程序的处理器和存储器，集成逻辑电路，和/或其他可以提供上述功能的器件。
212.此外，以上接收模块601、获取模块602和发送模块603可通过图7所示的pod处理装置的处理器702来实现。
213.图7是本技术实施例提供的pod处理装置的硬件结构示意图。图7所示的pod处理装置700(该装置700具体可以是一种计算机设备)包括存储器701、处理器702、通信接口703以
及总线704。其中，存储器701、处理器702、通信接口703通过总线704实现彼此之间的通信连接。
214.存储器701可以是只读存储器(read only memory，rom)，静态存储设备，动态存储设备或者随机存取存储器(random access memory，ram)。
215.存储器701可以存储程序，当存储器701中存储的程序被处理器702执行时，处理器702和通信接口703用于执行本技术实施例的pod处理方法的各个步骤。
216.处理器702可以采用通用的中央处理器(central processing unit，cpu)，微处理器，应用专用集成电路(application specific integrated circuit，asic)，图形处理器(graphics processing unit，gpu)或者一个或多个集成电路，用于执行相关程序，以实现本技术实施例的pod处理装置中的单元所需执行的功能，或者执行本技术方法实施例的pod处理方法。
217.处理器702还可以是一种集成电路芯片，具有信号的处理能力。在实现过程中，本技术的pod处理方法的各个步骤可以通过处理器702中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器702还可以是通用处理器、数字信号处理器(digital signal processing，dsp)、专用集成电路(asic)、现成可编程门阵列(field programmable gate array，fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本技术实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本技术实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器701，处理器702读取存储器701中的信息，结合其硬件完成本技术实施例的pod处理装置中包括的单元所需执行的功能，或者执行本技术方法实施例的基于容器组pod的处理方法。
218.通信接口703使用例如但不限于收发器一类的收发装置，来实现装置700与其他设备或通信网络之间的通信。例如，可以通过通信接口703获取数据。
219.总线704可包括在装置700各个部件(例如，存储器701、处理器702、通信接口703)之间传送信息的通路。
220.应注意，尽管图7所示的装置700仅仅示出了存储器、处理器、通信接口，但是在具体实现过程中，本领域的技术人员应当理解，装置700还包括实现正常运行所必须的其他器件。同时，根据具体需要，本领域的技术人员应当理解，装置700还可包括实现其他附加功能的硬件器件。此外，本领域的技术人员应当理解，装置700也可仅仅包括实现本技术实施例所必须的器件，而不必包括图7中所示的全部器件。
221.本技术实施例还提供了一种计算机可读存储介质，该计算机可读存储介质中存储有指令，当其在计算机或处理器上运行时，使得计算机或处理器执行上述任一个方法中的一个或多个步骤。
222.本技术实施例还提供了一种包含指令的计算机程序产品。当该计算机程序产品在计算机或处理器上运行时，使得计算机或处理器执行上述任一个方法中的一个或多个步骤。
223.所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、
装置和单元的具体工作过程，可以参考前述方法实施例中的对应步骤过程的具体描述，在此不再赘述。
224.应理解，在本技术的描述中，除非另有说明，“/”表示前后关联的对象是一种“或”的关系，例如，a/b可以表示a或b；其中a，b可以是单数或者复数。并且，在本技术的描述中，除非另有说明，“多个”是指两个或多于两个。“以下至少一项(个)”或其类似表达，是指的这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a，b，或c中的至少一项(个)，可以表示：a，b，c，a
‑
b，a
‑
c，b
‑
c，或a
‑
b
‑
c，其中a，b，c可以是单个，也可以是多个。另外，为了便于清楚描述本技术实施例的技术方案，在本技术的实施例中，采用了“第一”、“第二”等字样对功能和作用基本相同的相同项或相似项进行区分。本领域技术人员可以理解“第一”、“第二”等字样并不对数量和执行次序进行限定，并且“第一”、“第二”等字样也并不限定一定不同。同时，在本技术实施例中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本技术实施例中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念，便于理解。
225.在本技术所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，该单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。所显示或讨论的相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
226.作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
227.在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。该计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行该计算机程序指令时，全部或部分地产生按照本技术实施例的流程或功能。该计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。该计算机指令可以存储在计算机可读存储介质中，或者通过该计算机可读存储介质进行传输。该计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(digital subscriber line，dsl))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。该计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。该可用介质可以是只读存储器(read
‑
only memory，rom)，或随机存取存储器(random access memory，ram)，或磁性介质，例如，软盘、硬盘、磁带、磁碟、或光介质，例如，数字通用光盘(digital versatile disc，dvd)、或者半导体介质，例如，固态硬盘(solid state disk，ssd)等。
228.以上所述，仅为本技术实施例的具体实施方式，但本技术实施例的保护范围并不局限于此，任何在本技术实施例揭露的技术范围内的变化或替换，都应涵盖在本技术实施例的保护范围之内。因此，本技术实施例的保护范围应以所述权利要求的保护范围为准。