CN111258609A

CN111258609A - Kubernetes集群的升级方法、装置、电子设备和介质

Info

Publication number: CN111258609A
Application number: CN202010060408.3A
Authority: CN
Inventors: 郭良帅
Original assignee: Beijing Baidu Netcom Science and Technology Co Ltd
Current assignee: Beijing Baidu Netcom Science and Technology Co Ltd
Priority date: 2020-01-19
Filing date: 2020-01-19
Publication date: 2020-06-09
Anticipated expiration: 2040-01-19
Also published as: CN111258609B

Abstract

本申请公开了一种Kubernetes集群的升级方法、装置、设备和介质，涉及计算机技术领域，尤其是云计算技术领域。具体实现方案为：通过接口服务器，从控制管理器获取旧应用实例的删除请求和新副本集信息；其中所述删除请求和新副本集信息在检测到任一部署组的容器镜像字段更新时确定；确定旧应用实例所属的目标部署组是否需要原地升级；若需要原地升级，则根据新副本集信息将所述旧应用实例升级为新副本集中的新应用实例，以对目标部署组进行升级；拒绝所述删除请求。采用本申请的方案，能够实现对旧应用实例Pod进行原地升级，保证新旧Pod的附加属性信息相同，避免后续的访问发生异常。

Description

Kubernetes集群的升级方法、装置、电子设备和介质

技术领域

本申请实施例涉及计算机技术领域，尤其涉及云计算技术领域的一种Kubernetes集群的升级方法、装置、设备和介质。

背景技术

Kubernetes(简称K8S)集群是一个开源的，用于管理云平台中多个主机上容器化应用的容器编排管理平台，提供了应用部署，规划，更新，维护的一种机制。

K8S集群中的Deployment(部署组)支持Pod(应用实例)的两种升级模式：RollingUpdate(滚动升级模式)和RecreateUpdate(重建升级模式)。无论哪种升级模式，部署组都会删除旧Pod，创建新Pod。

然而，Pod本身具有诸如IP地址、存储空间和设备信息之类的附加属性信息，现有升级模式创建的新Pod与旧Pod的附加属性信息不同，导致访问异常。

发明内容

本申请实施例公开一种Kubernetes集群的升级方法、装置、电子设备和介质，可以使得新旧Pod的附加属性信息相同，避免访问异常。

第一方面，本申请实施例公开了一种Kubernetes集群的升级方法，由Kubernetes集群中的升级管理器执行，所述方法包括：

通过接口服务器，从控制管理器获取旧应用实例的删除请求和新副本集信息；其中所述删除请求和所述新副本集信息在检测到任一部署组的容器镜像字段更新时确定；

确定所述旧应用实例所属的目标部署组是否需要原地升级；

若需要原地升级，则根据所述新副本集信息将所述旧应用实例升级为新副本集中的新应用实例，以对所述目标部署组进行升级；

拒绝所述删除请求。

上述申请中的一个实施例具有如下优点或有益效果：能够实现对旧应用实例Pod进行原地升级，保证新旧Pod的附加属性信息相同，避免后续的访问异常。

另外，根据本申请上述实施例的Kubernetes集群的升级方法方法，还可以具有如下附加的技术特征：

可选地，根据所述新副本集信息将所述旧应用实例升级为新副本集中的新应用实例，包括：

将旧应用实例的元数据中的所有者标识，更新为新副本集的标识；

将旧应用实例的元数据中的模板哈希，更新为新副本集的哈希；

将旧应用实例的镜像名称字段更新为新副本集的镜像名称字段，以将所述旧应用实例升级为新应用实例。

上述申请中的一个实施例具有如下优点或有益效果：在Pod升级过程中，不需要删除旧Pod然后重新创建新Pod，只需通过将旧Pod变更为新Pod即可完成升级，能够保证新旧Pod的附加属性信息相同。

可选地，拒绝所述删除请求，包括：

在检测到新副本集的已有新应用实例数量达到新副本集的期望副本数时，拒绝所述删除请求。

上述申请中的一个实施例具有如下优点或有益效果：能够保证新副本集RS下的新应用实例数量达到新副本集的期望副本数的要求。

可选地，本申请实施例Kubernetes集群的升级方法，还包括：

通过接口服务器，从控制管理器获取新应用实例的创建请求；其中所述创建请求在检测到该部署组的容器镜像字段更新时确定；

确定所述旧应用实例所属的目标部署组是否需要原地升级；

若需要原地升级，则拒绝所述创建请求。

上述申请中的一个实施例具有如下优点或有益效果：能够在确定需要原地升级的情况下，阻止新应用实例Pod的重新创建，避免引起新旧Pod的附加属性信息发生不同。

可选地，确定旧应用实例所属的目标部署组是否需要原地升级，包括：

确定所述旧应用实例所属的旧副本集，并将所述旧副本集所属的部署组作为所述目标部署组；

确定所述目标部署组的元数据注解字段是否为原地升级；

若是，则确定所述目标部署组需要原地升级。

上述申请中的一个实施例具有如下优点或有益效果：能够在对Pod进行升级时，通过及时判断目标部署组是否需要进行原地升级，来确定对Pod的升级方式。

第二方面，本申请实施例中还公开了一种Kubernetes集群的升级装置，配置于Kubernetes集群中的升级管理器，所述装置包括：

删除信息获取模块，用于通过接口服务器，从控制管理器获取旧应用实例的删除请求和新副本集信息；其中所述删除请求和所述新副本集信息在检测到任一部署组的容器镜像字段更新时确定；

原地升级确定模块，用于确定所述旧应用实例所属的目标部署组是否需要原地升级；

目标升级模块，用于若需要原地升级，则根据所述新副本集信息将所述旧应用实例升级为新副本集中的新应用实例，以对所述目标部署组进行升级；

删除请求拒绝模块，用于拒绝所述删除请求。

第三方面，本申请实施例中还公开了一种电子设备，包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行本申请任意实施例中所提供的所述的Kubernetes集群的升级方法。

第四方面，本申请实施例中还公开了一种存储有计算机指令的非瞬时计算机可读存储介质，所述计算机指令用于使所述计算机执行本申请任意实施例中所提供的所述的Kubernetes集群的升级方法。

根据本申请提供的一种Kubernetes集群的升级方法，在通过接口服务器从控制管理器获取到旧应用实例的删除请求和新副本集信息后，会确定旧应用实例所属的目标部署组是否需要原地升级，进而将旧应用实例原地升级为新副本集中的新应用实例，能够实现对旧应用实例Pod进行原地升级，保证新旧Pod的附加属性信息相同，避免后续的访问发生异常。

上述可选方式所具有的其他效果将在下文中结合具体实施例加以说明。

附图说明

附图用于更好地理解本方案，不构成对本申请的限定。其中：

图1是根据本申请实施例一所提供的一种Kubernetes集群的升级方法的流程图；

图2是根据本申请实施例一所提供的一种Kubernetes集群的原地升级的架构示意图；

图3是根据本申请实施例一所提供的一种Kubernetes集群的原地升级的交互示意图；

图4是用来实现本申请实施例的Kubernetes集群的升级方法的Kubernetes集群的升级装置的结构框图；

图5是用来实现本申请实施例的Kubernetes集群的升级方法的电子设备的结构框图。

具体实施方式

以下结合附图对本申请的示范性实施例做出说明，其中包括本申请实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本申请的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

为了更好地理解本申请方案，下面针对本申请方案中将要出现的几个重要内容进行阐述。如下：Kubernetes集群是一种容器(应用程序的一种封装形式)编排管理平台。Pod应用实例是应用程序在K8S集群里运行的基本形式，一个Pod代表应用程序的一个实例。ReplicaSet副本集是Pod应用实例的抽象，Pod是ReplicaSet(简称RS)副本集的派生实例，RS的Replicas字段表示该RS需要有几个Pod。部署组Deployment定义了应用程序如何在K8S里部署和运行。

实施例一

图1是根据本申请实施例一所提供的一种Kubernetes集群的升级方法的流程图，本实施例可适用于对Kubernetes集群中Deployment(部署组)进行升级的情况。该方法可以由Kubernetes集群的升级装置来执行，该装置可以采用软件和/或硬件的方式实现，并集成在任何具有网络通信功能的电子设备上。

如图1所示，本申请实施例中提供的Kubernetes集群的升级方法，包括以下步骤：

S110、通过接口服务器，从控制管理器获取旧应用实例的删除请求和新副本集信息；其中删除请求和新副本集信息在检测到任一部署组的容器镜像字段更新时确定。

在本实施例中，图2是根据本申请实施例一所提供的一种Kubernetes集群的原地升级的架构示意图。参见图2，在Kubernetes集群中，通常会包括控制管理器ControllerManager、接口服务器APIServer和存储系统ETCD等。其中，各种控制流程一般是由控制管理器发起，然后通过HTTP请求提交给接口服务器，最终持久化到ETCD。控制管理器可负责业务逻辑的管理，包括：对Deployment部署组的管理、对RS副本集的管理以及对Pod应用实例的管理。

在本实施例中，在升级流程中，控制管理器可请求接口服务器删除指定应用实例和创建应用实例。图3是根据本申请实施例一所提供的一种Kubernetes集群的原地升级的交互示意图。参见图3，用户可根据需求对Kubernetes集群中任一部署组Deployment的容器镜像字段更新，比如，在需要进行应用镜像版本升级时，将版本由V1.1升级到V1.2，而控制管理器会对Kubernetes集群中任一部署组Deployment中的容器镜像字段进行监测，以检测部署组Deployment中的容器镜像字段是否发生更新。

在本实施例中，参见图3，若控制管理器检测到任一部署组Deployment的容器镜像字段发生更新，则将该容器镜像字段发生更新的部署组Deployment确定为新部署组Deployment。这样，控制管理器可基于新部署组的定义来创建新副本集，并根据需求缩减旧副本集的副本数(即，下辖应用实例Pod的数量)。其中，副本集的副本数可采用副本集RS的Replicas字段表示，其表示该RS所需应用实例Pod的个数。此时，控制管理器可根据要缩减的旧副本集的期望副本数，找到需要删除的多余的旧应用实例Pod，以此生成旧应用实例Pod的删除请求。

在一个可选示例中，如果需要缩减指定的一个或多个旧应用实例，控制管理器可从旧应用实例中选择指定一个或多个，并生成选择的旧应用实例的删除请求。可选地，在选择指定的一个或多个旧应用实例时，控制管理器可从随机选择一个或多个旧应用实例，也可按照旧应用实例中各个应用实例的性能大小选择一个或多个旧应用实例，用来生成删除请求。

在本实施例中，为了实现对Kubernetes集群中应用实例Pod的原地升级操作，可基于Kubernetes集群中的“Admission Control”机制，在Kubernetes集群中设置升级管理器的功能配置，以便通过升级管理器实现原地升级。参见图2和图3，控制管理器可将旧应用实例的删除请求向接口服务器发送，接口服务器接收控制管理器发送的旧应用实例的删除请求，并向升级管理器转发该旧应用实例的删除请求。可选地，接口服务器可根据基于“Admission Control”机制所配置的功能，将旧应用实例的删除请求向升级管理器转发。这样，升级管理器可通过接口服务器获取控制管理器生成的针对旧应用实例的删除请求。此外，控制管理器还可将生成的新副本集信息通过接口服务器转发给升级管理器。

在本实施例中，可选地，在使用Kubernetes集群中设置的升级管理器时，可针对升级管理器配置其管理的资源类型，例如应用实例Pod、副本集RS和部署组Deployment。可选地，在Kubernetes集群中，部署组Deployment支持两种升级模式，具体包括：RollingUpdate模式和RecreateUpdate模式，本申请方案在进行原地升级时，需要将部署组Deployment在RollingUpdate模式的基础上进行。

S120、确定旧应用实例所属的目标部署组是否需要原地升级。

在本实施例中，在Kubernetes集群中，应用实例Pod由部署组Deployment来进行管理。为此，当升级管理器接收到接口服务器转发的旧应用实例的删除请求后，可确定旧应用实例Pod所属的部署组Deployment，并作为目标部署组。进而，通过确定目标部署组是否支持进行原地升级，来确定是否对目标部署组管理的旧应用实例进行升级。

在本实施例的一种可选方式中，确定旧应用实例所属的目标部署组是否需要原地升级，可包括以下步骤A1-A2：

步骤A1、确定旧应用实例所属的旧副本集，并将旧副本集所属的部署组作为目标部署组。

在本实施方式中，在Kubernetes集群中，部署组Deployment管理应用实例Pod的过程，具体为部署组Deployment管理副本集RS，副本集RS管理应用实例Pod。为此，可选地，升级管理器可依据旧应用实例Pod的OwnerReference字段查找出其上游的旧副本集RS，然后通过该旧副本集RS的OwnerReference字段查找出其上游的部署组Deployment，并作为目标部署组。这样，就可得到旧应用实例所属的目标部署组。

步骤A2、确定目标部署组的元数据注解字段是否为原地升级；若是，则确定目标部署组需要原地升级。

在本实施方式中，在Kubernetes集群中，对于需要“原地升级”的部署组Deployment，可在部署组Deployment的元数据注解(例如metadata.annotation)字段中预先标记“in-place-update:true”，即需要原地升级的意思。在确定旧应用实例所属的目标部署组后，可解析该目标部署组的元数据注解字段里是否有“in-place-update:true”标记。如果有上述标记，则确定目标部署组需要原地升级；否则，确定目标部署组不需要原地升级。采用上述方式的好处在于，能够在对应用实例Pod进行升级时，通过及时判断目标部署组是否需要进行原地升级，来确定是否对Pod进行升级，以便保证新旧Pod的附加属性信息相同。

S130、若需要原地升级，则根据新副本集信息将旧应用实例升级为新副本集中的新应用实例，以对目标部署组进行升级；以及，拒绝该删除请求。

在本实施例中，若确定需要对目标部署组进行原地升级，则根据新副本集信息的期望副本数与已有新应用实例数量，将将旧应用实例升级为新副本集中的新应用实例，这样即可实现对目标部署组的升级。若确定不需要对目标部署组进行原地升级，升级管理器可允许接口服务器执行上述旧应用实例的删除请求，进行旧应用实例Pod的删除操作。

在本实施例中，在确定需要原地升级后，升级管理器可依据目标部署组Deployment的新副本集的期望副本数与新副本集的已有新应用实例数量，检测新副本集的已有新应用实例数量是否已经达到新副本集的期望副本数。新副本集的期望副本数可用于描述需要进行原地升级的应用实例Pod的数量。例如，升级管理器可判断目标部署组Deployment的新副本集的Replicas字段指示的副本数是否与新副本集的已有新应用实例数量一致。

在本实施例中，若检测到新副本集的已有新应用实例数量未达到新副本集的期望副本数，则将旧应用实例在原地升级为新副本集中的新应用实例。其中，对应用实例Pod的原地升级是指应用实例Pod在升级过程中不会被删除然后重新创建，而是在原地重建，且在原地升级后新应用实例Pod与旧应用实例Pod的附加属性信息相同。应用实例Pod的附加属性信息包括IP地址、存储空间和设备信息之类的信息等。若检测到新副本集的已有新应用实例数量达到新副本集的期望副本数，升级管理器可拒绝旧应用实例的删除请求。

在本实施例中，参见图3，若确定需要对目标部署组进行原地升级且进行了原地升级，则升级管理器向接口服务器回复拒绝上述旧应用实例的删除请求，不允许接口服务器执行上述旧应用实例的删除请求，因为此时升级管理器已经对旧应用实例进行原地升级，且将原地升级后的新应用实例归属到新副本集名下。

在本实施例的一种可选方式中，根据新副本集信息将旧应用实例升级为新副本集中的新应用实例，可包括以下步骤B1-B3：

步骤B1、将旧应用实例的元数据中的所有者标识，更新为新副本集的标识。

在本实施方式中，升级管理器可对旧应用实例的元数据中的所有者标识字段的取值进行更改，例如，可将旧应用实例Pod的元数据中的元数据所有者指针metadata.ownerReference字段的取值更新为新副本集的标识。

步骤B2、将旧应用实例的元数据中的模板哈希，更新为新副本集的哈希。

在本实施方式中，升级管理器可对旧应用实例的元数据中的模板哈希字段的取值进行更改，例如，将将旧应用实例Pod的Pod模板摘要metadata.labels.pod-template-hash字段的取值更改为新副本集的哈希；

步骤B3、将旧应用实例的镜像名称字段更新为新副本集的镜像名称字段，以将旧应用实例升级为新应用实例。

在本实施方式中，升级管理器可对旧应用实例的镜像名称字段，比如spec.containers[*].image字段，更改为新副本集RS的镜像名称字段，比如spec.template.containers[*].image。这一更新方式，是应用实例pod的属性而不是升级必须的。

采用本申请方案的上述方式，可以保证在对旧应用实例Pod进行升级时，只对特定字段进行更新而不会对旧应用实例Pod附加的属性信息进行更改，即只需通过将旧Pod变更为新Pod即可完成升级，这样可保证升级后得到的新应用实例Pod与旧应用实例Pod的附加属性信息保持一致，以防由于属性信息发生改变导致出现访问异常。

根据本申请提供的一种Kubernetes集群的升级方法，在通过接口服务器从控制管理器获取到旧应用实例的删除请求和新副本集信息后，会确定旧应用实例所属的目标部署组是否需要原地升级，并且在将旧应用实例原地升级为新副本集中的新应用实例时，能够实现对旧应用实例Pod进行原地升级，新应用实例的IP地址和设备信息仍然沿用旧应用实例IP地址和设备信息，保证新旧Pod的附加属性信息相同。这样，当新应用实例访问下游应用(例如数据库)时是基于IP白名单访问，不会因为IP变化而被拒绝访问，可避免后续的访问发生异常。同时，由于新应用实例的IP地址和设备信息未发生变化，那么就能避免因为新应用实例的IP地址和设备信息发生变化所造成的流量在Pod间的分配就不会有短时间的不均衡的现象，从而就可尽量避免导致发生部分Pod没流量而部分Pod因为流量过大被压垮的问题。

在上述实施例的基础上，可选地，本申请实施例中提供的Kubernetes集群的升级方法，还包括以下步骤C1-C2：

步骤C1、通过接口服务器，从控制管理器获取新应用实例的创建请求；其中创建请求在检测到该部署组的容器镜像字段更新时确定。

在本实施例中，当控制管理器检测到该部署组的容器镜像字段更新时，控制管理器可根据新副本集增加新副本集的副本数，即增加新副本集的下辖的应用实例Pod的数量，以便保证创建的新Pod数量能够与新副本集RS的期望副本数(即Replicas)一致。此时，控制管理器可根据要增加的新副本集的期望副本数，生成用于增加新应用实例Pod的创建请求，以便增加新副本集的下辖的应用实例Pod的数量。

在本实施例中，参见图2和图3，控制管理器可将新应用实例的创建请求向接口服务器发送，接口服务器接收控制管理器发送的新应用实例的创建请求，并向升级管理器转发该新应用实例的创建请求。这样，升级管理器可通过接口服务器获取控制管理器生成的新应用实例的创建请求。

步骤C2、确定旧应用实例所属的目标部署组是否需要原地升级；若需要原地升级，则拒绝创建请求。

在本实施例中，与前述确定目标部署组是否需要原地升级的过程相同，可确定目标部署组是否需要原地升级。若确定旧应用实例所属的目标部署组需要原地升级，则升级管理器向接口服务器回复拒绝创建请求，不允许接口服务器执行创建操作。因为既然目标部署组需要原地升价，那么表明升级管理器在前述过程已经对旧应用实例进行原地升级，且将原地升级后的新应用实例归属到新副本集名下，因此这里不再重新创建，这样可以避免新创建的应用实例Pod的附件属性信息与旧应用实例Pod的附件属性信息不一致，从而导致后续新创建的应用实例Pod进行访问下游应用时出现访问异常。可见，采用本申请上述方式，能够在确定需要原地升级的情况下，阻止新应用实例Pod的重新创建，避免引起新旧Pod的附加属性信息发生不同，从而导致后续新Pod访问下游应用时出现访问异常。

在本实施例中，可选地，对于控制管理器而言，无论是新应用实例Pod的增加，还是旧应用实例Pod的缩减，都不会是一步到位的，而是逐次进行的。例如，对于旧应用实例Pod，每次缩减10％，多次缩减之后才会完全清理掉旧应用实例Pod。并且，控制管理器对旧应用实例Pod的缩减操作与对新应用实例Pod的增加操作是并发执行的，例如一共需要变更10个Pod，每次变更1个。

实施例二

图4是用来实现本申请实施例的Kubernetes集群的升级方法的Kubernetes集群的升级装置的结构框图，本实施例可适用于对Kubernetes集群中Deployment(部署组)进行升级的情况。该装置可以采用软件和/或硬件的方式实现，并集成在任何具有网络通信功能的电子设备上。

如图4所示，本申请实施例中提供的Kubernetes集群的升级装置400具体包括：删除信息获取模块410、原地升级确定模块420、目标升级模块430和删除请求拒绝模块440。其中：

删除信息获取模块410，用于通过接口服务器，从控制管理器获取旧应用实例的删除请求和新副本集信息；其中所述删除请求和所述新副本集信息在检测到任一部署组的容器镜像字段更新时确定；

原地升级确定模块420，用于确定所述旧应用实例所属的目标部署组是否需要原地升级；

目标升级模块430，用于若需要原地升级，则根据所述新副本集信息将所述旧应用实例升级为新副本集中的新应用实例，以对所述目标部署组进行升级；

删除请求拒绝模块440，用于拒绝所述删除请求。

在上述实施例的基础上，可选地，目标升级模块430包括：

在上述实施例的基础上，可选地，删除请求拒绝模块430包括：

在上述实施例的基础上，可选地，所述装置还包括：

创建信息获取模块450，用于通过接口服务器，从控制管理器获取新应用实例的创建请求；其中所述创建请求在检测到该部署组的容器镜像字段更新时确定；

原地升级确定模块420，还用于确定所述旧应用实例所属的目标部署组是否需要原地升级；

创建请求拒绝模块460，还用于若需要原地升级，则拒绝所述创建请求。

在上述实施例的基础上，可选地，原地升级确定模块420包括：

确定所述目标部署组的元数据注解字段是否为原地升级；

若是，则确定所述目标部署组需要原地升级。

本申请实施例中所提供的Kubernetes集群的升级装置可执行上述本申请任意实施例中所提供的Kubernetes集群的升级方法，具备执行该Kubernetes集群的升级方法相应的功能和有益效果，未在上述实施例中详尽描述的技术细节，可参见本申请任意实施例中所提供的Kubernetes集群的升级方法。

实施例三

根据本申请的实施例，本申请还提供了一种电子设备和一种可读存储介质。图5是用来实现本申请实施例的Kubernetes集群的升级方法的电子设备的结构框图。

如图5所示，是根据本申请实施例的Kubernetes集群的升级方法的电子设备的框图。电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本申请的实现。

如图5所示，该电子设备包括：一个或多个处理器501、存储器502，以及用于连接各部件的接口，包括高速接口和低速接口。各个部件利用不同的总线互相连接，并且可以被安装在公共主板上或者根据需要以其它方式安装。处理器可以对在电子设备内执行的指令进行处理，包括存储在存储器中或者存储器上以在外部输入/输出装置(诸如，耦合至接口的显示设备)上显示GUI的图形信息的指令。在其它实施方式中，若需要，可以将多个处理器和/或多条总线与多个存储器和多个存储器一起使用。同样，可以连接多个电子设备，各个设备提供部分必要的操作(例如，作为服务器阵列、一组刀片式服务器、或者多处理器系统)。图5中以一个处理器501为例。

存储器502即为本申请所提供的非瞬时计算机可读存储介质。其中，所述存储器存储有可由至少一个处理器执行的指令，以使所述至少一个处理器执行本申请所提供的Kubernetes集群的升级的方法。本申请的非瞬时计算机可读存储介质存储计算机指令，该计算机指令用于使计算机执行本申请所提供的Kubernetes集群的升级的方法。

存储器502作为一种非瞬时计算机可读存储介质，可用于存储非瞬时软件程序、非瞬时计算机可执行程序以及模块，如本申请实施例中的Kubernetes集群的升级的方法对应的程序指令/模块(例如，附图4所示的删除信息获取模块410、原地升级确定模块420、目标升级模块430和删除请求拒绝模块440)。处理器501通过运行存储在存储器502中的非瞬时软件程序、指令以及模块，从而执行服务器的各种功能应用以及数据处理，即实现上述方法实施例中的Kubernetes集群的升级的方法。

存储器502可以包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需要的应用程序；存储数据区可存储根据Kubernetes集群的升级方法的电子设备的使用所创建的数据等。此外，存储器502可以包括高速随机存取存储器，还可以包括非瞬时存储器，例如至少一个磁盘存储器件、闪存器件、或其他非瞬时固态存储器件。在一些实施例中，存储器502可选包括相对于处理器501远程设置的存储器，这些远程存储器可以通过网络连接至Kubernetes集群的升级方法的电子设备。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

Kubernetes集群的升级的方法的电子设备还可以包括：输入装置503和输出装置504。处理器501、存储器502、输入装置503和输出装置504可以通过总线或者其他方式连接，图5中以通过总线连接为例。

输入装置503可接收输入的数字或字符信息，以及产生与Kubernetes集群的升级方法的电子设备的用户设置以及功能控制有关的键信号输入，例如触摸屏、小键盘、鼠标、轨迹板、触摸板、指示杆、一个或者多个鼠标按钮、轨迹球、操纵杆等输入装置。输出装置504可以包括显示设备、辅助照明装置(例如，LED)和触觉反馈装置(例如，振动电机)等。该显示设备可以包括但不限于，液晶显示器(LCD)、发光二极管(LED)显示器和等离子体显示器。在一些实施方式中，显示设备可以是触摸屏。

此处描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、专用ASIC(专用集成电路)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。

这些计算程序(也称作程序、软件、软件应用、或者代码)包括可编程处理器的机器指令，并且可以利用高级过程和/或面向对象的编程语言、和/或汇编/机器语言来实施这些计算程序。如本文使用的，术语“机器可读介质”和“计算机可读介质”指的是用于将机器指令和/或数据提供给可编程处理器的任何计算机程序产品、设备、和/或装置(例如，磁盘、光盘、存储器、可编程逻辑装置(PLD))，包括，接收作为机器可读信号的机器指令的机器可读介质。术语“机器可读信号”指的是用于将机器指令和/或数据提供给可编程处理器的任何信号。

为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置(例如，CRT(阴极射线管)或者LCD(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。

可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(LAN)、广域网(WAN)、互联网和区块链网络。

计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。

根据本申请实施例的技术方案，本申请提供的一种Kubernetes集群的升级方法，在通过接口服务器从控制管理器获取到旧应用实例的删除请求和新副本集信息后，会确定旧应用实例所属的目标部署组是否需要原地升级，进而将旧应用实例原地升级为新副本集中的新应用实例，能够实现对旧应用实例Pod进行原地升级，保证新旧Pod的附加属性信息相同，避免后续的访问发生异常。

应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本发申请中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本申请公开的技术方案所期望的结果，本文在此不进行限制。

上述具体实施方式，并不构成对本申请保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本申请的精神和原则之内所作的修改、等同替换和改进等，均应包含在本申请保护范围之内。

Claims

1.一种Kubernetes集群的升级方法，其特征在于，由Kubernetes集群中的升级管理器执行，所述方法包括：

确定所述旧应用实例所属的目标部署组是否需要原地升级；

拒绝所述删除请求。

2.根据权利要求1所述的方法，其特征在于，根据所述新副本集信息将所述旧应用实例升级为新副本集中的新应用实例，包括：

3.根据权利要求1所述的方法，其特征在于，拒绝所述删除请求，包括：

4.根据权利要求1所述的方法，其特征在于，所述方法还包括：

确定所述旧应用实例所属的目标部署组是否需要原地升级；

若需要原地升级，则拒绝所述创建请求。

5.根据权利要求1或4所述的方法，其特征在于，确定所述旧应用实例所属的目标部署组是否需要原地升级，包括：

确定所述目标部署组的元数据注解字段是否为原地升级；

若是，则确定所述目标部署组需要原地升级。

6.一种Kubernetes集群的升级装置，其特征在于，配置于Kubernetes集群中的升级管理器，所述装置包括：

删除请求拒绝模块，用于拒绝所述删除请求。

7.根据权利要求6所述的装置，其特征在于，目标升级模块包括：

8.根据权利要求6所述的装置，其特征在于，删除请求拒绝模块包括：

9.根据权利要求6所述的装置，其特征在于，所述装置还包括：

创建信息获取模块，用于通过接口服务器，从控制管理器获取新应用实例的创建请求；其中所述创建请求在检测到该部署组的容器镜像字段更新时确定；

原地升级确定模块，还用于确定所述旧应用实例所属的目标部署组是否需要原地升级；

创建请求拒绝模块，用于若需要原地升级，则拒绝所述创建请求。

10.根据权利要求6或9所述的装置，其特征在于，原地升级确定模块包括：

确定所述目标部署组的元数据注解字段是否为原地升级；

若是，则确定所述目标部署组需要原地升级。

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

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行权利要求1-5中任一项所述的Kubernetes集群的升级方法。

12.一种存储有计算机指令的非瞬时计算机可读存储介质，其特征在于，所述计算机指令用于使所述计算机执行权利要求1-5中任一项所述的Kubernetes集群的升级方法。