一种版本升级方法及计算机可读存储介质与流程

1.本发明属于版本升级技术领域，更具体地说，本发明涉及一种版本升级方法及计算机可读存储介质。


背景技术：

2.kubernetes简称k8s，是google开源的编排容器的重要工具，从2015年v1.0版本开始，至2021年7月的最新版本v1.21，google已经发布了二十多个大版本。很多使用了kubernetes集群作为生产环境运行载体的企业，不会选择及时升级，从而造成与最新版本之间存在多个版本的落后。当企业面临版本升级问题时，最主流的升级工具是开源社区的kubeadm upgrade，首先升级控制平面，然后升级工作节点，最后通过k8s api调整资源配置文件。但是该工具推荐的升级方式是同一大版本的小版本升级，或是相邻的大版本升级。如果需要跨若干个大版本进行升级，目前的技术方案存在以下缺陷：
3.第一，容易出现k8s某特性废弃的现象，导致升级到新版本时，被废弃的特性可能会影响集群和服务的稳定性；第二kubeadm是在原地升级，如果遇到升级失败，或者升级后集群或服务不稳定，它的回滚功能也无法完全回退到原先状态，且在这段升级和回滚期间，服务的可用性也无法保障。
4.目前对于该问题的处理方式是：逐版本的升级。例如升级k8s版本v1.10到v.16，使用kubeadm工具先升级到v1.11，接着v1.12，v1.13等经历6次升级后达到v1.16。该处理方式的问题是每次升级都需要耗费运维人力去关注kubernetes集群和服务的可用性，且容易出现生产故障，如低版本的kubernetes集群和高版本的kubernetes集群在内网域名系统和外网域名系统不互通，导致服务间访问不可达的现象，并仍然存在不可回滚的情况。


技术实现要素：

5.本发明的目的在于提供一种版本升级方法及计算机可读存储介质，以解决上述现有技术中存在的在版本升级和回滚期间，业务应用服务的可用性无法保障的技术问题。
6.为实现上述技术目的，本发明采用的技术方案如下：
7.一种版本升级方法，包括以下步骤：
8.建立目标版本的新kubernetes集群；
9.所述新kubernetes集群的部署单元和原kubernetes集群的部署单元进行互通访问；
10.所述新kubernetes集群和所述原kubernetes集群在内网域名系统进行互通访问；
11.所述新kubernetes集群和所述原kubernetes集群在外网域名系统进行互通访问；
12.将所述原kubernetes集群的资源配置文件平滑迁移到所述新kubernetes集群；
13.判断所述原kubernetes集群的应用是否都迁移完成，若是，则结束流程；若否，则继续将剩余的所述原kubernetes集群的资源配置文件平滑迁移到所述新kubernetes集群。
14.优选地，建立目标版本的新kubernetes集群，具体包括以下步骤：
15.初始化目标版本的所述新kubernetes集群中的组件配置；
16.部署所述新kubernetes集群中的主节点；
17.加入所述新kubernetes集群中的工作节点。
18.优选地，所述组件配置包括主节点接口服务器、资源控制器、容器调度组件、存储组件、容器网络标准组件、网络组件和容器控制器。
19.优选地，还包括以下步骤：
20.在所述原kubernetes集群中部署第一控制器，在所述新kubernetes集群中部署第二控制器。
21.优选地，新kubernetes集群的部署单元和原kubernetes集群的部署单元进行互通访问，具体包括以下步骤：
22.所述原kubernetes集群新增若干个工作节点；
23.容器网络标准组件分配所述工作节点的部署单元ip地址段；
24.所述第一控制器监控所述部署单元ip地址段和所述工作节点，并在路由表中添加记录。
25.优选地，新kubernetes集群的部署单元和原kubernetes集群的部署单元进行互通访问，具体包括以下步骤：
26.所述新kubernetes集群新增若干个工作节点；
27.容器网络标准组件分配所述工作节点的部署单元ip地址段；
28.所述第二控制器监控所述部署单元ip地址段和所述工作节点，并在路由表中添加记录。
29.优选地，所述新kubernetes集群和所述原kubernetes集群在内网域名系统进行互通访问，具体包括以下步骤：
30.获取kubernetai插件，将所述kubernetai插件放入所述内网域名系统并重新构建镜像；
31.在所述新kubernetes集群更新镜像，在所述原kubernetes集群更新镜像；
32.所述新kubernetes集群的apiserver访问方式写入原kubernetes集群的配置文件中；
33.所述原kubernetes集群的apiserver访问方式写入新kubernetes集群的配置文件中。
34.优选地，所述新kubernetes集群和所述原kubernetes集群在外网域名系统进行互通访问，具体包括以下步骤：
35.更改第三控制器的源代码，所述第三控制器同时监控所述新kubernetes集群的端点和所述原kubernetes集群的端点；
36.所述新kubernetes集群的端点和所述原kubernetes集群的端点合并成一个上游服务器的列表。
37.优选地，若否，则继续将剩余的所述原kubernetes集群的资源配置文件平滑迁移到所述新ku bernetes集群，具体包括以下步骤：
38.确定下一个需要迁移的业务应用，导出所述业务应用在所述原kubernetes集群的资源配置文件；
39.所述新kubernetes集群根据所述资源配置文件进行新建部署；
40.对所述新kubernetes集群内的所述业务应用进行健康检查；
41.删除所述原kubernetes集群内的所述业务应用。
42.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机指令，所述计算机指令被处理器执行时实现上述所述方法的步骤。
43.本发明提供的有益效果在于：
44.1、本发明通过建立目标版本的新kubernetes集群，新kubernetes集群的部署单元和原kubernetes集群的部署单元进行互通访问，使新kubernetes集群和原kubernetes集群中运行的业务应用一直处于互相可用的状态，实现业务应用过程中的服务高可用，通过容器网络标准组件和基础网络设施让原kubernetes集群和新kubernetes集群的部署单元网络互通，防止出现原kubernetes集群的业务应用访问迁移至新kubernetes集群的业务应用的部署单元时会出现网络不通的现象。
45.2、本发明通过新kubernetes集群和原kubernetes集群在内网域名系统进行互通访问，保障系统内部服务调用的稳定性，防止出现原kubernetes集群的业务应用通过内网域名系统访问迁移至新kubernetes集群的业务应用时，会出现内网域名无法解析的现象。
46.3、本发明通过新kubernetes集群和原kubernetes集群在外网域名系统进行互通访问，通过ingress控制器实现在新kubernetes集群和原kubernetes集群的外网域名访问互通，可保障对外提供域名访问的服务不受影响，不会因为部署单元迁移到新kubernetes集群后导致服务不可用的问题。
附图说明
47.为了更清楚地说明本发明实施例中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
48.图1是版本升级的方法流程图；
49.图2是部署单元进行互通访问的流程示意图；
50.图3是内网域名系统进行互通访问的流程示意图；
51.图4是原kubernetes集群的资源配置文件平滑迁移到新kubernetes集群的流程示意图。
具体实施方式
52.为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本发明实施例的组件可以以各种不同的配置来布置和设计。
53.因此，以下对在附图中提供的本发明的实施例的详细描述并非旨在限制要求保护的本发明的范围，而是仅仅表示本发明的选定实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范
围。
54.实施例1：
55.如图1所示，本实施例包括一种版本升级方法，包括以下步骤：建立目标版本的新kubernetes集群；新kubernetes集群的部署单元和原kubernetes集群的部署单元进行互通访问；新kubernetes集群和原kubernetes集群在内网域名系统进行互通访问；新kubernetes集群和原kubernetes集群在外网域名系统进行互通访问；将原kubernetes集群的资源配置文件平滑迁移到新kubernetes集群；判断原kubernetes集群的应用是否都迁移完成，若是，则结束流程；若否，则继续将剩余的原kubernetes集群的资源配置文件平滑迁移到新kubernetes集群。
56.在kubernetes跨大版本升级的过程中，能使新kubernetes集群和原kubernetes集群中运行的业务应用一直处于互相可用的状态，相较于现有技术中，直接在原kubernetes集群中版本升级，或者断开原kubernetes集群的业务应用可用状态直接与新kubernetes集群建立业务应用连接的方式，本实施例中的版本升级方法可以实现业务应用过程中的服务高可用，且容易回滚，相比于kubeadm升级，减少了大版本升级的升级操作次数。
57.建立目标版本的新kubernetes集群，具体包括以下步骤：初始化目标版本的新kubernetes集群中的组件配置；部署新kubernetes集群中的主节点；加入新kubernetes集群中的工作节点。组件配置包括主节点接口服务器、资源控制器、容器调度组件、存储组件、容器网络标准组件、网络组件和容器控制器。
58.具体的，在本实施例中，在同一专有网络下，通过使用kubeadm工具建立目标版本的新kubernetes集群，初始化目标版本的新kubernetes集群中的组件，组件包括主节点接口服务器(kube
‑
apiserver)、资源控制器(kube
‑
controller
‑
manager)、容器调度组件(kube
‑
scheduler)、存储组件(etcd)、容器网络标准组件(cni)、网络组件(kube
‑
proxy)和容器控制器(kubelet)等，cni组件可以选择flannel插件。
59.如图2所示，还包括以下步骤：在原kubernetes集群中部署第一控制器，在新kubernetes集群中部署第二控制器。
60.新kubernetes集群的部署单元和原kubernetes集群的部署单元进行互通访问，具体包括以下步骤：原kubernetes集群新增若干个工作节点；容器网络标准组件分配工作节点的部署单元ip地址段(pod ip classless inter
‑
domain routing)，classless inter
‑
domainrouting以下简称cidr；第一控制器监控部署单元ip地址段和工作节点，并在路由表中添加记录。
61.新kubernetes集群的部署单元和原kubernetes集群的部署单元进行互通访问，具体包括以下步骤：新kubernetes集群新增若干个工作节点；容器网络标准组件分配工作节点的部署单元ip地址段(pod ipcidr)；第二控制器监控部署单元ip地址段和工作节点，并在路由表中添加记录。
62.具体的，在本实施例中，第一控制器和第二控制器均为路由控制器，通过在原kubernetes集群和新kubernetes集群分别部署一个路由控制器，当在原kubernetes集群或新kubernetes集群新增一个工作节点时，cni组件分配工作节点的pod ip cidr，路由控制器监控到podip cidr和pod ip cidr对应的工作节点，并在专有网络的路由表中添加一条记录，即pod ipcidr的下一跳为该工作节点的ip。
63.通过cni组件和基础网络设施让原kubernetes集群和新kubernetes集群的部署单元网络互通，防止出现原kubernetes集群的业务应用a访问迁移至新kubernetes集群的业务应用b的部署单元时会出现网络不通的现象。
64.如图3所示，新kubernetes集群和原kubernetes集群在内网域名系统进行互通访问，具体包括以下步骤：获取kubernetai插件，将kubernetai插件放入内网域名系统并重新构建镜像；在新kubernetes集群更新镜像，在原kubernetes集群更新镜像；新kubernetes集群的apiserver访问方式写入原kubernetes集群的配置文件中；原kubernetes集群的apiserver访问方式写入新kubernetes集群的配置文件中。
65.具体的，下载并获取插件kubernetai源代码，将kubernetai插件放入内网域名系统(coredns)并重新构建镜像，将kubernetai插件放入内网域名系统并重新构建镜像，在新kubernetes集群更新上述镜像，在原kubernetes集群更新上述镜像。
66.将新kubernetes集群的主节点接口服务器的apiserver访问方式写入原kubernetes集群的配置文件中，将原kubernetes集群的apiserver访问方式写入新kubernetes集群的配置文件中。
67.当一项业务应用从原kubernetes集群迁移到新kubernetes集群，原kubernetes集群能通过coredns将访问的内网域名解析到新kubernetes集群的内网域名的ip，新kubernetes集群也能通过coredns将访问的内网域名解析到原kubernetes集群的内网域名的ip。
68.通过在同一专有网络下建立目标版本的新kubernetes集群，并实现同一专有网络下新kubernetes集群的部署单元和原kubernetes集群的部署单元的网络互通，实现内网域名系统在新kubernetes集群和原kubernetes集群的内网域名互通。可保证分布在新kubernetes集群的部署单元和原kubernetes集群的部署单元，通过ip和内网域名实现访问互通互相不受影响，可保障系统内部服务调用的稳定性。防止出现原kubernetes集群的业务应用a通过内网域名系统访问迁移至新kubernetes集群的业务应用b时，会出现内网域名无法解析的现象。
69.新kubernetes集群和原kubernetes集群在外网域名系统进行互通访问，具体包括以下步骤：更改第三控制器的源代码，第三控制器同时监控新kubernetes集群的端点和原kubernetes集群的端点；新kubernetes集群的端点和原kubernetes集群的端点合并成一个上游服务器的列表。
70.具体的，在本实施例中第三控制器为ingress控制器(ingresscontroller)，通过更改ingress控制器的源代码，同时监控新kubernetes集群和原kubernetes集群的端点(endpoints)，并且合并成一个上游服务器的列表。当某业务应用副本从原kubernetes集群迁移到新kubernetes集群，无需修改外网dns解析，仍然可以实现将原kubernetes集群的网关流量代理到新kubernetes集群的业务应用副本中。
71.具体的，业务应用a基于主节点接口服务器(kube
‑
apiserver)作为服务发现机制，可以获得迁移至新kubernetes集群的业务应用b的部署单元的ip，即业务应用a可以获得依赖业务应用b的端点(endpoint)ip，从而访问成功。
72.通过ingress控制器实现在新kubernetes集群和原kubernetes集群的外网域名访问互通。可保障对外提供域名访问的服务不受影响，不会因为部署单元(pod)迁移到新
kubernetes集群后导致服务不可用的问题。
73.如图4所示，若否，则继续将剩余的原kubernetes集群的资源配置文件平滑迁移到新kubernetes集群，具体包括以下步骤：确定下一个需要迁移的业务应用，导出业务应用在原kub ernetes集群的资源配置文件；新kubernetes集群根据资源配置文件进行新建部署；对新kub ernetes集群内的业务应用进行健康检查；删除原kubernetes集群内的业务应用。
74.具体的，健康检查采用就绪探针技术，就绪探针技术包括http探测，tcp套接字探测和本地命令探测中的至少一种，当探针连续执行探测若干次，并且均获得预期的结果，即认为业务应用通过健康检查。
75.将原kubernetes集群的资源配置文件平滑迁移到新kubernetes集群，通过导出业务应用在原kubernetes集群的资源配置文件，将导出的资源配置文件在新kubernetes集群中新建部署，并等待新kubernetes集群的业务应用通过健康检查，当通过健康检查后再删除原kubern etes集群的资源配置文件，从而达到平滑迁移的效果，在此迁移过程中，服务都是可用的。
76.实施例2：
77.一种计算机可读存储介质，计算机可读存储介质上存储有计算机指令，计算机指令被处理器执行时实现实施例1中方法的步骤。
78.本领域内的技术人员应明白，本发明的实施例可提供为方法、装置、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd
‑
rom、光学存储器等)上实施的计算机程序产品的形式。
79.本发明是参照根据本发明的方法、终端设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理终端设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理终端设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
80.这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理终端设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
81.这些计算机程序指令也可装载到计算机或其他可编程数据处理终端设备上，使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程终端设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
82.需要说明的是：
83.说明书中提到的“一个实施例”或“实施例”意指结合实施例描述的特定特征、结构或特性包括在本发明的至少一个实施例中。因此，说明书通篇各个地方出现的短语“一个实
施例”或“实施例”并不一定均指同一个实施例。
84.尽管已描述了本发明的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。
85.此外，需要说明的是，本说明书中所描述的具体实施例，其零、部件的形状、所取名称等可以不同。凡依本发明专利构思所述的构造、特征及原理所做的等效或简单变化，均包括于本发明专利的保护范围内。本发明所属技术领域的技术人员可以对所描述的具体实施例做各种各样的修改或补充或采用类似的方式替代，只要不偏离本发明的结构或者超越本权利要求书所定义的范围，均应属于本发明的保护范围。