CN115373859B - 基于Kubernetes集群的模型服务容量调整方法及其装置 - Google Patents

Abstract

本公开是关于一种基于Kubernetes集群的模型服务容量调整方法及其装置。其中，Kubernetes集群上部署多个Pod副本，且在每个Pod副本中部署多个相同的服务进程，每个Pod副本中多个服务进程的个数大于或等于第一数值且小于或等于第二数值，该方法包括：响应于接收到资源容量调整信号，确定Pod副本的当前副本数和在每个Pod副本中部署的服务进程的当前进程数；根据Pod副本的当前副本数和在每个Pod副本中部署的服务进程的当前进程数，对模型服务进行图形处理器GPU资源容量调整。本公开实施例可以提高GPU资源的利用率，从而降低了服务运行的成本。

Description

基于Kubernetes集群的模型服务容量调整方法及其装置

技术领域

本公开涉及计算机领域，尤其涉及一种基于Kubernetes集群的模型服务容量调整方法及其装置。

背景技术

容器集群管理***Kubernetes是一个开源的、用于管理云平台中多个主机上的容器化的应用，它提供了应用部署、规划、更新、维护的一种机制，让部署容器化的应用简单并且高效。Kubernetes能够实现将应用的运行、配置、管理、所有生存周期与当前操作***解耦，并且使得容器和容器之间相互隔离，不会互相影响。Kubernetes可以对其中被管理的容器化应用的副本数，根据容器内资源的使用量，自动进行增加或减少，从而实现扩容或缩容的调度。

相关技术中，基于Kubernetes集群进行服务扩缩容的方式通常是通过监测中央处理器（Central Processing Unit，CPU）和内存使用量来作为Pod副本数增减依据，以提高Kubernetes集群中CPU和内存资源的利用率。然而，目前尚缺乏用于调整针对Kubernetes集群中使用图形处理器（Graphics Processing Unit，GPU）资源的模型服务容量的有效手段。

发明内容

为克服相关技术中存在的问题，本公开提供一种基于Kubernetes集群的模型服务容量调整方法及其装置。

根据本公开实施例的第一方面，提供一种基于Kubernetes集群的模型服务容量调整方法，所述Kubernetes集群上部署多个Pod副本，且在每个所述Pod副本中部署多个相同的服务进程，每个所述Pod副本中多个服务进程的个数大于或等于第一数值且小于或等于第二数值，所述方法包括：

响应于接收到资源容量调整信号，确定所述Pod副本的当前副本数和在每个所述Pod副本中部署的所述服务进程的当前进程数；

根据所述Pod副本的当前副本数和在每个所述Pod副本中部署的所述服务进程的当前进程数，对所述模型服务进行图形处理器GPU资源容量调整。

根据本公开实施例的第二方面，提供一种基于Kubernetes集群的模型服务容量调整装置，所述Kubernetes集群上部署多个Pod副本，且在每个所述Pod副本中部署多个相同的服务进程，每个所述Pod副本中多个服务进程的个数大于或等于第一数值且小于或等于第二数值，所述装置包括：

确定模块，用于在接收到资源容量调整信号时，确定所述Pod副本的当前副本数和在每个所述Pod副本中部署的所述服务进程的当前进程数；

调整模块，用于根据所述Pod副本的当前副本数和在每个所述Pod副本中部署的所述服务进程的当前进程数，对所述模型服务进行图形处理器GPU资源容量调整。

根据本公开实施例的第三方面，提供一种电子设备，包括：处理器；用于存储处理器可执行指令的存储器；其中，所述指令被所述处理器执行，以使所述处理器能够执行如前述第一方面所述的基于Kubernetes集群的模型服务容量调整方法。

根据本公开实施例的第四方面，提供一种计算机可读存储介质，当所述存储介质中的指令由电子设备的处理器执行时，使得所述电子设备能够执行如前述第一方面所述的基于Kubernetes集群的模型服务容量调整方法。

本公开的实施例提供的技术方案可以包括以下有益效果：

本公开实施例提出了一种新的GPU资源扩缩容方式，即可以根据Kubernetes集群上Pod副本的当前副本数和每个Pod副本中部署的服务进程的当前进程数，对部署在Kubernetes集群上的模型服务进行GPU资源容量调整，可以提高GPU资源的利用率，从而降低了服务运行的成本。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。

图1是根据一示例性实施例示出的一种基于Kubernetes集群的模型服务容量调整方法的流程图。

图2是根据另一示例性实施例示出的一种基于Kubernetes集群的模型服务容量调整方法的流程图。

图3是根据又一示例性实施例示出的一种基于Kubernetes集群的模型服务容量调整方法的流程图。

图4是根据又一示例性实施例示出的一种基于Kubernetes集群的模型服务容量调整方法的流程图。

图5是根据一示例性实施例示出的另一种基于Kubernetes集群的模型服务容量调整方法的流程图。

图6是根据一示例性实施例示出的一种基于Kubernetes集群的模型服务容量调整装置框图。

图7是根据一示例性实施例示出的一种电子设备的框图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。

需要说明的是，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。在本公开的描述中，“至少一个”的含义是一个或多个；“多个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。

容器集群管理***Kubernetes是一个开源的、用于管理云平台中多个主机上的容器化的应用，它提供了应用部署、规划、更新、维护的一种机制，让部署容器化的应用简单并且高效。Kubernetes能够实现将应用的运行、配置、管理、所有生存周期与当前操作***解耦，并且使得容器和容器之间相互隔离，不会互相影响。Kubernetes可以对其中被管理的容器化应用的副本数，根据容器内资源的使用量，自动进行增加或减少，从而实现扩容或缩容的调度。

相关技术中，基于Kubernetes集群进行服务扩缩容的方式通常是通过监测中央处理器（Central Processing Unit，CPU）和内存使用量来作为Pod副本数增减依据，以提高Kubernetes集群中CPU和内存资源的利用率。然而，目前尚缺乏用于调整针对Kubernetes集群中使用图形处理器（Graphics Processing Unit，GPU）资源的模型服务容量的有效手段。

基于上述问题，本公开提出了一种基于Kubernetes集群的模型服务容量调整方法及其装置，可以针对Kubernetes集群中使用图形处理器GPU资源的模型服务在扩缩容时，优先在Pod副本内增减服务进程数，当增减的服务进程数超出阈值范围，才进行Pod副本的增减，从而可以提高GPU资源的利用率，降低服务运行的成本。

图1是根据一示例性实施例示出的一种基于Kubernetes集群的模型服务容量调整方法的流程图。需要说明的是，本公开实施例的基于Kubernetes集群的模型服务容量调整方法可用于电子设备中，作为一种示例，该电子设备可以是服务器。

还需要说明的是，在本公开的实施例中，Kubernetes集群上部署多个Pod副本，且在每个Pod副本中部署多个相同的服务进程，每个Pod副本中多个服务进程的个数大于或等于第一数值且小于或等于第二数值。例如，该第一数值可以为1，该第二数值可以为maxM，maxM为大于1的整数。其中，Pod是可以在Kubernetes中创建和管理的、最小的可部署的计算单元。Pod是一组（一个或多个）容器；这些容器共享存储、网络、以及怎样运行这些容器的声明。

作为一种可能实现方式的示例，在基于Kubernetes集群部署使用GPU资源的模型服务时，不仅部署多个Pod副本，并且在每个Pod副本中部署多个相同的服务进程。

如图1所示，该基于Kubernetes集群的模型服务容量调整方法可以包括以下步骤。

在步骤101中，响应于接收到资源容量调整信号，确定Pod副本的当前副本数和在每个Pod副本中部署的服务进程的当前进程数。

在本公开的一些实施例中，该资源容量调整信号可以是资源扩容信号，或者还可以是资源缩容信号。

可选地，在接收到资源容量调整信号时，可以确定Kubernetes集群上Pod副本的当前副本数和每个Pod副本中部署的服务进程的当前进程数。

在步骤102中，根据Pod副本的当前副本数和在每个Pod副本中部署的服务进程的当前进程数，对模型服务进行图形处理器GPU资源容量调整。

可选地，可以根据Pod副本的当前副本数和在每个Pod副本中部署的服务进程的当前进程数，决定先在Pod副本内增减服务进程数，并在进程数超出阈值范围时，进行Pod副本数的增减，以实现对模型服务进行GPU资源的扩缩容。

在一种可能的实现方式中，可以优先对每个Pod副本中部署的服务进程的当前进程数进行调整，以完成本次对模型服务进行GPU资源容量的调整。或者，在另一种可能的实现方式中，可以按照预设的GPU资源容量调整策略，根据Pod副本的当前副本数和在每个Pod副本中部署的服务进程的当前进程数，从多个Pod副本中找出可被调整的Pod副本，以便对该可被调整的Pod副本中服务进程的当前进程数进行调整，若从多个Pod副本中未能找出可被调整的Pod副本，则对Pod副本的当前副本数进行调整，以完成对模型服务进行GPU资源容量调整。

本公开实施例提出了一种新的GPU资源扩缩容方式，即可以根据Kubernetes集群上Pod副本的当前副本数和每个Pod副本中部署的服务进程的当前进程数，对部署在Kubernetes集群上的模型服务进行GPU资源容量调整，可以提高GPU资源的利用率，从而降低了服务运行的成本。

图2是根据另一示例性实施例示出的一种基于Kubernetes集群的模型服务容量调整方法的流程图。如图2所示，该方法可以包括如下步骤。

在步骤201中，响应于接收到资源容量调整信号，确定Pod副本的当前副本数和在每个Pod副本中部署的服务进程的当前进程数。

在本公开的实施例中，步骤201可以分别采用本公开的各实施例中的任一种方式实现，本公开实施例并不对此作出限定，也不再赘述。

在步骤202中，判断每个Pod副本中服务进程的当前进程数是否超出预设的阈值范围。

可选地，由于本公开实施例在对模型服务进行资源容量调整时，优先在Pod副本内增减服务进程数，在进程数超出阈值范围时才进行Pod副本数的增减，所以在接收到资源容量调整信号之后，可以判断每个Pod副本中服务进程的当前进程数是否超出预设的阈值范围，若每个Pod副本中服务进程的当前进程数未超出预设的阈值范围，则执行步骤203；若每个Pod副本中服务进程的当前进程数超出预设的阈值范围，则执行步骤204。

在步骤203中，响应于每个Pod副本中服务进程的当前进程数未超出预设的阈值范围，调整在每个Pod副本中部署的服务进程的当前进程数。

在一种实现方式中，在每个Pod副本中服务进程的当前进程数未超出预设的阈值范围时，可以先对每个Pod副本中部署的服务进程的当前进程数进行调整。也就是说，在接收到资源容量调整信号时，如果每个Pod副本中服务进程的当前进程数未超出预设的阈值范围，则可以优先对每个Pod副本中服务进程的当前进程数进行调整，如在每个Pod副本内增减服务进程数。

在步骤204中，响应于每个Pod副本中服务进程的当前进程数超出预设的阈值范围，调整Pod副本的当前副本数，以完成本次对模型服务进行图形处理器GPU资源容量的调整。

在一种实现方式中，在每个Pod副本中服务进程的当前进程数超出预设的阈值范围时，说明Pod副本内服务进程数已经达到了极限，不能再对Pod副本内的服务进程数进行调整，此时可以调整Kubernetes集群上部署的Pod副本的当前副本数，以完成本次对模型服务进行GPU资源容量的调整。

需要说明的是，在本公开的一些实施例中，Pod副本中服务进程数的增减量以及Pod副本数的增减量，与模型服务的流量变化量相关，比如成正比。在一种实现方式中，以对模型服务进行扩容为例，在模型服务的流量突然增加，需要对模型服务的GPU资源进行扩容时，可以根据模型服务的流量变化量来增加在每个Pod副本中部署的服务进程的当前进程数，并在服务进程数超出阈值范围时进行Pod副本数的增加。也就是说，模型服务的流量变化量越大，则Pod副本中服务进程数和Pod副本数的调整量越大，模型服务的流量变化量越小，则Pod副本中服务进程数和Pod副本数的调整量越小。

本公开实施例的模型服务容量调整方法，在接收到资源容量调整信号时，可以优先在每个Pod副本内调整服务进程数，若每个Pod副本内的服务进程数超出阈值范围，则对Kubernetes集群上部署的Pod副本的当前副本数进行调整，以完成本次对模型服务进行GPU资源容量的调整，从而可以提高GPU资源的利用率，降低了服务运行的成本。

需要说明的是，在本公开的实施例中，资源容量调整信号可以为资源缩容信号。在资源容量调整信号为资源缩容信号时，可以对模型服务进行GPU资源缩容。图3是根据又一示例性实施例示出的一种基于Kubernetes集群的模型服务容量调整方法的流程图。在本实施例中，以资源容量调整信号为资源缩容信号为例，对基于Kubernetes集群的模型服务容量调整方法的实现方式进行描述。如图3所示，该方法可以包括如下步骤。

在步骤301中，响应于接收到资源缩容信号，确定Pod副本的当前副本数和在每个Pod副本中部署的服务进程的当前进程数。

在一种可能的实现方式中，在模型服务的流量发生变化（如流量减少）时，可以接收到模型服务发送的资源缩容信号。在接收到资源缩容信号时，可以确定Kubernetes集群上Pod副本的当前副本数和每个Pod副本中部署的服务进程的当前进程数。

在步骤302中，判断每个Pod副本中服务进程的当前进程数是否小于或等于第一数值。

可选地，由于本公开实施例在对模型服务进行资源缩容时，优先在Pod副本内缩减服务进程数，在进程数超出阈值范围时才进行Pod副本数的缩减，所以在接收到资源缩容信号之后，可以判断每个Pod副本中服务进程的当前进程数是否超出预设的阈值范围，比如，可以判断每个Pod副本中服务进程的当前进程数是否小于或等于第一数值。若每个Pod副本中服务进程的当前进程数大于第一数值且小于或等于第二数值，则判定每个Pod副本中服务进程的当前进程数未超出预设的阈值范围，则执行步骤303；若每个Pod副本中服务进程的当前进程数小于或等于第一数值，可认为每个Pod副本中服务进程的当前进程数超出阈值范围，则执行步骤304。

在步骤303中，响应于每个Pod副本中服务进程的当前进程数大于第一数值且小于或等于第二数值，缩减在每个Pod副本中部署的服务进程的当前进程数。

可选地，在每个Pod副本中服务进程的当前进程数大于第一数值且小于或等于第二数值时，可以缩减在每个Pod副本中部署的服务进程的当前进程数。例如，可以将每个Pod副本中部署的服务进程的当前进程数进行减一操作，也就是说，可以在每个Pod副本内删减一个服务进程，以完成本次对模型服务进行GPU资源缩容操作。

在步骤304中，响应于每个Pod副本中服务进程的当前进程数小于或等于第一数值，缩减Pod副本的当前副本数。

在一种实现方式中，在每个Pod副本中服务进程的当前进程数小于或等于第一数值时，说明Pod副本内服务进程数已经达到下限值，不能再对Pod副本内的服务进程数进行缩减，此时可以缩减Kubernetes集群上部署的Pod副本的当前副本数，以完成本次对模型服务进行GPU资源缩容操作。

举例而言，假设基于kubernetes集群部署模型服务时，部署N个Pod副本，每个Pod副本部署M个服务进程，其中1≤M≤maxM。在接收到对模型服务的资源缩容信号时，可以优先缩减每个Pod副本中服务进程数，即在每个Pod副本内进行M-1操作。当M=1时，才对Pod副本数进行N-1操作。例如，假设基于kubernetes集群部署模型服务时，部署5个Pod副本，每个Pod副本部署3个服务进程，在接收到对模型服务的资源缩容信号时，可以在这5个Pod副本内分别进行缩减服务进程数操作，即将每个Pod副本内的服务进程数缩减到2个，以完成本次对模型服务进行GPU资源缩容操作。当再次接收到模型服务的资源缩容信号时，由于这5个Pod副本内服务进程数未超出阈值范围，所以可以继续在这5个Pod副本内分别进行缩减服务进程数操作，即将每个Pod副本内的服务进程数缩减到1个，以完成本次对模型服务进行GPU资源缩容操作。当继续接收到模型服务的资源缩容信号时，由于这5个Pod副本内服务进程数超出阈值范围，即Pod副本内服务进程数为1，不能再对Pod副本内的服务进程数进行缩减，此时可以缩减Kubernetes集群上部署的Pod副本的当前副本数，即将5个Pod副本缩减到4个Pod副本。

需要说明的是，本公开实施例提出了一种新的GPU资源扩缩容方式，即针对kubernetes集群中使用GPU资源的模型服务在扩缩容时，优先在Pod副本内增减服务进程数，当进程数超出阈值范围，才进行Pod副本数的增减，其中服务进程数的增减多少以及Pod副本数的增减多少可以与模型服务的流量变化量有关，比如，流量变化量越大，则服务进程数和Pod副本数的增减量越大，本公开对此不做具体限定。

本公开实施例的模型服务容量调整方法，在接收到资源缩容信号时，可以优先在每个Pod副本内缩减服务进程数，若每个Pod副本内的服务进程数超出阈值范围，则对Kubernetes集群上部署的Pod副本的当前副本数进行缩减，以完成本次对模型服务进行GPU资源缩容操作，从而可以提高GPU资源的利用率，降低了服务运行的成本。

需要说明的是，在本公开的实施例中，资源容量调整信号可以为资源扩容信号。在资源容量调整信号为资源缩容信号时，可以对模型服务进行GPU资源扩容。图4是根据又一示例性实施例示出的一种基于Kubernetes集群的模型服务容量调整方法的流程图。在本实施例中，以资源容量调整信号为资源扩容信号为例，对基于Kubernetes集群的模型服务容量调整方法的实现方式进行描述。如图4所示，该方法可以包括如下步骤。

在步骤401中，响应于接收到资源扩容信号，确定Pod副本的当前副本数和在每个Pod副本中部署的服务进程的当前进程数。

在一种可能的实现方式中，在模型服务的流量发生变化（如流量增加）时，可以接收到模型服务发送的资源扩容信号。在接收到资源扩容信号时，可以确定Kubernetes集群上Pod副本的当前副本数和每个Pod副本中部署的服务进程的当前进程数。

在步骤402中，判定每个Pod副本中服务进程的当前进程数是否大于或等于第二数值。

可选地，由于本公开实施例在对模型服务进行资源扩容时，优先在Pod副本内增加服务进程数，在进程数超出阈值范围时才进行Pod副本数的增加，所以在接收到资源扩容信号之后，可以判断每个Pod副本中服务进程的当前进程数是否超出预设的阈值范围，比如，可以判断每个Pod副本中服务进程的当前进程数是否大于或等于第二数值。若每个Pod副本中服务进程的当前进程数大于或等于第一数值且小于第二数值，则判定每个Pod副本中服务进程的当前进程数未超出预设的阈值范围，则执行步骤403；若每个Pod副本中服务进程的当前进程数大于或等于第二数值，可认为每个Pod副本中服务进程的当前进程数超出阈值范围，则执行步骤404。

在步骤403中，响应于每个Pod副本中服务进程的当前进程数大于或等于第一数值且小于第二数值，增加在每个Pod副本中部署的服务进程的当前进程数。

可选地，在每个Pod副本中服务进程的当前进程数大于或等于第一数值且小于第二数值时，可以增加在每个Pod副本中部署的服务进程的当前进程数。例如，可以将每个Pod副本中部署的服务进程的当前进程数进行加一操作，也就是说，可以在每个Pod副本内增加一个服务进程，以完成本次对模型服务进行GPU资源扩容操作。

在步骤404中，响应于每个Pod副本中服务进程的当前进程数大于或等于第二数值，增加Pod副本的当前副本数。

在一种实现方式中，在每个Pod副本中服务进程的当前进程数大于或等于第二数值时，说明Pod副本内服务进程数已经达到上限值，不能再对Pod副本内的服务进程数进行增加操作，此时可以增加Kubernetes集群上部署的Pod副本的当前副本数，以完成本次对模型服务进行GPU资源扩容操作。

举例而言，假设基于kubernetes集群部署模型服务时，部署N个Pod副本，每个Pod副本部署M个服务进程，其中1≤M≤maxM。在接收到对模型服务的资源扩容信号时，可以优先增加每个Pod副本中服务进程数，即在每个Pod副本内进行M+1操作。当M= maxM时，才对Pod副本数进行N+1操作。例如，假设maxM为4，基于kubernetes集群部署模型服务时，部署5个Pod副本，每个Pod副本部署3个服务进程，在接收到对模型服务的资源扩容信号时，可以在这5个Pod副本内分别进行增加服务进程数操作，即将每个Pod副本内的服务进程数增加到4个，以完成本次对模型服务进行GPU资源扩容操作。当再次接收到模型服务的资源扩容信号时，由于这5个Pod副本内服务进程数超出阈值范围（即Pod副本内服务进程数等于maxM），所以不能再对Pod副本内的服务进程数进行增加操作，此时可以增加Kubernetes集群上部署的Pod副本的当前副本数，即将5个Pod副本增加到6个Pod副本。

本公开实施例的模型服务容量调整方法，在接收到资源扩容信号时，可以优先在每个Pod副本内增加服务进程数，若每个Pod副本内的服务进程数超出阈值范围，则对Kubernetes集群上部署的Pod副本的当前副本数进行增加操作，以完成本次对模型服务进行GPU资源扩容操作，从而可以提高GPU资源的利用率，降低了服务运行的成本。

图5是根据一示例性实施例示出的另一种基于Kubernetes集群的模型服务容量调整方法的流程图。如图5所示，该方法可以包括但不限于如下步骤。

在步骤501中，响应于接收到资源容量调整信号，确定Pod副本的当前副本数和在每个Pod副本中部署的服务进程的当前进程数。

在本公开的实施例中，步骤501可以分别采用本公开的各实施例中的任一种方式实现，本公开实施例并不对此作出限定，也不再赘述。

在步骤502中，根据预设的GPU资源容量调整策略、Pod副本的当前副本数和在每个Pod副本中部署的服务进程的当前进程数，对模型服务进行图形处理器GPU资源容量调整。

可选地，可以按照预设的GPU资源容量调整策略，根据Pod副本的当前副本数和在每个Pod副本中部署的服务进程的当前进程数，从多个Pod副本中找出可被调整的Pod副本，以便对该可被调整的Pod副本中服务进程的当前进程数进行调整，若从多个Pod副本中未能找出可被调整的Pod副本，则对Pod副本的当前副本数进行调整，以完成对模型服务进行GPU资源容量调整。

在本公开的一些实施例中，所述根据预设的GPU资源容量调整策略、Pod副本的当前副本数和在每个Pod副本中部署的服务进程的当前进程数，对模型服务进行图形处理器GPU资源容量调整的实现方式可如下：根据GPU资源容量调整策略，从多个Pod副本中确定出满足资源容量调整条件的至少一个第一Pod副本；响应于每个第一Pod副本中服务进程的当前进程数未超出预设的阈值范围，调整在每个第一Pod副本中部署的服务进程的当前进程数；和/或，响应于每个第一Pod副本中服务进程的当前进程数超出预设的阈值范围，调整其他Pod副本中服务进程的当前进程数，和/或，调整Pod副本的当前副本数，以完成本次对模型服务进行图形处理器GPU资源容量的调整；其中，其他Pod副本为多个Pod副本中除第一Pod副本之外的Pod副本。

在本公开的实施例中，上述资源容量调整信号为资源缩容信号；其中，上述GPU资源容量调整策略可包括：Pod副本的启动时长小于或等于预设时长，Pod副本的GPU资源占用量大于或等于第一阈值中的至少一种。

举例而言，在接收到对模型服务的资源缩容信号时，可以从多个Pod副本中找出Pod副本的启动时长短和/或Pod副本的GPU资源占用量大的第一Pod副本，在确定该第一Pod副本中服务进程的当前进程数未超出预设的阈值范围（如当前进程数大于第一数值且小于或等于第二数值）时，可以缩减每个第一Pod副本中部署的服务进程的当前进程数。在确定该第一Pod副本中服务进程的当前进程数超出预设的阈值范围（如当前进程数小于或等于第一数值）时，可以缩减其他Pod副本中服务进程的当前进程数，和/或，缩减Pod副本的当前副本数，以完成本次对模型服务进行GPU资源缩容操作。

在本公开的实施例中，上述资源容量调整信号为资源扩容信号；其中，上述GPU资源容量调整策略可包括：Pod副本的启动时长小于或等于预设时长，Pod副本的GPU资源占用量小于或等于第二阈值中的至少一种。其中，第一阈值大于第二阈值。

举例而言，在接收到对模型服务的资源扩容信号时，可以从多个Pod副本中找出Pod副本的启动时长短和/或Pod副本的GPU资源占用量小的第一Pod副本，在确定该第一Pod副本中服务进程的当前进程数未超出预设的阈值范围（如当前进程数大于或等于第一数值且小于第二数值）时，可以增加每个第一Pod副本中部署的服务进程的当前进程数。在确定该第一Pod副本中服务进程的当前进程数超出预设的阈值范围（如当前进程数大于或等于第二数值）时，可以增加其他Pod副本中服务进程的当前进程数，和/或，增加Pod副本的当前副本数，以完成本次对模型服务进行GPU资源扩容操作。

本公开实施例提出了一种新的GPU资源扩缩容方式，即可以根据Kubernetes集群上Pod副本的当前副本数和每个Pod副本中部署的服务进程的当前进程数，结合GPU资源容量调整策略对部署在Kubernetes集群上的模型服务进行GPU资源容量调整，可以提高GPU资源的利用率，从而降低了服务运行的成本。

图6是根据一示例性实施例示出的一种基于Kubernetes集群的模型服务容量调整装置框图。需要说明的是，在本公开的实施例中，Kubernetes集群上部署多个Pod副本，且在每个Pod副本中部署多个相同的服务进程，每个Pod副本中多个服务进程的个数大于或等于第一数值且小于或等于第二数值。参照图6，该装置包括：确定模块601和调整模块602。

其中，确定模块601用于在接收到资源容量调整信号时，确定Pod副本的当前副本数和在每个Pod副本中部署的服务进程的当前进程数。

调整模块602用于根据Pod副本的当前副本数和在每个Pod副本中部署的服务进程的当前进程数，对模型服务进行图形处理器GPU资源容量调整。

在本公开的一些实施例中，调整模块602根据Pod副本的当前副本数和在每个Pod副本中部署的服务进程的当前进程数，对模型服务进行图形处理器GPU资源容量调整的实现方式可如下：在每个Pod副本中服务进程的当前进程数未超出预设的阈值范围时，调整在每个Pod副本中部署的服务进程的当前进程数；和/或，响应于每个Pod副本中服务进程的当前进程数超出预设的阈值范围，调整Pod副本的当前副本数，以完成本次对模型服务进行图形处理器GPU资源容量的调整。

在本公开的一些实施例中，资源容量调整信号为资源缩容信号；其中，调整模块602具体用于：在每个Pod副本中服务进程的当前进程数大于第一数值且小于或等于第二数值时，缩减在每个Pod副本中部署的服务进程的当前进程数；和/或，响应于每个Pod副本中服务进程的当前进程数小于或等于第一数值，缩减Pod副本的当前副本数。

在本公开的一些实施例中，资源容量调整信号为资源扩容信号；其中，调整模块602具体用于：在每个Pod副本中服务进程的当前进程数大于或等于第一数值且小于第二数值时，增加在每个Pod副本中部署的服务进程的当前进程数；和/或，响应于每个Pod副本中服务进程的当前进程数大于或等于第二数值，增加Pod副本的当前副本数。

在本公开的一些实施例中，调整模块602根据Pod副本的当前副本数和在每个Pod副本中部署的服务进程的当前进程数，对模型服务进行图形处理器GPU资源容量调整的实现方式可如下：根据预设的GPU资源容量调整策略、Pod副本的当前副本数和在每个Pod副本中部署的服务进程的当前进程数，对模型服务进行图形处理器GPU资源容量调整。

在本公开的实施例中，调整模块602具体用于：根据GPU资源容量调整策略，从多个Pod副本中确定出满足资源容量调整条件的至少一个第一Pod副本；响应于每个第一Pod副本中服务进程的当前进程数未超出预设的阈值范围，调整在每个第一Pod副本中部署的服务进程的当前进程数；和/或，响应于每个第一Pod副本中服务进程的当前进程数超出预设的阈值范围，调整其他Pod副本中服务进程的当前进程数，和/或，调整Pod副本的当前副本数，以完成本次对模型服务进行图形处理器GPU资源容量的调整；其中，其他Pod副本为多个Pod副本中除第一Pod副本之外的Pod副本。

其中，在本公开的实施例中，资源容量调整信号为资源缩容信号；其中，GPU资源容量调整策略包括：Pod副本的启动时长小于或等于预设时长，Pod副本的GPU资源占用量大于或等于第一阈值中的至少一种；或者，资源容量调整信号为资源扩容信号；其中，GPU资源容量调整策略包括：Pod副本的启动时长小于或等于预设时长，Pod副本的GPU资源占用量小于或等于第二阈值中的至少一种；其中，第一阈值大于第二阈值。

关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。

图7是根据一示例性实施例示出的一种电子设备700的框图。例如，电子设备700电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。如图7所示，上述电子设备700可以包括：

存储器710及处理器720，连接不同组件（包括存储器710和处理器720）的总线730，存储器710存储有处理器720可执行指令；其中，处理器720被配置为执行所述指令，以实现本公开实施例所述的基于Kubernetes集群的模型服务容量调整方法。

总线730表示几类总线结构中的一种或多种，包括存储器总线或者存储器控制器，***总线，图形加速端口，处理器或者使用多种总线结构中的任意总线结构的局域总线。举例来说，这些体系结构包括但不限于工业标准体系结构（ISA）总线，微通道体系结构（MAC）总线，增强型ISA总线、视频电子标准协会（VESA）局域总线以及***组件互连（PCI）总线。

电子设备700典型地包括多种电子设备可读介质。这些介质可以是任何能够被电子设备700访问的可用介质，包括易失性和非易失性介质，可移动的和不可移动的介质。存储器710还可以包括易失性存储器形式的计算机***可读介质，例如随机存取存储器（RAM）740和/或高速缓存存储器750。电子设备700可以进一步包括其它可移动/不可移动的、易失性/非易失性计算机***存储介质。仅作为举例，存储***760可以用于读写不可移动的、非易失性磁介质（图7未显示，通常称为“硬盘驱动器”）。尽管图7中未示出，可以提供用于对可移动非易失性磁盘（例如“软盘”）读写的磁盘驱动器，以及对可移动非易失性光盘（例如CD-ROM, DVD-ROM或者其它光介质）读写的光盘驱动器。在这些情况下，每个驱动器可以通过一个或者多个数据介质接口与总线730相连。存储器710可以包括至少一个程序产品，该程序产品具有一组（例如至少一个）程序模块，这些程序模块被配置以执行本公开各实施例的功能。

具有一组（至少一个）程序模块770的程序/实用工具780，可以存储在例如存储器710中，这样的程序模块770包括——但不限于——操作***、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。程序模块770通常执行本公开所描述的实施例中的功能和/或方法。

电子设备700也可以与一个或多个外部设备790（例如键盘、指向设备、显示器791等）通信，还可与一个或者多个使得用户能与该电子设备700交互的设备通信，和/或与使得该电子设备700能与一个或多个其它计算设备进行通信的任何设备（例如网卡，调制解调器等等）通信。这种通信可以通过输入/输出（I/O）接口792进行。并且，电子设备700还可以通过网络适配器793与一个或者多个网络（例如局域网（LAN），广域网（WAN）和/或公共网络，例如因特网）通信。如图所示，网络适配器793通过总线730与电子设备700的其它模块通信。应当明白，尽管图中未示出，可以结合电子设备700使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID***、磁带驱动器以及数据备份存储***等。

处理器720通过运行存储在存储器710中的程序，从而执行各种功能应用以及数据处理。

需要说明的是，本实施例的服务器的实施过程和技术原理参见前述对本公开实施例的基于Kubernetes集群的模型服务容量调整方法的解释说明，此处不再赘述。

为了实现上述实施例，本公开还提出一种存储介质。

其中，该存储介质中的指令由服务器的处理器执行时，使得服务器能够执行如前所述的基于Kubernetes集群的模型服务容量调整方法。

为了实现上述实施例，本公开还提供一种计算机程序产品。该计算机程序产品包括计算机程序，该计算机程序在被服务器的处理器执行时实现如前所述的基于Kubernetes集群的模型服务容量调整方法。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本公开旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求指出。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。

Claims (12)

1.一种基于Kubernetes集群的模型服务容量调整方法，其特征在于，所述Kubernetes集群上部署多个Pod副本，且在每个所述Pod副本中部署多个相同的服务进程，每个所述Pod副本中多个服务进程的个数大于或等于第一数值且小于或等于第二数值，所述方法包括：

响应于接收到资源容量调整信号，确定所述Pod副本的当前副本数和在每个所述Pod副本中部署的所述服务进程的当前进程数；

根据所述Pod副本的当前副本数和在每个所述Pod副本中部署的所述服务进程的当前进程数，对所述模型服务进行图形处理器GPU资源容量调整；

所述根据所述Pod副本的当前副本数和在每个所述Pod副本中部署的所述服务进程的当前进程数，对所述模型服务进行图形处理器GPU资源容量调整，包括：

响应于每个所述Pod副本中服务进程的当前进程数未超出预设的阈值范围，调整在每个所述Pod副本中部署的所述服务进程的当前进程数；响应于每个所述Pod副本中服务进程的当前进程数超出预设的阈值范围，调整所述Pod副本的当前副本数，以完成本次对所述模型服务进行图形处理器GPU资源容量的调整；

所述资源容量调整信号为资源缩容信号；其中，

所述响应于每个所述Pod副本中服务进程的当前进程数未超出预设的阈值范围，调整在每个所述Pod副本中部署的所述服务进程的当前进程数，包括：

响应于每个所述Pod副本中服务进程的当前进程数大于所述第一数值且小于或等于所述第二数值，缩减在每个所述Pod副本中部署的所述服务进程的当前进程数；

所述响应于每个所述Pod副本中服务进程的当前进程数超出预设的阈值范围，调整所述Pod副本的当前副本数，包括：

响应于每个所述Pod副本中服务进程的当前进程数小于或等于所述第一数值，缩减所述Pod副本的当前副本数。

2.如权利要求1所述的方法，其特征在于，所述资源容量调整信号为资源扩容信号；其中，

所述响应于每个所述Pod副本中服务进程的当前进程数未超出预设的阈值范围，调整在每个所述Pod副本中部署的所述服务进程的当前进程数，包括：

响应于每个所述Pod副本中服务进程的当前进程数大于或等于所述第一数值且小于所述第二数值，增加在每个所述Pod副本中部署的所述服务进程的当前进程数；

所述响应于每个所述Pod副本中服务进程的当前进程数超出预设的阈值范围，调整所述Pod副本的当前副本数，包括：

响应于每个所述Pod副本中服务进程的当前进程数大于或等于所述第二数值，增加所述Pod副本的当前副本数。

3.如权利要求1所述的方法，其特征在于，所述根据所述Pod副本的当前副本数和在每个所述Pod副本中部署的所述服务进程的当前进程数，对所述模型服务进行图形处理器GPU资源容量调整，包括：

根据预设的GPU资源容量调整策略、所述Pod副本的当前副本数和在每个所述Pod副本中部署的所述服务进程的当前进程数，对所述模型服务进行图形处理器GPU资源容量调整。

4.如权利要求3所述的方法，其特征在于，所述根据预设的GPU资源容量调整策略、所述Pod副本的当前副本数和在每个所述Pod副本中部署的所述服务进程的当前进程数，对所述模型服务进行图形处理器GPU资源容量调整，包括：

根据所述GPU资源容量调整策略，从所述多个Pod副本中确定出满足资源容量调整条件的至少一个第一Pod副本；

响应于每个所述第一Pod副本中服务进程的当前进程数未超出预设的阈值范围，调整在每个所述第一Pod副本中部署的所述服务进程的当前进程数；和/或，

响应于每个所述第一Pod副本中服务进程的当前进程数超出预设的阈值范围，调整其他Pod副本中服务进程的当前进程数，和/或，调整所述Pod副本的当前副本数，以完成本次对所述模型服务进行图形处理器GPU资源容量的调整；其中，所述其他Pod副本为所述多个Pod副本中除所述第一Pod副本之外的Pod副本。

5.如权利要求3或4所述的方法，其特征在于，

所述资源容量调整信号为资源缩容信号；其中，所述GPU资源容量调整策略包括：Pod副本的启动时长小于或等于预设时长，Pod副本的GPU资源占用量大于或等于第一阈值中的至少一种；或者，

所述资源容量调整信号为资源扩容信号；其中，所述GPU资源容量调整策略包括：Pod副本的启动时长小于或等于预设时长，Pod副本的GPU资源占用量小于或等于第二阈值中的至少一种；

其中，所述第一阈值大于所述第二阈值。

6.一种基于Kubernetes集群的模型服务容量调整装置，其特征在于，所述Kubernetes集群上部署多个Pod副本，且在每个所述Pod副本中部署多个相同的服务进程，每个所述Pod副本中多个服务进程的个数大于或等于第一数值且小于或等于第二数值，所述装置包括：

确定模块，用于在接收到资源容量调整信号时，确定所述Pod副本的当前副本数和在每个所述Pod副本中部署的所述服务进程的当前进程数；

调整模块，用于根据所述Pod副本的当前副本数和在每个所述Pod副本中部署的所述服务进程的当前进程数，对所述模型服务进行图形处理器GPU资源容量调整；

所述调整模块具体用于：

在每个所述Pod副本中服务进程的当前进程数未超出预设的阈值范围时，调整在每个所述Pod副本中部署的所述服务进程的当前进程数；响应于每个所述Pod副本中服务进程的当前进程数超出预设的阈值范围，调整所述Pod副本的当前副本数，以完成本次对所述模型服务进行图形处理器GPU资源容量的调整；

所述资源容量调整信号为资源缩容信号；其中，所述调整模块具体用于：

在每个所述Pod副本中服务进程的当前进程数大于所述第一数值且小于或等于所述第二数值时，缩减在每个所述Pod副本中部署的所述服务进程的当前进程数；

响应于每个所述Pod副本中服务进程的当前进程数小于或等于所述第一数值，缩减所述Pod副本的当前副本数。

7.如权利要求6所述的装置，其特征在于，所述资源容量调整信号为资源扩容信号；其中，所述调整模块具体用于：

在每个所述Pod副本中服务进程的当前进程数大于或等于所述第一数值且小于所述第二数值时，增加在每个所述Pod副本中部署的所述服务进程的当前进程数；和/或，

响应于每个所述Pod副本中服务进程的当前进程数大于或等于所述第二数值，增加所述Pod副本的当前副本数。

8.如权利要求6所述的装置，其特征在于，所述调整模块具体用于：

根据预设的GPU资源容量调整策略、所述Pod副本的当前副本数和在每个所述Pod副本中部署的所述服务进程的当前进程数，对所述模型服务进行图形处理器GPU资源容量调整。

9.如权利要求8所述的装置，其特征在于，所述调整模块具体用于：

根据所述GPU资源容量调整策略，从所述多个Pod副本中确定出满足资源容量调整条件的至少一个第一Pod副本；

响应于每个所述第一Pod副本中服务进程的当前进程数未超出预设的阈值范围，调整在每个所述第一Pod副本中部署的所述服务进程的当前进程数；和/或，

响应于每个所述第一Pod副本中服务进程的当前进程数超出预设的阈值范围，调整其他Pod副本中服务进程的当前进程数，和/或，调整所述Pod副本的当前副本数，以完成本次对所述模型服务进行图形处理器GPU资源容量的调整；其中，所述其他Pod副本为所述多个Pod副本中除所述第一Pod副本之外的Pod副本。

10.如权利要求8或9所述的装置，其特征在于，

所述资源容量调整信号为资源缩容信号；其中，所述GPU资源容量调整策略包括：Pod副本的启动时长小于或等于预设时长，Pod副本的GPU资源占用量大于或等于第一阈值中的至少一种；或者，

所述资源容量调整信号为资源扩容信号；其中，所述GPU资源容量调整策略包括：Pod副本的启动时长小于或等于预设时长，Pod副本的GPU资源占用量小于或等于第二阈值中的至少一种；

其中，所述第一阈值大于所述第二阈值。

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

处理器；

用于存储处理器可执行指令的存储器；其中，所述指令被所述处理器执行，以使所述处理器能够执行如权利要求1至5中任一项所述的基于Kubernetes集群的模型服务容量调整方法。

12.一种计算机可读存储介质，其特征在于，当所述存储介质中的指令由电子设备的处理器执行时，使得所述电子设备能够执行如权利要求1至5中任一项所述的基于Kubernetes集群的模型服务容量调整方法。

Images