一种跨版本升级方法、装置及电子设备与流程

本申请涉及集群部署技术领域，尤其涉及一种跨版本升级方法、装置及电子设备。

背景技术：

kubernetes是开源的一个容器编排工具，其社区活跃度非常高，这样，使得kubernetes版本(本申请统称版本)迭代周期较快，通常是每三个月发布一个正式版本，并且社区仅支持相邻版本的升级。

基于此，针对一些使用kubernetes的项目，可能由于这些项目自身版本的发布周期长于kubernetes版本更新的发布周期，也可能基于布置在kubernetes上各应用的功能稳定性方面的考虑，不会随着kubernetes版本的更新，频繁升级项目所使用的当前版本，由此，导致项目所使用的当前版本落后于社区所使用的版本多个版本，为了不落后于社区所使用的版本，按照社区当前仅支持相邻版本的升级，需要对项目所使用的当前版本进行逐版本升级，以使项目所使用的当前版本经过多个中间版本后升级到社区所使用的版本。

然而，在版本升级过程中，需要对各个中间版本进行逐个测试以保证这些中间版本的kubernetes在业务场景中功能也是正常的，这样，不仅会增大测试工作量，还会造成版本升级的复杂度。

技术实现要素：

有鉴于此，本申请提供一种跨版本升级方法、装置及电子设备，以在降低测试工作量的同时，降低版本升级的复杂度。

基于此，本申请是通过如下技术方案实现的：

第一方面，本申请实施例提供一种跨版本升级方法，该方法应用于管理节点，包括：

从已部署第一kubernetes版本的所有节点中选择一个待升级的主节点；所述第一kubernetes版本的kubernetes包括具有所述第一kubernetes版本的用于数据存储的存储组件和位于控制层的控制组件；

控制所述主节点的存储组件进行版本升级，以使所述存储组件的版本升级为目标版本；

在将所述存储组件的版本升级为目标版本后，再控制所述主节点的所述控制组件进行版本升级，以使所述控制组件的版本升级为目标版本。

本申请的一个实施例中，所述kubernetes还包括位于控制层中具有所述第一kubernetes版本的负载均衡组件，所述控制所述主节点的控制组件进行版本升级，包括：

若所述控制组件为负载均衡组件，则依据已配置的用于负载均衡组件升级的升级指令信息，控制所述负载均衡组件的版本升级，以使所述负载均衡组件的版本升级为目标版本；

若所述控制组件不为负载均衡组件，则依据已配置的控制组件的配置文件对控制组件进行升级，以使所述控制组件的版本升级为目标版本。

本申请的一个实施例中，所述kubernetes还包括位于控制层中具有第一kubernetes版本的第三方应用插件，在控制主节点的控制组件进行版本升级时，该方法还包括：

依据已配置的用于第三方应用插件升级的升级指令信息，控制第三方应用插件进行版本升级，以使所述第三方应用插件的版本均升级为目标版本。

本申请的一个实施例中，所述kubernetes还包括部署在主节点中待升级的第三方应用插件和部署在从节点中节点端代理控制组件，在所述控制组件的版本升级至目标版本后，该方法进一步包括：

检查部署所述第一kubernetes版本的节点中是否还存在未升级的主节点，如果是，选择一个待升级的主节点，并返回控制所述主节点的控制组件进行版本升级的步骤；如果否，

检查部署所述第一kubernetes版本的节点中是否存在待升级的从节点，

当存在从节点时，选择一个待升级的从节点，依据已配置的用于节点端代理控制组件升级的升级指令信息，控制所述节点端代理控制组件进行版本升级，以使所述节点端代理控制组件的版本升级为目标版本，并返回检查部署第一kubernetes版本的节点中是否存在待升级的从节点的步骤；

当不存在从节点时，依据已配置的用于所述第三方应用插件升级的升级指令信息，控制部署所述第一kubernetes版本的主节点中待升级的第三方应用插件进行版本升级，以使所述第三方应用插件的版本升级为目标版本。

本申请的一个实施例中，部署kubernetes的任一节点上的控制组件通过ga的v1接口与外部进行通信。

本申请的一个实施例中，在所述控制所述主节点中用于数据存储的存储组件进行版本升级之前，或，在所述控制从节点中的节点端代理控制组件进行版本升级之前，进一步包括：

依据所述目标版本对应的kubernetes资源号检查所述目标版本是否支持所述第一kubernetes版本已有的各第三方应用对应的应用资源，若所述目标版本不支持所述第一kubernetes版本已部署的至少一个第三方应用对应的应用资源，则删除所述至少一个应用对应的应用资源。

第二方面，本申请实施例还提供一种跨版本升级装置，该装置应用于管理节点，包括：

节点选择单元，用于从已部署第一kubernetes版本的所有节点中选择一个待升级的主节点，所述第一kubernetes版本的kubernetes包括具有所述第一kubernetes版本的用于数据存储的存储组件和位于控制层的控制组件；

存储组件升级单元，用于控制所述主节点的存储组件进行版本升级，以使所述存储组件的版本升级为目标版本；

控制组件升级单元，用于在将所述存储组件的版本升级为目标版本后，再控制所述主节点的控制组件进行版本升级，以使所述控制组件的版本升级为目标版本。

本申请的一个实施例中，所述kubernetes还包括位于控制层中具有所述第一kubernetes版本的负载均衡组件，所述控制组件升级单元，具体用于执行：

若所述控制组件为所述负载均衡组件，则依据已配置的用于负载均衡组件升级的升级指令信息，控制所述负载均衡组件的版本升级，以使所述负载均衡组件的版本升级为目标版本；

若所述控制组件不为所述负载均衡组件，则依据已配置的控制组件的配置文件对控制组件进行升级，以使所述控制组件的版本升级为目标版本。

本申请的一个实施例中，所述kubernetes还包括部署在主节点中待升级的第三方应用插件升级和部署在从节点中节点端代理控制组件升级的升级，所述装置还包括：

检查单元，用于检查部署所述第一kubernetes版本的节点中是否还存在未升级的主节点，如果是，触发主节点选择单元，如果否，触发从节点检查单元；

所述主节点选择单元，用于选择一个待升级的主节点作为主节点，并触发所述控制组件升级单元；

所述从节点检查单元，用于检查部署所述第一kubernetes版本的节点中是否存在待升级的从节点，当存在从节点时，触发从节点选择单元；当不存在从节点时，触发插件升级单元；

所述从节点选择单元，用于选择一个待升级的从节点，依据已配置的用于节点端代理控制组件升级的升级指令信息，控制所述节点端代理控制组件进行版本升级，以使所述节点端代理控制组件的版本升级为目标版本，并触发所述从节点检查单元；当不存在从节点时，触发插件升级单元；

所述插件升级单元，用于依据已配置的用于所述第三方应用插件升级的升级指令信息，控制部署第一kubernetes版本的主节点中待升级的第三方应用插件进行版本升级，以使所述第三方应用插件的版本升级为目标版本。

第三方面，本申请实施例还提供了一种电子设备，该电子设备包括：处理器和存储器；

所述存储器，用于存储机器可执行指令；

所述处理器，用于读取并执行所述存储器存储的机器可执行指令，以实现上述任一实施例所述的跨版本升级方法。

由以上技术方案可以看出，本申请实施例中，管理节点通过控制主节点中的存储组件进行版本升级，以使存储组件的版本升级为目标版本；在将存储组件的版本升级为目标版本后，再控制主节点中处于控制层的控制组件进行版本升级，以使控制组件的版本升级为目标版本。可见，只需要引入目标版本的kubernetes即可，不需要引入多个中间版本的kubernetes，这样就不需要对各个中间版本进行测试以确定这些中间版本的kubernetes在业务场景中功能是否正常。可见，应用本申请实施例能够在降低测试工作量的同时，降低版本升级的复杂度。

附图说明

图1为现有技术提供的一种版本升级方法的流程图；

图2为本申请实施例提供的一种跨版本升级方法的流程示意图；

图3为本申请实施例提供的一种示例性的实现步骤230的流程示意图；

图4为本申请实施例提供的另一种跨版本升级方法的流程示意图；

图5为本申请实施例提供的一种示例性的kubernetes的结构示意图；

图6为本申请实施例提供的一种基于本申请的跨版本升级方法进行升级后的kubernetes的结构示意图；

图7为本申请实施例提供的一种跨版本升级装置的结构示意图；

图8为本申请实施例提供的一种电子设备的结构示意图。

具体实施方式

在本申请实施例使用的术语仅仅是出于描述特定实施例的目的，而非限制本申请。本申请和权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其它含义。还应当理解，本文中使用的术语“和/或”是指包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请实施例可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，此外，所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

kubernetes是一种以集群模式部署的容器编排工具，其社区仅支持相邻版本的升级，并不提供成熟跨多个版本的升级方案，基于此，现有技术针对需要跨版本升级kubernetes的场景中，提供的一种可行的升级方案是逐版本的升级，例如：如图1所示，先将kubernetes的版本v1.11升级至版本v1.12，再从版本v1.12升级至版本v1.13，以此类推，最终升级至目标版本即版本v1.15，这样升级结束。

可见，按照上述现有技术提供的升级方案，需要经过多个中间版本后才能够升级到待要升级的目标版本，而在升级的过程中，还需要对各个中间版本进行逐个测试以保证这些中间版本的kubernetes在业务场景中功能也是正常的，这样，不仅会增大测试工作量，还会造成版本升级的复杂度。为了解决这一技术问题，本申请实施例提供了一种跨版本升级方法、装置及电子设备。

本申请的一个实施例中，提供了一种跨版本升级方法，该方法应用于管理节点，该方法包括：从已部署第一kubernetes版本的所有节点中选择一个待升级的主节点，上述第一kubernetes版本的kubernetes包括具有所述第一kubernetes版本的用于数据存储的存储组件和位于控制层的控制组件；控制所述主节点的所述存储组件进行版本升级，以使所述存储组件的版本升级为目标版本；在将存储组件的版本升级为目标版本后，再控制主节点的所述控制组件进行版本升级，以使控制组件的版本升级为目标版本。

由以上可见，应用本申请实施例提供的技术方案在遇到跨版本升级的场景中，只需要引入目标版本的kubernetes即可，不需要引入多个中间版本的kubernetes，这样就不需要对各个中间版本进行测试以确定这些中间版本的kubernetes在业务场景中功能是否正常。可见，应用本申请实施例能够在降低测试工作量的同时，降低版本升级的复杂度。

参见图2，图2为本申请实施例提供的一种跨版本升级方法的流程示意图，该方法应用于管理节点，在本申请中，部署kubernetes的节点可以包括至少一个主节点(master)，也可以包括至少一个主节点和各主节点管理的从节点(worker)，本申请中的管理节点可以从部署kubernetes的所有节点中选择一个主节点作为管理节点，也可以从部署kubernetes的所有节点中选择一个从节点作为管理节点，还可以专门设置一个独立于主节点和从节点之外的节点作为管理节点，并实施例对此并不限定。

如图2所示，该流程可以包括如下步骤：

步骤210，从已部署第一kubernetes版本的所有主节点中选择一个待升级的主节点，上述第一kubernetes版本的kubernetes可以包括具有所述第一kubernetes版本的用于数据存储的存储组件和位于控制层的控制组件。

在本申请中，第一kubernetes版本，并不特指某个固定的kubernetes版本，而是指部署在节点上未进行版本升级的任一kubernetes版本，本发明实施例后续不再复述。

作为一个实施例，实现上述步骤201的实现方式可以是依据已配置好的待主节点的节点名单，从已部署第一kubernetes版本的所有主节点中选择一个待升级的主节点。该节点名单可以仅包括待升级的主节点，也可以包括待升级的主节点和待升级的从节点，本实施例对此并不限定。

步骤220，控制主节点的存储组件进行版本升级，以使存储组件的版本升级为目标版本。

在本申请中，目标版本为已经对第一kubernetes版本进行版本升级后的最终版本。

在本申请中，各主节点均被部署有存储组件，针对一个主节点，该主节点中的存储组件可以存储该主节点中与kubernetes相关的数据，该存储组件可以是etcd组件。存储组件可以按照如下两种情况被部署在主节点中：一种情况是，针对每一主节点，该主节点的存储组件可以作为一个容器被部署在该主节点的控制层中。另一种情况是，针对每一主节点，该主节点的存储组件作为数据库的进程独立于控制层外，并运行在该主节点上。基于上述两种情况，均需要首先对存储组件进行版本升级，否则，若先升级其他控制组件，则就会导致未进行版本升级的存储组件不适配升级为目标版本的控制组件。

步骤230，在将存储组件的版本升级为目标版本后，再控制主节点中处于控制层的控制组件进行版本升级，以使控制组件的版本升级为目标版本。

在kubernetes中，控制组件是用于管理容器的编排的组件，在将存储组件的版本升级为目标版本后，就需要对控制主节点中处于控制层的控制组件进行版本升级，以使控制组件的版本升级为目标版本。

在本实施例中，上述目标版本指的是待升级的最终版本，目标版本可以是与上述当前版本相邻的版本，如当前版本为版本v1.12，则目标版本为版本v1.13，也可以是跨中间版本的版本，如当前版本为版本v1.12，则目标版本为版本v1.14，可见，目标版本跨越了版本v1.13。至于目标版本是升级前版本的相邻版本还是跨版本，本实施例对此并不限定。

需要说明的是，在本申请中，在进行跨版本升级时，无需经过中间版本便可控制各个控制组件的版本直接升级至目标版本，也就是说，在本申请中，不需要对多个中间版本进行逐级升级。

作为一个实施例，如图3所示，所述kubernetes还可以包括位于控制层中具有所述第一kubernetes版本的负载均衡组件，步骤230的具体实现方式可以包括如下步骤231～步骤233：

步骤231，判断主节点中处于控制层的控制组件是否存在负载均衡组件，如果是，若控制组件为负载均衡组件，则执行步骤232，如果否，则执行步骤233。

在一些实施例中，主节点和从节点均可以部署用于实现kubernetes中各节点应用服务service的通信与负载均衡机制的负载均衡组件。如，负载均衡组件可以是kube-proxy组件。

本步骤仅针对具有述第一kubernetes版本即未升级的负载均衡组件进行升级，对于部署已升级为目标版本的负载均衡组件的待升级的主节点，则不需要再进行版本升级。

步骤232，依据已配置的用于负载均衡组件升级的升级指令信息，控制负载均衡组件的版本升级，以使负载均衡组件的版本升级为目标版本。

在本步骤中，作为一个实施例，在升级控制组件的过程中，若确定该控制组件为未升级的负载均衡组件，则向各部署kubernetes的节点发送用于负载均衡组件升级的升级指令信息，以使各节点中的负载均衡组件的版本同步升级为目标版本。

负载均衡组件是一个全局组件，也就是说，在依据在管理节点中已配置的用于负载均衡组件升级的升级指令信息，控制负载均衡组件的版本升级的同时，被部署在其他节点的负载均衡组件均会同步升级，以使各个节点中的负载均衡组件的版本升级为目标版本。示例性的，若主节点的控制层中存在负载均衡组件，如kube-proxy组件，则当管理节点确定控制组件为kube-proxy组件，则依据升级指令信息，控制主节点中的kube-proxy组件进行版本升级，以使kube-proxy的版本升级为目标版本，在升级的过程中，向各节点发送升级指令信息，以使各节点中的kube-proxy的版本同步升级为目标版本。

基于上述描述，可以看出，只需要对一个负载均衡组件进行版本升级，在升级为目标版本后，部署在其他节点上的负载均衡组件也已同步升级为目标版本，这样，其他节点的负载均衡组件就无需再进行版本升级。

步骤233，依据已配置的控制组件的配置文件对控制组件进行升级，以使控制组件的版本升级为目标版本。

在本步骤中，需要事先为每一控制组件配置各自升级为目标版本的配置文件，也是说，针对每一控制组件，按照与该控制组件对应的配置文件，控制该控制组件进行版本升级，以使该控制组件的版本升级为目标版本。

至此，完成图3所示流程。

通过图3所示流程可以看出，在本申请实施例提供的技术方案中，版本升级后的负载均衡组件能够与版本升级后的各控制组件适配，使得kubernetes在业务场景中功能保持正常的同时，还能够进一步提升负载均衡组件的性能。

在一些实施例中，主节点上的控制层中可能还包含有第三方应用插件，如主要作为dns(domainnamesystem：域名系统)记录kubernetes上各类微服务的访问地址的coredns组件，基于此，作为一个实施例，kubernetes还可以包括位于控制层中具有第一kubernetes版本的第三方应用插件，依据已配置的第三方应用插件升级的升级指令信息，控制第三方应用插件进行版本升级，以使未升级第三方应用插件的版本均升级为目标版本。在本实施例中，上述第三应用插件指的是控制层内的第三应用插件。这样升级后的第三方应用插件能够适配版本升级为目标版本的控制组件。本实施例中的第三方应用插件也是一个全局组件，作为一个实施例，在控制主节点中处于控制层的控制组件进行版本升级时，若确定处于控制层的第三方应用插件为具有第一kubernetes版本即未升级的第三方应用插件，则向各部署kubernetes的节点发送第三方应用插件升级的升级指令信息，以使各节点中具有第一kubernetes版本的第三方应用插件的版本同步升级为目标版本。

至此，完成图2所示流程。

通过图2所示流程可以看出，在本申请中，通过控制主节点中的存储组件进行版本升级，以使存储组件的版本升级为目标版本；在将存储组件的版本升级为目标版本后，再控制主节点中处于控制层的控制组件进行版本升级，以使控制组件的版本升级为目标版本。可见，只需要引入目标版本的kubernetes即可，不需要引入多个中间版本的kubernetes，这样就不需要对各个中间版本进行测试以确定这些中间版本的kubernetes在业务场景中功能是否正常。可见，应用本申请实施例能够在降低测试工作量的同时，降低版本升级的复杂度。

在完成图2中的流程之后，作为一个实施例，如图4所示，kubernetes还可以包括部署在主节点中待升级的第三方应用插件和部署在从节点中节点端代理控制组件，该方法还可以包括如下步骤240～步骤280：

步骤240，检查部署第一kubernetes版本的节点中是否还存在未升级的主节点，如果是，执行步骤250，如果否，执行步骤260。

步骤250，选择一个待升级的主节点作为主节点，并返回执行步骤230。

步骤260，检查部署第一kubernetes版本的节点中是否存在待升级的从节点。当存在从节点时，执行步骤270；当不存在从节点时，执行步骤280。

在待升级的主节点中的各控制组件和存储组件的版本均升级为目标版本之后，再检查是否存在待升级的从节点。

鉴于主节点管理从节点，当选择的主节点为待升级的主节点时，待升级的从节点就是该待升级的主节点管理的从节点。作为一个实施例，从已配置的包含待升级的主节点管理的从节点的节点名单中，检查部署kubernete的节点中是否存在待升级的从节点。

步骤270，选择一个待升级的从节点，依据已配置的用于节点端代理控制组件升级的升级指令信息，控制节点端代理控制组件进行版本升级，以使节点端代理控制组件的版本升级为目标版本，并返回执行步骤260。

在kubernetes中，上述节点端代理控制组件就是kubelet，kubelet在每个主、从节点上都有，针对从节点而言，主要负责主节点下发到该从节点的具体任务，管理该从节点上的pod和容器。而且会在创建之初向应用服务apiserver注册自身的信息，定时汇报各个主、从节点的信息。它还通过容器监控工具cadvisor监控容器和节点资源。可见，kubelet类似于一个执行者，创建、修改、销毁pod的工作都是由它来具体执行。这样，每一主、从节点均需要部署kubelet。

步骤280，依据已配置的用于第三方应用插件升级的升级指令信息，控制部署第一kubernetes版本的主节点中待升级的第三方应用插件进行版本升级，以使第三方应用插件的版本升级为目标版本。

在一些实施例中，在升级完各待升级的主节点的控制组件和存储组件之后，若不存在待升级的从节点，则执行本步骤。在另一些实施例中，在升级完各待升级的主节点的控制组件和存储组件，以及，各待升级的从节点的控制组件之后，再执行本步骤。

在实际应用中，鉴于各节点的控制组件的版本升级为目标版本后，一些网络插件需要与升级后的控制组件适配，这些网络插件就是本步骤中的待升级的第三方应用插件，但并不需要对所有被部署在各节点中的网络插件进行版本升级，仅需要对不适配版本升级后的控制组件的网络插件进行版本升级。另一些网络插件，即使控制组件升级到目标版本后，仍然与目标版本的控制组件适配，针对这些网络插件就不需要进行版本升级。

在本实施例中，根据各网络插件的应用，一些网络插件仅被部署在主节点上，但这些网络插件不必部署在每一主节点上，如图5中仅部署在主节点1控制层内的coredns插件，但需要明确的是，coredns插件并不一定需要部署在每一个主节点上。而一些网络插件既可以部署在主节点上，又可以部署在从节点上，如图5中的calio插件和multus插件，二者均部署在主节点和从节点上。

基于上述描述，针对被部署在从节点的待升级的第三方应用插件，鉴于未升级的第三方应用插件是全局组件，则在对主节点被部署的待升级的第三方应用插件进行版本升级时，若从节点中存在与该主节点当前升级的待升级的第三方应用插件为同一网络插件时，此时，从节点中的该网络插件也会同步进行版本升级，以使该网络插件的版本升级为目标版本。

至此，完成图4所示流程。

通过图4所示流程可以看出，在本申请中，在各待升级的主节点的控制组件和存储组件版本升级完成后，再对各待升级的从节点的控制组件进行版本升级，之后，再对各待升级的主节点的未升级的第三方应用插件进行版本升级，以使未升级的第三方应用插件的版本升级为目标版本。可见，应用本申请实施例的技术方案只需要引入目标版本的kubernetes即可，不需要引入多个中间版本的kubernetes，这样就不需要对各个中间版本进行测试以确定这些中间版本的kubernetes在业务场景中功能是否正常，以能够在降低测试工作量的同时，降低版本升级的复杂度。

在实际应用中，并不需要对部署kubernetes的各节点均进行版本升级，有些节点因为实际需要，则并不需要进行版本升级，至于对哪些节点进行升级，这与节点的实际使用情况相关，本实施例对此并不限定。

基于此，在跨版本升级kubernetes的过程中，在一个已完成版本升级的节点中的组件，与一个未升级的节点中的组件进行交互时，就会出现各个组件的高低版本混跑场景，基于此，需要逐个对组件混跑进行分析，以达到混跑期间，业务功能正常的需求。

示例性的，针对存储组件，如已完成版本升级的主节点的存储组件为etcd-1，未升级的主节点的存储组件为etcd-2，由于存储组件可以以低版本协议进行通信，因此，存储组件能够支持跨版本的混跑，这样，未升级的etcd-2也能够与已经升级为目标版本的etcd-1进行通信，且在高低版本混跑场景满足在混跑期间，业务功能正常的需求。

另外，可能出现的混跑场景还可以包括主节点控制层内的coredns组件。基于此，作为一个实施例，本kubernetes中被部署的任一节点上的控制组件ga(generalavailability)的v1接口与外部进行通信。

在本申请，上述任一节点指的是主节点或从节点。ga是一种正式发布的版本，则ga的v1接口就是一种成熟的接口，能够用于稳定应用资源。在管理侧，各节点的控制组件间的通信均采用v1接口进行通信，这样，在后续的版本中都会支持，并且，只会新增接口资源不会减少接口资源。同时，对于删减掉的非v1接口资源，也不会影响kubernetes组件之间的正常通信，而且，升级期间，kubernetes的各节点的控制组件之间还可以正常通过v1接口进行通信。

作为一个实施例，在步骤230之前或在步骤270之前，还可以包括：依据目标版本对应的kubernetes资源号检查目标版本是否支持第一kubernetes版本已有的各第三方应用对应的应用资源，若目标版本不支持第一kubernetes版本已部署的至少一个第三方应用对应的应用资源，则删除至少一个应用对应的应用资源。

在实际应用中，第三方应用一般是部署在kubernetes中的业务侧，鉴于升级的目标版本并不支持一些第三方应用的应用资源，基于此，可以先删除第三方应用的应用资源，在删除应用资源后，可以再对支持这些第三方应用的应用资源的各组件进行版本升级。

示例性的，若支持第三方应用的应用资源的组件的当前版本为v12，v12对应的资源号为a，这也就是说，资源号为a对应的v12支持该应用资源，但经确定，该组件的当前版本需要升级至目标版本，而目标版本为v18，v18的资源号为b，b并不支持该应用资源，基于此，先删除该应用资源，再对v12进行版本升级，以升级至v18，最后创建该第三方应用的应用资源，以使v18能够支持创建的应用资源。

可见，在本实施例提供的技术方案中，针对目标版本不支持kubernetes已部署的第三方应用对应的应用资源，则先删除至少一个应用对应的应用资源，这样，可以待升级至目标版本后，创建目标版本能够支持的已删除的应用资质，进而能够使得业务侧的各第三方应用能够正常运行，且不影响业务。

下面通过一个具体实施例对本申请提供的方法进行描述：

参见图5所示，为本申请实施例的应用场景示意图，以一个主节点和该主节点管理的多个从节点为例进行说明，在实际应用中，主节点的数量可以更多，对此不做限制。此外，从节点的数量也可以更多。以下结合具体的图5所示的应用场景，该应用场景具体为：kubernete包括一个主节点1以及该主节点1管理的从节点1和从节点2，主节点1的控制层上部署有多个控制组件和coredns，且主节点和从节点部署的控制组件均有kubelet。主节点1部署的控制组件除kubelet外还至少包括kube-apiserver、kube-scheduler和kube-manager。

其中，kube-apiserver起着桥梁的作用，各个组件都要通过它进行交互。kube-manager类似于集群的大管家，管理着许多事务。

kube-scheduler类似于一个调度亭，负责pod的调度工作，负责决定将pod放在哪一个从节点上运行。kube-scheduler在调度时会充分考虑集群cluster的拓扑结构、当前各个节点的负载，以及应用对高可用、性能、数据亲和性的需求等。

可见，kubernetes的这些控制组件各自分别有着重要的功能。它们之间协同工作，共同保证了kubernetes对于容器化应用的自动管理。基于此，需要对这些控制组件所使用的版本进行逐个升级。

根据实际需要，上述kubernetes还可以部署用于搭建本kubernetes中各节点容器之间的通信网络的网络插件。该网络插件为第三方应用的cni(containernetworkinterface：容器网络接口)插件，如图5中主节点1、从节点1和从节点2中部署的calico和multus。以及，还可以部署用于实现kubernetes中各节点应用服务service的通信与负载均衡机制的均衡通信组件，如图5中主节点1、从节点1和从节点2中部署的kube-proxy组件，kube-proxy主要负责接收并转发请求，它的核心功能是将到service的访问请求转发到后台的某个具体的pod。同时，主节点1还可以部署用于存放本主节点1数据的存储插件，如图5中的etcd-1。kubernetes中各节点部署的控制组件之间的通信均采用v1接口。在kubernetes中，一个虚ip是一个多个节点共用的虚拟ip，可以设置在一个主节点中控制业务流量的接口处，且该接口处还可以设置负责业务均衡分担的均衡组件，以对传输的业务进行编排，并通过该ip传输到各个节点处。

基于上述描述的应用场景，参见图6，对本申请实施例中的跨版本升级方法进行说明：

步骤1.确定kubernetes的一个节点为管理节点，管理节点依据目标版本对应的kubernetes资源号a检查目标版本是否支持第一kubernetes版本已有的各第三方应用对应的应用资源，若目标版本不支持第一kubernetes版本已部署的第三方应用对应的应用资源d，则删除该应用资源d。再删除应用资源d之后，执行步骤2。

步骤2.管理节点从已部署第一kubernetes版本的所有节点中选择待升级的主节点1。控制主节点1先对etcd-1进行版本升级，以使etcd-1的版本升级为目标版本；这样，主节点1的存储组件的版本升级完毕，具体参见图6，图6中上述etcd-1旁的一个箭头数量表示升级etcd-1的步骤，即第一步。

在将etcd-1的版本升级为目标版本后，再判断控制组件是否为kube-proxy，如果是，判断kube-proxy是否为具有第一kubernetes版本的kube-proxy，在本实施例中，kube-proxy是未升级的组件，那么，依据主节点1已配置的用于负载均衡组件升级的升级指令信息，控制kube-proxy的版本升级，在升级的过程中，向从节点1和从节点2被部署的kube-proxy发送升级指令信息，以使主节点1、从节点1和从节点2中的kube-proxy的版本均同步升级为目标版本。若控制组件不为kube-proxy，则控制主节点1中处于控制层的kube-apiserver、kubelet、kube-scheduler或kube-manager控制组件进行版本升级，以使上述控制层中的各控制组件的版本均升级为目标版本。在升级主节1控制组件的过程中，确定控制层中还存在第一插件coredns，则可以对coredns进行版本升级，以使用coredns的版本升级为目标版本。

步骤3.管理节点检查部署第一kubernetes版本的节点中是否还存在未升级的主节点1，如果是，选择一个待升级的主节点1，并返回执行步骤1；如果否，执行步骤4。在本实施例中，只有一个待升级的主节点1，因此，上述步骤1和步骤2已经执行完毕后，意味着，本步骤只能执行步骤4。

这样，主节点1上各个控制组件和控制层内的插件的版本全部升级完毕，具体参见图6，图6中上述kube-apiserver、kubelet、kube-scheduler、kube-proxy、coredns和kube-manager旁的两个箭头数量表示升级kube-apiserver、kubelet、kube-scheduler、coredns、kube-proxy和kube-manager的步骤，即第二步。

步骤4.检查部署第一kubernetes版本的节点中是否存在待升级的从节点，当存在从节点时，选择一个待升级的从节点，假设选择的从节点为从节点1，则依据已配置的用于kubelet升级的升级指令信息控制从节点1中的kubelet进行版本升级，以使kubelet的版本升级为目标版本，并返回步骤4后，确定还存在未进行版本升级的从节点2，再控制从节点2中的kubelet进行版本升级，以使kubelet的版本升级为目标版本。

这样，从节点1和从节点2上各控制组件的版本全部升级完毕，具体参见图6，图6中上述从节点1和从节点2中kubelet旁的三个箭头数量表示升级kubelet的步骤，即第三步。

此时，再并返回步骤4，发现已经不存再待升级的从节点，依据已配置的用于multus的升级指令信息控制第一kubernetes版本的主节点1中multus进行版本升级，以使multus的版本升级为目标版本。鉴于multus为全局插件，则从节点1的multus也与主节点1在升级multus时，同步升级至目标版本。

这样，主节点和从节点中待升级的第三方应用插件升级全部升级完毕，具体参见图6图6中上述multus旁的四个箭头数量表示升级multus的步骤，即第四步，此时，升级后的multus能够与主节点1中的各控制组件适配，使得其性能得到进一步提高。

基于与上述方法同样的申请构思，如图7所示，本申请实施例还提出一种跨版本升级装置700，应用于管理节点，上述装置包括：

节点选择单元710，用于从已部署第一kubernetes版本的所有主节点中选择一个待升级的主节点，所述第一kubernetes版本的kubernetes包括具有所述第一kubernetes版本的用于数据存储的存储组件和位于控制层的控制组件；

存储组件升级单元720，用于控制存储组件进行版本升级，以使存储组件的版本升级为目标版本；

控制组件升级单元730，用于在将所述存储组件的版本升级为目标版本后，再控制所述主节点的控制组件进行版本升级，以使所述控制组件的版本升级为目标版本。

作为一个实施例，所述kubernetes还包括位于控制层中具有所述第一kubernetes版本的负载均衡组件，上述控制组件升级单元730，具体用于执行：

若所述控制组件为所述负载均衡组件，则依据已配置的用于负载均衡组件升级的升级指令信息，控制所述负载均衡组件的版本升级，以使所述负载均衡组件的版本升级为目标版本；

若所述控制组件不为所述负载均衡组件，则依据已配置的控制组件的配置文件对所述控制组件进行版本升级，以使所述控制组件的版本升级为目标版本。

作为一个实施例，所述kubernetes还包括位于控制层中具有第一kubernetes版本的第三方应用插件，在控制主节点的所述控制组件进行版本升级时，该装置还可以包括：

控制层插件升级单元，用于依据已配置的用于第三方应用插件升级的升级指令信息，控制所述第三方应用插件进行版本升级，以使所述第三方应用插件的版本均升级为目标版本。

作为一个实施例，kubernetes还包括部署在主节点中待升级的第三方应用插件和部署在从节点中节点端代理控制组件，所述装置还可以包括：

检查单元，用于检查部署第一kubernetes版本的节点中是否还存在未升级的主节点，如果是，触发主节点选择单元，如果否，触发从节点检查单元；

所述主节点选择单元，用于选择一个待升级的主节点，并触发所述控制组件升级单元；

所述从节点检查单元，用于检查部署第一kubernetes版本的节点中是否存在待升级的从节点，当存在从节点时，触发从节点选择单元；当不存在从节点时，触发插件升级单元；

所述从节点选择单元，用于选择一个待升级的从节点，依据已配置的用于节点端代理控制组件升级的升级指令信息，控制节点端代理控制组件进行版本升级，以使所述节点端代理控制组件的版本升级为目标版本，并触发所述从节点检查单元；当不存在从节点时，触发插件升级单元；

所述插件升级单元，用于依据已配置的用于第三方应用插件升级的升级指令信息，控制部署第一kubernetes版本的主节点中待升级的第三方应用插件进行版本升级，以使所述第三方应用插件的版本升级为目标版本。

作为一个实施例，所述kubernetes中被部署的任一节点上的控制组件通过ga的v1接口与外部进行通信。

作为一个实施例，所述装置还可以包括：

应用资源检查单元，用于依据所述目标版本对应的kubernetes资源号检查所述目标版本是否支持第一kubernetes版本已有的各第三方应用对应的应用资源，若所述目标版本不支持第一kubernetes版本已部署的至少一个第三方应用对应的应用资源，则触发删除单元；

所述删除单元，用于删除所述至少一个应用对应的应用资源。

上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

对应地，本申请实施例还提供了图8所示装置实施例的硬件结构图，具体如图8所示。如图8示，该硬件结构包括：处理器和存储器。

其中，所述存储器，用于存储机器可执行指令；

所述处理器，用于读取并执行所述存储器存储的机器可执行指令，以实现如图1所示的跨版本升级方法。

作为一个实施例，存储器可以是任何电子、磁性、光学或其它物理存储装置，可以包含或存储信息，如可执行指令、数据，等等。例如，存储器可以是：易失存储器、非易失性存储器或者类似的存储介质。具体地，存储器可以是ram(radomaccessmemory，随机存取存储器)、闪存、存储驱动器(如硬盘驱动器)、固态硬盘、任何类型的存储盘(如光盘、dvd等)，或者类似的存储介质，或者它们的组合。

至此，完成图8所示设备的描述。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。