CN111459612A - 针对Kubernetes系统中Pod的更新方法及装置 - Google Patents

Abstract

本说明书公开一种针对Kubernetes系统中Pod的更新方法及装置。所述方法包括：根据预先确定出的针对Kubernetes系统中Pod的本次更新数，指示Kubernetes系统对所述需要更新的Pod进行更新，所述本次更新数小于需要更新的Pod总个数；当确定出本次完成更新的Pod数量等于所述本次更新数时，则暂停更新；获取已完成更新的Pod对应的唯一标识，并发送给测试地址，以便对所述已完成更新的Pod进行测试。

Description

针对Kubernetes系统中Pod的更新方法及装置

技术领域

本文件涉及计算机技术领域，尤其涉及一种针对Kubernetes系统中Pod的更新方法及装置。

背景技术

Kubernetes作为一种可以自动部署、扩展和管理“容器化应用程序”的开源系统，可以提供一种跨主机集群的自动部署、扩展以及运行应用程序容器的平台。Kubernetes的基本调度单元称为Pod。一个Pod可以包含一个或多个容器，从而可以使Pod可以一直位于主机上，并且共享资源Kubernetes中的每个Pod都被分配一个唯一的(在集群内的)IP地址。

根据业务需求通常会对Pod进行更新，比如可以依次对需要更新的Pod进行逐个更新。然而在对Pod进行更新的过程中，可能由于一些错误导致系统出现不可用的情况，这对于具有高可用需求的业务而言很不理想。所以，亟需提供一种方案，能够在对Pod进行更新时，降低业务故障的风险。

发明内容

本说明书实施例提供一种针对Kubernetes系统中Pod的更新方法和装置，能够在对Kubernetes系统中需要更新的Pod进行更新的过程中，降低业务故障的风险，尽量保障业务的高可用性。

为解决上述技术问题，本说明书实施例是这样实现的：

本说明书实施例采用下述技术方案：

第一方面，提出了一种针对Kubernetes系统中Pod的更新方法，包括：

根据预先确定出的针对Kubernetes系统中Pod的本次更新数，指示Kubernetes系统对所述需要更新的Pod进行更新，所述本次更新数小于需要更新的Pod总个数；

当确定出本次完成更新的Pod数量等于所述本次更新数时，则暂停更新；

获取已完成更新的Pod对应的唯一标识，并发送给测试地址，以便对所述已完成更新的Pod进行测试。

第二方面，提出了一种针对Kubernetes系统中Pod的更新装置，包括：更新指示单元、更新控制单元、以及测试返回单元，其中，

所述更新指示单元，用于根据预先确定出的针对Kubernetes系统中Pod的本次更新数，指示Kubernetes系统对所述需要更新的Pod进行更新，所述本次更新数小于需要更新的Pod总个数；

所述更新控制单元，用于当确定出本次完成更新的Pod数量等于所述本次更新数时，则暂停更新；

所述测试返回单元，用于获取已完成更新的Pod对应的唯一标识，并发送给测试地址，以便对所述已完成更新的Pod进行测试。

第三方面，提出了一种电子设备，应用于应用服务端，该电子设备包括：

处理器；以及

被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器执行以下操作：

根据预先确定出的针对Kubernetes系统中Pod的本次更新数，指示Kubernetes系统对所述需要更新的Pod进行更新，所述本次更新数小于需要更新的Pod总个数；

当确定出本次完成更新的Pod数量等于所述本次更新数时，则暂停更新；

获取已完成更新的Pod对应的唯一标识，并发送给测试地址，以便对所述已完成更新的Pod进行测试。

第四方面，提出了一种计算机可读存储介质，应用于应用服务端，所述计算机可读存储介质存储一个或多个程序，所述一个或多个程序当被包括多个应用程序的电子设备执行时，使得所述电子设备执行以下操作：

根据预先确定出的针对Kubernetes系统中Pod的本次更新数，指示Kubernetes系统对所述需要更新的Pod进行更新，所述本次更新数小于需要更新的Pod总个数；

当确定出本次完成更新的Pod数量等于所述本次更新数时，则暂停更新；

获取已完成更新的Pod对应的唯一标识，并发送给测试地址，以便对所述已完成更新的Pod进行测试。

由以上实施例提供的技术方案可见，针对Kubernetes系统中Pod，可以先根据预先确定出的、比需要更新的Pod总个数小的本次更新数，并指示Kubernetes系统对需要更新的Pod进行部分更新。当确定出本次更新完成后，则暂停更新，并获取已完成更新的Pod对应的唯一标识，以此发送给测试地址，以便对已完成更新的Pod进行测试。

可见，利用本实施例在对Kubernetes系统中的Pod进行更新时，可以分批次进行更新，在每次分批更新完后，暂停更新进度，并提供对更新结果的测试条件。由于可以对Pod进行分批次更新，并在每次更新后进行暂停、测试，所以便可以在对Kubernetes系统中的Pod进行更新的过程中，降低由更新而导致的业务故障风险，从而尽量保障业务的高可用性。

附图说明

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

图1为本说明书实施例提供的针对Kubernetes系统中Pod的更新方法的流程示意图；

图2为本说明书实施例提供的针对Kubernetes系统中Pod的更新方法的流程示意图；

图3为本说明书实施例提供的针对Kubernetes系统中Pod的更新方法的示意图；

图4为本说明书实施例提供的针对Kubernetes系统中Pod的更新系统的结构图；

图5本说明书实施例提供的电子设备的结构示意图。

具体实施方式

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

以下结合附图，详细说明本说明书中各实施例提供的技术方案。

实施例1

本实施例提供一种针对Kubernetes系统中Pod的更新方法，可以在对Kubernetes系统中需要更新的Pod进行更新的过程中，降低业务故障的风险，尽量保障业务的高可用性。可以假设该方法的执行主体为服务端，具体流程示意图如图1所示，包括：

步骤102：根据预先确定出的针对Kubernetes系统中Pod的本次更新数，指示Kubernetes系统对需要更新的Pod进行更新。

在前文已经介绍，Kubernetes可以是一种自动部署、扩展和管理“容器化应用程序”的开源系统，而Pod可以是Kubernetes的基本调度单元。在实际的应用环境中，还可以存在一个控制器Deployment，该控制器可以用来管理、控制Pod，比如可以对Pod进行创建、删除等，并且该控制器通常可以有自己的描述信息，而描述信息中可以包含描述所控制的Pod的多种基本信息。比如总个数、版本信息、运行情况、对应的唯一标识等。

在实际应用中，根据业务的复杂程度，可能会创建多个不同的Pod，而为满足不断提升的业务需求，通常需要对Pod进行定期更新，比如基于新功能、或修复漏洞等。然而一次性更新全部Pod可能会由于某个更新后的Pod出现错误，而导致业务不可用，所以本说明书可以采取对需要更新的Pod进行分批更新的方式。

为了实现针对Kubernetes系统中的Pod进行分批更新，则可以预先确定出本次更新数，这里的本次更新数可以是指本次更新Pod时，最大的更新数，而为了实现分批更新，本次更新数可以小于需要更新的Pod总个数。比如根据Deployment的描述信息，可以确定出有10个需要更新的Pod，为了能够对这10个Pod进行分批更新，可以预先确定出小于10个的本次更新数，具体比如可以随机确定出一个小于10的正整数。

在实际应用中，对于如何分批次更新Pod，可以预先设置分批更新的进度，而分批更新的进度，可以通过不同参数设置。

比如可以通过最大不可用比例设置分批更新进度，这里的最大不可用、或称最大不可达，可以指代在对Pod进行更新时，最多可以容许出现不可用的Pod个数，具体比如当最大不可用比例为20％、需要更新的Pod个数为如前所举例的10个，那么最大不可达数可以是2，这便可以作为分批更新Pod的依据，具体可以设置1或2为本次更新数。也即，可以预先设置最大不可用比例、或直接设置最大不可用数，从而据此确定出本次更新数。

又如可以通过最大激增比例设置分批更新进度，这里的最大激增，可以指代在对Pod进行更新时，一次可以增加更新的个数，具体比如当最大激增比例为20％、需要更新的Pod个数为如前所举例的10个，那么最大激增数可以是2，这便可以作为分批更新Pod的依据，具体可以将2加成在将要更新的个数上。也即，可以预先设置最大激增比例、或最大激增数，从而据此确定出本次更新数。

在实际应用中，可以预先分别设置最大不可用比例、以及最大激增比例，当根据Deployment描述信息确定出需要更新的Pod总个数后，则可以根据预先设置的最大不可用比例、以及最大激增比例，分别确定出最大不可用数、以及最大激增数。并可以通过加和、或取最大、或取最小的方式，预先确定出出本次更新数。

此后，便可以根据本次更新数，指示Kubernetes系统对需要更新的Pod进行更新，具体地，对Pod进行更新时，可以根据Pod镜像文件先创建一个新的Pod，并将业务从旧的Pod迁移至新的Pod，再将旧的Pod删除，从而实现对Pod进行更新，并保持Pod总个数保持在较为稳定的状态。

在实际的业务场景中，还可以存在更新Pod所需要的镜像，由于Kubernetes系统中存在控制器Deployment，所以可以通过指示Kubernetes系统中的Deployment对Pod进行更新，而更新的依据，可以利用运行Pod的节点，根据镜像地址，拉取对应的镜像文件，从而由Deployment基于镜像文件，创建新的Pod、删除旧的Pod，来实现对Pod的更新。

步骤104：当确定出本次完成更新的Pod数量等于本次更新数时，则暂停更新。

在前文已经介绍，当指示Kubernetes系统对需要更新的Pod进行更新后，可以根据用于更新的Pod镜像地址，通过Pod所在的节点进去拉取镜像，实现对Pod进行更新。比如有10个需要更新的Pod，那么就可以有对应的10个镜像，而在Kubernetes系统对Pod进行更新时，则可以根据本次更新数，选取相应个数的镜像，以便对Pod进行更新。具体比如根据步骤102的指示，若本次更新数为4，那么则可以从10个镜像中选取4个，作为更新选取的4个Pod的依据。

在前文已经介绍，可以通过控制器Deployment管理各Pod，且Deployment中包含多种描述信息，来描述Pod的基本信息，而本步骤便可以监听Deployment的描述信息变化情况，比如可以通过描述信息，监听本次完成更新的Pod数量，再判断是否与本次更新数相同。

当确定出本次完成更新的Pod数量等于本次更新数时，为了降低业务故障的风险，此时可以暂停更新，并在后续步骤中向测试方提供针对Pod的测试信息。

步骤106：获取已完成更新的Pod对应的唯一标识，并发送给测试地址，以便对已完成更新的Pod进行测试。

在前述步骤中，为了降低业务故障的风险，尽量保障业务的高可用性，可以暂停更新，而本步骤为了能够实现对已完成更新的Pod进行测试，可以获取已完成更新的Pod对应的唯一标识，比如在实际的业务环境中，该唯一标识可以是IP(Internet Protocol，网际互连协议)地址。

具体比如，Deployment可以管理一个内网，为了实现对多个Pod进行管理，可以为每个Pod分配唯一的内网IP地址，而本步骤便可以获取这个唯一标识，并发送给测试地址，比如测试地址可以是测试人员的邮箱、某个用于管理Pod的图形用户界面，也可以是自动化测试的地址等，以便可以对已完成更新的Pod进行测试。实际中，测试人员、或自动化测试模型便可以根据IP地址，进行查询一段时间内的运行情况、压力测试等测试操作。

在实际应用中，当测试完毕后，可以再次循环执行上述步骤，从而实现分批次更新Pod的效果，比如当根据测试结果为可用、确定测试完毕后，可以再次执行步骤102，根据本次更新数，指示Kubernetes系统对需要更新的Pod进行更新，此后可以依次执行步骤104和步骤106，根据已完成更新的Pod数决定是否暂停更新，并再次获取IP地址，以便再次进行测试。根据前文举例，若需要更新的Pod总个数为10个，本次更新数为4，那么便可以进行分批次更新，每次更新4个Pod。

由以上实施例提供的技术方案可见，可以先根据预先确定出的、比需要更新的Pod总个数小的本次更新数，指示Kubernetes系统对需要更新的Pod进行部分更新，当确定出本次完成后，则暂停更新，并获取已完成更新的Pod对应的唯一标识，以此发送给测试地址，以便对已完成更新的Pod进行测试。

可见，利用本实施例在对Kubernetes系统中的Pod进行更新时，可以分批次进行更新，在每次分批更新完后，暂停更新进度，并提供对更新结果的测试条件。

由于可以对Pod进行分批次更新，并在每次更新后进行暂停、测试，所以便可以在对Kubernetes系统中的Pod进行更新的过程中，降低由更新而导致的业务故障风险，从而尽量保障业务的高可用性。

实施例2

基于相同的构思，本说明书实施例2提供了一种针对Kubernetes系统中Pod的更新方法，可以根据用户的分批次更新需求对Kubernetes系统中需要更新的Pod进行更新，并在更新的过程中，降低业务故障的风险，尽量保障业务的高可用性。可以假设该方法的执行主体为服务端，具体流程示意图如图2所示，包括：

步骤202：接收用户发送的、包含更新进度的更新请求。

在实际应用中，可以为用户提供输入接口，用户通过该接口，可以根据不同的需求，设置更新进度。则本步骤便可以接收用户发送的、包含更新进度的更新请求。

具体地，更新进度可以用于表征对Pod进行分批次更新时，每批次更新的数量。比如这里的更新进度可以是用户设置更新进度比例，例如20％、30％、40％等，当然也可以是具体的数值，例如2、3、4等。

在实际应用中，更新请求中，还可以包含用于更新Pod的镜像地址，比如需要更新10个Pod，那么便可以包含10个镜像地址，

步骤204：根据该更新进度、以及需要更新的Pod的总个数，确定本次更新数。

根据前文介绍，用户设置的更新进度可以表征在对Pod进行分批次更新时，这一批次期望的更新数，那么本步骤便可以根据更新进度，确定本次更新数。而具体地，则可以根据更新进度、以及需要更新的Pod的总个数，确定本次更新数。前述步骤中已经介绍，用户可以设置更新进度比例为20％、30％、或40％等，那么若需要更新的Pod的总个数为10，则本次更新数可以是2、3、或4，当然用户也可以设置具体的数值。

在前述实施例中介绍了，为了实现分批次更新Pod，本次更新数要小于需要更新的Pod总个数。在本步骤中，若更新进度包括进度比例时，则可以直接根据需要更新的Pod的总个数确定出本次更新数，但若更新进度包括更新数时，还可以判断更新数是否小于该总个数，若小于，则可以确定为本次更新数。

在前述实施例中已经介绍，可以通过最大不可用、以及最大激增，确定出本次更新数，那么在一种实施方式中，为了适配一种业务逻辑，也可以结合用户设置的更新进度、以及这两个参数，确定本次更新数。

具体地，可以先根据用户设置的更新进度，确定出更新数，再根据最大激增比例确定出最大激增数，此后用该更新数减最大激增数，得到的值可以作为最大不可达数，从而使某种固定的业务逻辑，可以根据最大不可达数以及最大激增数，确定出本次更新数。可见，若根据用户设置的更新进度确定出的更新数大于最大激增数时，那么以业务逻辑为最大不可用数加最大激增数确定出的本次更新数，也就等于该更新数。

步骤206：根据预先确定出的针对Kubernetes系统中Pod的本次更新数，指示Kubernetes系统对需要更新的Pod进行更新。

步骤208：当确定出本次完成更新的Pod数量等于本次更新数时，则暂停更新。

步骤210：获取已完成更新的Pod对应的唯一标识，并发送给测试地址，以便对该已完成更新的Pod进行测试。

步骤206至步骤210与前述实施例中的步骤102至步骤106类似，这里不再赘述。

而在前述实施例中介绍，可以有Pod所在的节点拉取镜像文件，在本实施例中，则可以指示Pod所在的节点，根据用户的更新请求中包含的更新Pod的镜像地址，拉取对应的镜像文件，并由控制器Deployment进行创建Pod。

在实际应用中，当测试完毕后，可以再次循环执行上述步骤，从而实现分批次更新Pod的效果。比如当根据测试结果为可用，确定测试完毕后，用户可以再次发送包含更新进度的更新请求，此后则可以再次执行步骤202和步骤204，以便确定出本次更新数，指示Kubernetes系统对需要更新的Pod进行更新，以及可以暂停更新，并再次获取IP地址，以便再次进行测试。

也即用户可以根据不同的需求，为每批次设置相同或不同的更新进度，从而可以进一步按需控制Pod的更新过程。比如，第一次可以更新3个Pod，第二次可以更新6个Pod，等。

步骤212：接收用户发送的继续更新请求。

步骤214：根据确定出的本次更新数，再次指示Kubernetes系统对需要更新的Pod进行更新。

在实际应用中，当测试完毕后，用户还可以以上一次的更新数作为下一次的更新数，而无需再次设置更新进度，此时则可以发送继续更新请求。据此，则可以根据上一次更新Pod时，确定出的本地更新数，作为这一次更新的本次更新数，并再次指示Kubernetes系统对需要更新的Pod进行更新。

在实际应用中，进行多次分批更新后，未更新的Pod数量会越来越少，此时可能会出现确定出的本次更新数大于等于剩余未更新的Pod数，比如有10个需要更新的Pod，并以每3个Pod进行分批次更新，当经过3次更新、完成9个Pod更新后，还剩下1个未更新的Pod，这时本次更新数3则大于剩余未更新数1；又如，依旧有10个需要更新的Pod，并以每2个Pod进行分批次更新，当经过4次更新、完成8个Pod更新后，还剩下2个未更新的Pod，这时本次更新数2则等于剩余未更新数2。那么此时，便可以以本次更新数作为依据，来指示Kubernetes系统对剩余未更新的Pod进行更新。

所以在一种实施方式中，根据确定出的本次更新数，再次指示Kubernetes系统对所述需要更新的Pod进行更新，可以包括：根据本次更新数，指示Kubernetes系统对剩余未更新的Pod进行更新；如果本次更新数大于等于剩余未更新的Pod个数，那么当确定出已完成更新的Pod个数等于需要更新的Pod总个数时，则可以停止更新；如果本次更新数小于等于剩余未更新的Pod个数，那么当确定出本次完成更新的Pod个数等于本次更新数时，则可以暂停更新。

具体地，当接收到用户发送的继续更新请求后，可以以上一次更新时的本次更新数，作为下一次更新的依据，此时，可以基于本次更新数，指示Kubernetes系统对剩余未更新的Pod进行更新，那么若本次更新数大于等于剩余未更新的Pod个数时，则系统可以更新本次更新数的Pod，可以理解地，若本次更新数小于剩余未更新的Pod个数时，则系统可以将剩余未更新的Pod全部更新。

可以理解地，若全部更新完，则无需再进行更新，若未全部更新完，则还需要下一批次更新，所以在根据本次更新数，指示Kubernetes系统对剩余未更新的Pod进行更新后，则可以判断是否需要下一次更新。

所以，如果本次更新数大于等于剩余未更新的Pod个数，则有可能出现需要更新的Pod全部更新完的情况，那么此时，可以确定已完成更新的Pod个数是否等于需要更新的Pod总个数，若是，则可以表明需要更新的Pod全部更新完成，测试便可以停止更新。

如果本次更新数小于剩余未更新的Pod个数，则往往表明，还存在剩余未更新的Pod，那么此时，则可以执行类似于步骤208的操作，确定本次完成更新的Pod个数是否等于本次更新数，若是，则可以再暂停更新。

此后则可以再次执行步骤210，再次获取已完成更新的Pod对应的唯一标识，并发送给测试地址，以便对已完成更新的Pod进行测试。

如图3所示，为针对Kubernetes系统中Pod的更新方法的示意图。在实际的业务场景中，可以在Kubernetes系统外部创建一个Restful API、以及一个逻辑处理模块，而在Kubernetes系统中，可以开放对外的Kubernetes API，对外可以与逻辑处理模块进行交互，对内可以与Deployment进行交互，从而使得逻辑处理模块可以通过Kubernetes API与Deployment进行交互。

其中，Restful API作为应用接口，可以提供给用户，以便接收更新请求、反馈更新进度、反馈已完成更新的Pod的唯一标识等。逻辑处理模块，可以用于处理Restful API发送来的请求，通过与Kubernetes API进行交互，而实现对需要更新的Pod进行更新，还可以向Kubernetes API发送监听Deployment描述信息的指令，并决定是否需要暂停或停止，等。Deployment如前所述，可以用于管理Pod。

当Restful API接收到用户发送的更新请求后，可以发送至逻辑处理模块，该更新请求中可以包含用户需要的更新进度，当然还可以包含更新Pod所需的镜像地址。

逻辑处理模块可以通过设置spec.paused值为false，打开预先创建的更新开关。此后，可以根据更新进度、以及需要更新的Pod总个数，确定出本次更新数，并根据该本次更新数，通过指示Kubernetes API，控制Deployment对Pod进行更新。

此后，通过向Kubernetes API发送指令，监听Deployment的描述信息，根据返回的描述信息，确定本次完成更新的Pod数据是否等于本次更新数，若是则可以通过设置spec.paused值为true，关闭更新开关，从而暂停更新。再后，可以通过向Kubernetes API发送指令，获取已完成更新的Pod对应的IP地址，并返回给Restful API，以便测试人员可以根据IP地址，对已完成更新的Pod进行测试。

当Restful API再次接收到用户发送的继续更新请求后，再发送至逻辑处理模块。此时，逻辑处理模块可以根据上一次更新时的本次更新数，再次通过指示Kubernetes API，控制Deployment对剩余未更新的Pod进行更新。并再次通过监听Deployment的描述信息，关闭更新开关并暂停更新，此时，如果本次更新数小于剩余未更新的Pod个数，那么可以确定本次完成更新的Pod个数是否等于本次更新数，若是，则可以通过设置spec.paused值为true，关闭更新开关，从而暂停更新，以及返回已完成更新的Pod对应的IP地址。

当Restful API，又一次接收到用户发送的继续更新请求后，发送至逻辑处理模块，此时逻辑处理模块可以再次根据上一次更新时的本次更新数，通过指示KubernetesAPI，控制Deployment对剩余未更新的Pod进行更新。并再次通过监听Deployment的描述信息，关闭更新开关并暂停更新，此时，如果本次更新数大于等于剩余未更新的Pod个数，那么可以确定已完成更新的Pod个数是否等于需要更新的Pod总个数，若是，则可以通过设置spec.paused值为true并停止更新。

最后，还可以通过向Kubernetes API发送指令，获取已完成更新的Pod对应的IP地址，并返回给Restful API，以便测试人员可以根据IP地址，对已完成更新的Pod进行测试。

由以上实施例提供的技术方案可见，可以先接收用户发送的、包含更新进度的更新请求，从而可以根据更新进度确定出本次更新数，并指示Kubernetes系统对需要更新的Pod进行更新，当确定出本次完成后，则暂停更新，并获取已完成更新的Pod对应的唯一标识，以此发送给测试地址，以便对已完成更新的Pod进行测试。当再次接收到用户发送的继续更新请求后，则根据上一次确定出的本次更新数，再次指示Kubernetes系统对需要更新的Pod进行更新。在此后进行指示更新时，还可以根据本次更新数，指示对剩余未更新的Pod进行更新，并当确定出已完成更新的数量等于需要更新的数量时，停止更新。

可见，利用本实施例在对Kubernetes系统中的Pod进行更新时，可以根据用户的不同更新进度需求，分批次进行更新，在每次分批更新完后，暂停更新进度，并提供对更新结果的测试条件，以及在更新完成后，可以停止更新。

由于可以根据用户的需求，对Pod进行分批次更新，并在每次更新后进行暂停、测试，以及在更新完成后进行停止、测试，所以便可以在对Kubernetes系统中的Pod进行更新的过程中，降低由更新而导致的业务故障风险，从而尽量保障业务的高可用性。

实施例3

基于相同的构思，本说明书实施例3提供了一种针对Kubernetes系统中Pod的更新装置，可以在对Kubernetes系统中需要更新的Pod进行更新的过程中，降低业务故障的风险，尽量保障业务的高可用性。该装置可以应用于终端，其结构示意图如图4所示，包括：更新指示单元302、更新控制单元304、以及测试返回单元306，其中，

更新指示单元302，可以用于根据预先确定出的针对Kubernetes系统中Pod的本次更新数，指示Kubernetes系统对需要更新的Pod进行更新，本次更新数小于需要更新的Pod总个数；

更新控制单元304，可以用于当确定出本次完成更新的Pod数量等于本次更新数时，则暂停更新；

测试返回单元306，可以用于获取已完成更新的Pod对应的唯一标识，并发送给测试地址，以便对已完成更新的Pod进行测试。

在一种实施方式中，该装置还包括更新数确定单元，可以用于：根据预先确定出的本次更新数，指示Kubernetes系统对需要更新的Pod进行更新之前，接收用户发送的、包含更新进度的更新请求；

根据更新进度、以及需要更新的Pod的总个数，确定本次更新数。

在一种实施方式中，更新指示单元302，还可以用于：

接收用户发送的继续更新请求；

根据本次更新数，再次指示Kubernetes系统对需要更新的Pod进行更新；

再次获取已完成更新的Pod对应的唯一标识，并发送给测试地址，以便对已完成更新的Pod进行测试。

在一种实施方式中，更新指示单元302，可以用于：

根据所述本次更新数，指示Kubernetes系统对剩余未更新的Pod进行更新；

如果本次更新数大于等于剩余未更新的Pod个数，当确定出已完成更新的Pod个数等于需要更新的Pod总个数时，则停止更新；

如果本次更新数小于剩余未更新的Pod个数，当确定出本次完成更新的Pod个数等于本次更新数时，则暂停更新。

由以上实施例提供的系统可见，针对Kubernetes系统中Pod，可以先根据预先确定出的、比需要更新的Pod总个数小的本次更新数，并指示Kubernetes系统对需要更新的Pod进行部分更新。当确定出本次更新完成后，则暂停更新，并获取已完成更新的Pod对应的唯一标识，以此发送给测试地址，以便对已完成更新的Pod进行测试。

可见，利用本实施例在对Kubernetes系统中的Pod进行更新时，可以分批次进行更新，在每次分批更新完后，暂停更新进度，并提供对更新结果的测试条件。由于可以对Pod进行分批次更新，并在每次更新后进行暂停、测试，所以便可以在对Kubernetes系统中的Pod进行更新的过程中，降低由更新而导致的业务故障风险，从而尽量保障业务的高可用性。

图5本说明书的实施例电子设备的结构示意图。在硬件层面，电子设备包括处理器，可选地还包括内部总线、网络接口、存储器。其中，存储器可能包含内存，例如高速随机存取存储器(Random-Access Memory，RAM)，也可能还包括非易失性存储器(non-volatilememory)，例如至少1个磁盘存储器等。当然，该电子设备还可能包括其他业务所需要的硬件。

处理器、网络接口和存储器可以通过内部总线相互连接，该内部总线可以是ISA(Industry Standard Architecture，工业标准体系结构)总线、PCI(PeripheralComponent Interconnect，外设部件互连标准)总线或EISA(Extended Industry StandardArchitecture，扩展工业标准结构)总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图5仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。

存储器，用于存放程序。具体地，程序可以包括程序代码，所述程序代码包括计算机操作指令。存储器可以包括内存和非易失性存储器，并向处理器提供指令和数据。

处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成针对Kubernetes系统中Pod的更新装置。处理器，执行存储器所存放的程序，并具体用于执行以下操作：

根据预先确定出的针对Kubernetes系统中Pod的本次更新数，指示Kubernetes系统对所述需要更新的Pod进行更新，所述本次更新数小于需要更新的Pod总个数；

当确定出本次完成更新的Pod数量等于所述本次更新数时，则暂停更新；

获取已完成更新的Pod对应的唯一标识，并发送给测试地址，以便对所述已完成更新的Pod进行测试。

上述如本说明书图4示实施例提供的针对Kubernetes系统中Pod的更新装置执行的方法可以应用于处理器中，或者由处理器实现。处理器可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器，包括中央处理器(CentralProcessing Unit，CPU)、网络处理器(Network Processor，NP)等；还可以是数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific IntegratedCircuit，ASIC)、现场可编程门阵列(Field－Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本说明书实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

结合本说明书实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。

该电子设备还可执行图4示实施例提供的针对Kubernetes系统中Pod的更新装置在图5示实施例的功能，本说明书实施例在此不再赘述。

本说明书实施例还提出了一种计算机可读存储介质，该计算机可读存储介质存储一个或多个程序，该一个或多个程序包括指令，该指令当被包括多个应用程序的电子设备执行时，能够使该电子设备执行图4示实施例中针对Kubernetes系统中Pod的更新装置执行的方法，并具体用于执行：

根据预先确定出的针对Kubernetes系统中Pod的本次更新数，指示Kubernetes系统对所述需要更新的Pod进行更新，所述本次更新数小于需要更新的Pod总个数；

当确定出本次完成更新的Pod数量等于所述本次更新数时，则暂停更新；

获取已完成更新的Pod对应的唯一标识，并发送给测试地址，以便对所述已完成更新的Pod进行测试。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。

为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本说明书时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

本领域内的技术人员应明白，本说明书的实施例可提供为方法、装置、或计算机程序产品。因此，本说明书可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本说明书可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本说明书是参照根据本说明书实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

以上所述仅为本说明书的实施例而已，并不用于限制本说明书。对于本领域技术人员来说，本说明书可以有各种更改和变化。凡在本说明书的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本文件的权利要求范围之内。

Claims (10)

1.一种针对Kubernetes系统中Pod的更新方法，其特征在于，包括：

根据预先确定出的针对Kubernetes系统中Pod的本次更新数，指示Kubernetes系统对需要更新的Pod进行更新，所述本次更新数小于需要更新的Pod总个数；

当确定出本次完成更新的Pod个数等于所述本次更新数时，则暂停更新；

获取已完成更新的Pod对应的唯一标识，并发送给测试地址，以便对所述已完成更新的Pod进行测试。

2.如权利要求1所述的方法，其特征在于，根据预先确定出的针对Kubernetes系统中Pod的本次更新数，指示Kubernetes系统对需要更新的Pod进行更新之前，所述方法还包括：

接收用户发送的、包含更新进度的更新请求；

根据所述更新进度、以及需要更新的Pod的总个数，确定本次更新数。

3.如权利要求2所述的方法，其特征在于，所述方法还包括：

接收用户发送的继续更新请求；

根据所述本次更新数，再次指示Kubernetes系统对所述需要更新的Pod进行更新；

再次获取已完成更新的Pod对应的唯一标识，并发送给测试地址，以便对所述已完成更新的Pod进行测试。

4.如权利要求3所述的方法，其特征在于，根据所述本次更新数，再次指示Kubernetes系统对所述需要更新的Pod进行更新，包括：

根据所述本次更新数，指示Kubernetes系统对剩余未更新的Pod进行更新；

如果所述本次更新数大于等于剩余未更新的Pod个数，当确定出已完成更新的Pod个数等于所述需要更新的Pod总个数时，则停止更新；

如果所述本次更新数小于剩余未更新的Pod个数，当确定出本次完成更新的Pod个数等于所述本次更新数时，则暂停更新。

5.一种针对Kubernetes系统中Pod的更新装置，其特征在于，包括：更新指示单元、更新控制单元、以及测试返回单元，其中，

所述更新指示单元，用于根据预先确定出的针对Kubernetes系统中Pod的本次更新数，指示Kubernetes系统对所述需要更新的Pod进行更新，所述本次更新数小于需要更新的Pod总个数；

所述更新控制单元，用于当确定出本次完成更新的Pod数量等于所述本次更新数时，则暂停更新；

所述测试返回单元，用于获取已完成更新的Pod对应的唯一标识，并发送给测试地址，以便对所述已完成更新的Pod进行测试。

6.如权利要求5所述的装置，其特征在于，所述装置还包括更新数确定单元，用于：根据预先确定出的本次更新数，指示Kubernetes系统对所述需要更新的Pod进行更新之前，

接收用户发送的、包含更新进度的更新请求；

根据所述更新进度、以及需要更新的Pod的总个数，确定本次更新数。

7.如权利要求6所述的装置，其特征在于，所述更新指示单元还用于：

接收用户发送的继续更新请求；

根据所述本次更新数，再次指示Kubernetes系统对所述需要更新的Pod进行更新；

再次获取已完成更新的Pod对应的唯一标识，并发送给测试地址，以便对所述已完成更新的Pod进行测试。

8.如权利要求7所述的装置，其特征在于，所述更新指示单元用于：

根据所述本次更新数，指示Kubernetes系统对剩余未更新的Pod进行更新；

如果所述本次更新数大于等于剩余未更新的Pod个数，当确定出已完成更新的Pod个数等于所述需要更新的Pod总个数时，则停止更新；

如果所述本次更新数小于等于剩余未更新的Pod个数，当确定出本次完成更新的Pod个数等于所述本次更新数时，则暂停更新。

9.一种电子设备，所述电子设备应用于应用服务端，包括：

处理器；以及

被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器执行以下操作：

根据预先确定出的针对Kubernetes系统中Pod的本次更新数，指示Kubernetes系统对所述需要更新的Pod进行更新，所述本次更新数小于需要更新的Pod总个数；

当确定出本次完成更新的Pod数量等于所述本次更新数时，则暂停更新；

获取已完成更新的Pod对应的唯一标识，并发送给测试地址，以便对所述已完成更新的Pod进行测试。

10.一种计算机可读存储介质，应用于应用服务端，所述计算机可读存储介质存储一个或多个程序，所述一个或多个程序当被包括多个应用程序的电子设备执行时，使得所述电子设备执行以下操作：

根据预先确定出的针对Kubernetes系统中Pod的本次更新数，指示Kubernetes系统对所述需要更新的Pod进行更新，所述本次更新数小于需要更新的Pod总个数；

当确定出本次完成更新的Pod数量等于所述本次更新数时，则暂停更新；

获取已完成更新的Pod对应的唯一标识，并发送给测试地址，以便对所述已完成更新的Pod进行测试。

Images