CN111897558A - 容器集群管理系统Kubernetes升级方法和装置 - Google Patents
容器集群管理系统Kubernetes升级方法和装置 Download PDFInfo
- Publication number
- CN111897558A CN111897558A CN202010716323.6A CN202010716323A CN111897558A CN 111897558 A CN111897558 A CN 111897558A CN 202010716323 A CN202010716323 A CN 202010716323A CN 111897558 A CN111897558 A CN 111897558A
- Authority
- CN
- China
- Prior art keywords
- kubernets
- version
- cluster
- upgrading
- container
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 129
- 230000008569 process Effects 0.000 claims abstract description 86
- 230000009467 reduction Effects 0.000 claims description 36
- 238000004140 cleaning Methods 0.000 claims description 19
- 238000012545 processing Methods 0.000 claims description 17
- 230000005012 migration Effects 0.000 claims description 15
- 238000013508 migration Methods 0.000 claims description 15
- 238000003860 storage Methods 0.000 claims description 14
- 230000002688 persistence Effects 0.000 claims description 12
- 238000005096 rolling process Methods 0.000 claims description 9
- 238000007726 management method Methods 0.000 description 16
- 238000010586 diagram Methods 0.000 description 14
- 238000012217 deletion Methods 0.000 description 6
- 230000037430 deletion Effects 0.000 description 6
- 238000004590 computer program Methods 0.000 description 5
- 230000006870 function Effects 0.000 description 5
- 230000008901 benefit Effects 0.000 description 3
- 238000001514 detection method Methods 0.000 description 3
- 230000001360 synchronised effect Effects 0.000 description 3
- 230000008859 change Effects 0.000 description 2
- 239000003795 chemical substances by application Substances 0.000 description 2
- 230000002427 irreversible effect Effects 0.000 description 2
- 238000004519 manufacturing process Methods 0.000 description 2
- 230000002085 persistent effect Effects 0.000 description 2
- 238000013461 design Methods 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 239000003550 marker Substances 0.000 description 1
- 238000013024 troubleshooting Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/90—Details of database functions independent of the retrieved data types
- G06F16/901—Indexing; Data structures therefor; Storage structures
- G06F16/9014—Indexing; Data structures therefor; Storage structures hash tables
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/70—Software maintenance or management
- G06F8/71—Version control; Configuration management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/4557—Distribution of virtual machine instances; Migration and load balancing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45575—Starting, stopping, suspending or resuming virtual machine instances
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45595—Network integration; Enabling network access in virtual machine instances
Abstract
本申请公开了一种容器集群管理系统Kubernetes升级方法和装置，所述方法包括：获取升级请求；根据升级请求，将低版本集群中的Kubernetes资源迁移到高版本集群中；根据高版本集群中的资源对高版本集群中的容器进行更新；将宿主机上的低版本Kubelet升级至高版本，并将高版本集群中更新后的容器由高版本Kubelet接管，以完成升级过程。本申请的升级方法可针对任意版本的集群升级使用，通用性更强，降低了集群整体升级的风险，将风险降低到宿主机维度，一台宿主机升级失败不会影响到集群中其它的容器和宿主机。此外，本申请解决了升级过程中容器重启的问题，升级不会造成容器重启，用户无感知，提高了用户体验。
Description
技术领域
本申请涉及计算机技术领域，具体涉及一种容器集群管理系统 Kubernetes升级方法和装置。
背景技术
Kubernetes是Google(谷歌)开源的一个容器集群管理系统，它支持自 动化部署、大规模可伸缩、应用容器化管理。在生产环境中部署一个应用程 序时，通常要部署该应用的多个实例以便对应用请求进行负载均衡。在 Kubernetes中可以创建多个容器，每个容器里面运行一个应用实例，然后通 过内置的负载均衡策略，实现对这一组应用实例的管理、发现、访问，而这 些细节都不需要运维人员去进行复杂的手工配置和处理。
现有的Kubernetes集群升级方案为开源社区官方推荐的升级方案，也是 业界的主流方案，该升级方案主要分为控制平面的滚动升级和数据平面的滚 动升级两个部分，真正的工作负载都在数据平面上。
然而，发明人发现，上述升级方案至少存在着升级过程的可控性差、控 制层面升级不可灰度、用户体验较差等技术问题。
发明内容
鉴于上述问题，提出了本申请以便提供一种克服上述问题或者至少部分 地解决上述问题的容器集群管理系统Kubernetes升级方法和装置。
依据本申请的第一方面，提供了一种容器集群管理系统Kubernetes升级 方法，包括：
获取Kubernetes升级请求，其中所述Kubernetes升级请求包括对宿主机 上的低版本Kubelet进行升级的请求；
根据所述Kubernetes升级请求，将低版本集群中的Kubernetes资源迁移 到高版本集群中，所述Kubernetes资源至少包括容器；
根据所述高版本集群中的Kubernetes资源对所述高版本集群中的容器进 行更新，所述更新至少包括哈希值更新；
将所述宿主机上的低版本Kubelet升级至高版本Kubelet，并将高版本集 群中更新后的容器由所述高版本Kubelet接管，以完成Kubernetes升级过程。
可选地，所述获取Kubernetes升级请求包括：
根据所述Kubernetes升级请求确定所述低版本Kubelet对应的宿主机；
将所述宿主机的状态设置为禁止调度状态。
可选地，所述将所述宿主机上的低版本Kubelet升级至高版本Kubelet， 并将高版本集群中更新后的容器由所述高版本Kubelet接管，以完成 Kubernetes升级过程包括：
在所述Kubernetes升级过程完成后，将所述宿主机的状态恢复为可调度 状态。
可选地，所述根据所述Kubernetes升级请求，将所述低版本集群中的 Kubernetes资源迁移到高版本集群中包括：
通过Kubernetes的接口服务接收待迁移数据，并检测所述待迁移数据中 是否存在所述低版本集群中的Kubernetes资源的唯一标识；
若存在，则直接将所述低版本集群中的Kubernetes资源的唯一标识作为 所述高版本集群中的Kubernetes资源的唯一标识，并将所述待迁移数据进行 数据持久化处理后同步至键值数据库中；
若不存在，则为所述待迁移数据创建唯一标识，并将所述待迁移数据进 行数据持久化处理后同步至所述键值数据库中。
可选地，所述根据所述高版本集群中的Kubernetes资源对所述高版本集 群中的容器进行更新包括：
获取所述低版本集群中的容器的哈希值，作为所述高版本集群中的容器 的第一哈希值；
根据所述高版本集群中的资源计算所述高版本集群中的容器的第二哈希 值；
对所述第二哈希值和所述第一哈希值进行比较，当所述第二哈希值与所 述第一哈希值不一致时，根据所述第二哈希值对所述高版本集群中的容器的 第一哈希值进行更新。
可选地，所述方法还包括：
在Kubernetes升级过程中，检测所述宿主机上是否发生容器重启事件；
在发生容器重启事件的情况下，中断所述Kubernetes升级过程并回滚所 述Kubernetes升级过程中已完成的操作。
可选地，所述方法还包括：
在所述Kubernetes升级过程完成后，按照预设缩容算法对所述宿主机上 的Kubernetes资源进行资源清理。
可选地，所述Kubernetes资源包括所述宿主机上的容器所对应的部署单 元Pod，所述按照预设缩容算法对所述宿主机上的低版本Kubelet管理的低版 本集群进行资源清理包括：
确定所述宿主机的Pod的缩容策略，所述缩容策略包括：所述Pod是否 已被调度、所述Pod的状态、所述Pod是否带有优先删除标记、所述Pod的 准备就绪时间、所述Pod的重启次数以及所述Pod的创建时间；
根据所述缩容策略确定所述宿主机上的待清理Pod，并将所述待清理Pod 从所述宿主机上的低版本集群中清理掉。
依据本申请的第二方面，提供了一种容器集群管理系统Kubernetes升级 装置，包括：
获取单元，用于获取Kubernetes升级请求，其中所述Kubernetes升级请 求包括对宿主机上的低版本Kubelet进行升级的请求；
迁移单元，用于根据所述Kubernetes升级请求，将低版本集群中的 Kubernetes资源迁移到高版本集群中，所述Kubernetes资源至少包括容器；
更新单元，用于根据所述高版本集群中的Kubernetes资源对所述高版本 集群中的容器进行更新，所述更新至少包括哈希值更新；
升级单元，用于将所述宿主机上的低版本Kubelet升级至高版本Kubelet， 并将高版本集群中更新后的容器由所述高版本Kubelet接管，以完成 Kubernetes升级过程。
可选地，所述获取单元还用于：
根据所述Kubernetes升级请求确定所述低版本Kubelet对应的宿主机；
将所述宿主机的状态设置为禁止调度状态。
可选地，所述升级单元还用于：
在所述Kubernetes升级过程完成后，将所述宿主机的状态恢复为可调度 状态。
可选地，所述迁移单元还用于：
通过Kubernetes的接口服务接收待迁移数据，并检测所述待迁移数据中 是否存在所述低版本集群中的Kubernetes资源的唯一标识；
若存在，则直接将所述低版本集群中的Kubernetes资源的唯一标识作为 所述高版本集群中的Kubernetes资源的唯一标识，并将所述待迁移数据进行 数据持久化处理后同步至键值数据库中；
若不存在，则为所述待迁移数据创建唯一标识，并将所述待迁移数据进 行数据持久化处理后同步至所述键值数据库中。
可选地，所述更新单元还用于：
获取所述低版本集群中的容器的哈希值，作为所述高版本集群中的容器 的第一哈希值；
根据所述高版本集群中的资源计算所述高版本集群中的容器的第二哈希 值；
对所述第二哈希值和所述第一哈希值进行比较，当所述第二哈希值与所 述第一哈希值不一致时，根据所述第二哈希值对所述高版本集群中的容器的 第一哈希值进行更新。
可选地，所述装置还包括：
检测单元，用于在Kubernetes升级过程中，检测所述宿主机上是否发生 容器重启事件；
中断单元，用于在发生容器重启事件的情况下，中断所述Kubernetes升 级过程并回滚所述Kubernetes升级过程中已完成的操作。
可选地，所述装置还包括：
清理单元，用于在所述Kubernetes升级过程完成后，按照预设缩容算法 对所述宿主机上的Kubernetes资源进行资源清理。
可选地，所述Kubernetes资源包括所述宿主机上的容器所对应的部署单 元Pod，所述清理单元还用于：
确定所述宿主机的Pod的缩容策略，所述缩容策略包括：所述Pod是否 已被调度、所述Pod的状态、所述Pod是否带有优先删除标记、所述Pod的 准备就绪时间、所述Pod的重启次数以及所述Pod的创建时间；
根据所述缩容策略确定所述宿主机上的待清理Pod，并将所述待清理Pod 从所述宿主机上的低版本集群中清理掉。
依据本申请的第三方面，提供了一种电子设备，包括：处理器；以及被 安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述 处理器执行如上述任一所述的容器集群管理系统Kubernetes升级方法。
依据本申请的第四方面，提供了一种计算机可读存储介质，其中，所述 计算机可读存储介质存储一个或多个程序，所述一个或多个程序当被处理器 执行时，实现如上述任一所述的容器集群管理系统Kubernetes升级方法。
由上述可知，本申请的技术方案，通过获取Kubernetes升级请求，其中 所述Kubernetes升级请求包括对宿主机上的低版本Kubelet进行升级的请求； 根据所述Kubernetes升级请求，将所述低版本集群中的Kubernetes资源迁移 到高版本集群中，所述Kubernetes资源至少包括容器；根据所述高版本集群 中的Kubernetes资源对所述高版本集群中的容器进行更新，所述更新至少包 括哈希值更新；将所述宿主机上的低版本Kubelet升级至高版本Kubelet，并 将高版本集群中更新后的容器由所述高版本Kubelet接管，以完成Kubernetes 升级过程。本申请的Kubernetes升级方法可针对任意版本的Kubernetes集群 升级使用，通用性更强。本申请降低了集群整体升级的风险，将风险降低到 宿主机维度，一台宿主机升级失败不会影响到集群中其它的容器和宿主机。 此外，本申请解决了升级过程中容器重启的问题，升级不会造成容器重启， 用户无感知，提高了用户体验。
上述说明仅是本申请技术方案的概述，为了能够更清楚了解本申请的技 术手段，而可依照说明书的内容予以实施，并且为了让本申请的上述和其它 目的、特征和优点能够更明显易懂，以下特举本申请的具体实施方式。
附图说明
通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本 领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的， 而并不认为是对本申请的限制。而且在整个附图中，用相同的参考符号表示 相同的部件。在附图中：
图1示出了现有技术中的Kubernetes整体架构示意图；
图2示出了根据本申请一个实施例的容器集群管理系统Kubernetes升级 方法的流程示意图；
图3示出了根据本申请一个实施例的Kubernetes整体升级过程示意图；
图4示出了根据本申请一个实施例的Kubernetes资源迁移过程示意图；
图5示出了根据本申请一个实施例的Kubernetes中容器哈希值更新的过 程示意图；
图6示出了根据本申请一个实施例的Kubernetes升级流程示意图；
图7示出了根据本申请一个实施例的容器集群管理系统Kubernetes升级 装置的结构示意图；
图8示出了根据本申请一个实施例的电子设备的结构示意图；
图9示出了根据本申请一个实施例的计算机可读存储介质的结构示意 图。
图中：Kube-controller-manager为在主节点上运行控制器的组件， Kube-apiserver为主节点上负责提供Kubernetes接口服务的组件， Kube-scheduler为主节点上的调度和负载均衡组件，Kubelet为在集群中每个 节点上运行的代理，Node为节点对象，Kube-proxy是集群中每个节点上运行 的网络代理，ETCD为Kubernetes中默认的存储系统，UID(UserIdentification) 为Kubernetes中唯一标识对象的字符串，Pod为Kubernetes中应用程序的单 个实例，Docker为Kubernetes Pod中最常用的容器运行时，Container为容器。
具体实施方式
下面将参照附图更详细地描述本申请的示例性实施例。虽然附图中显示 了本申请的示例性实施例，然而应当理解，可以以各种形式实现本申请而不 应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地 理解本申请，并且能够将本申请的范围完整的传达给本领域的技术人员。
如图1所示，提供了一种现有的Kubernetes整体架构，现有的Kubernetes 架构主要包括控制平面组件和工作负载平面组件，对应的升级方案也分为控 制平面升级和工作负载平面升级两部分，其中控制平面升级主要是指滚动升 级控制平面组件，包括Kube-apiserver、Kuber-scheduler和 Kube-controller-manager组件的升级；工作负载平面升级主要是指滚动升级宿 主机上的工作组件，包括Kubelet、Kube-proxy等组件。
然而现有的控制平面升级过程通常会影响到整个Kubernetes集群，即影 响到Kubernetes集群中的所有宿主机，风险较高，很容易出现升级失败导致 数据无法恢复等不可逆的问题。并且由于控制平面的高可用特性决定了控制 平面无法实现灰度升级，一旦升级变更将会作用到整个集群。此外，一些企 业的应用管理特点是尽量使容器在升级过程中不发生变化，而现有的升级方 案会造成容器的驱逐以及重启等现象，用户层面会感知到变化，导致用户体 验较差。
基于此，本申请实施例提供了一种容器集群管理系统Kubernetes升级方 法，如图2所示，所述方法包括如下的步骤S210至步骤S240：
步骤S210，获取Kubernetes升级请求，其中所述Kubernetes升级请求包 括对宿主机上的低版本Kubelet进行升级的请求。
具体实施时，本申请实施例可以通过构建一个升级平台来实现 Kubernetes的升级过程，在该升级平台上可以接收到Kubernetes升级请求， 这里的Kubernetes升级请求是指将低版本的Kubernetes升级到高版本的 Kubernetes的请求，例如将Kubernetes中的低版本的Kubelet升级到高版本 的Kubelet，该升级请求中具体还可以包括升级对象，升级对象可以理解为是 指对哪个或哪些宿主机上的Kubernetes进行升级。也即本申请实施例的Kubernetes升级过程从宿主机维度来进行，这样可以在一定程度上降低集群 整体升级的风险，将风险降低到宿主机维度，一台宿主机升级失败不会影响 到集群中其它的容器和宿主机。
步骤S220，根据所述Kubernetes升级请求，将低版本集群中的Kubernetes 资源迁移到高版本集群中，所述Kubernetes资源至少包括容器。
在接收到Kubernetes升级请求后，根据该升级请求可以确定需要进行升 级的宿主机，然后将该宿主机上的低版本集群中的Kubernetes资源迁移到高 版本集群中，这里的低版本集群和高版本集群不同于前面提到的Kubernetes 集群，其可以理解为是一个由Kubernetes中各个组件构成的集群结构，迁移 可以理解为是资源或数据的拷贝过程，通过这个过程，低版本集群内的数据 仍然会保留，避免后续升级失败导致数据无法恢复的问题。
Kubernetes中的所有“对象”都可以被抽象为“资源”，如部署单元Pod、节 点对象Node等都是资源。“对象”就是“资源”的实例，是持久化的实体，如某 个具体的Pod、某个具体的Node，Kubernetes使用这些实体去表示整个集群 的状态。
本申请实施例的高版本集群可根据实际升级需要事先构建好，并在高版 本集群中搭建好高版本Kubelet所对应的控制平面组件，包括Kube-apiserver (接口服务组件)、Kuber-scheduler(调度组件)和Kube-controller-manager (控制器组件)，当然本领域技术人员也可以根据实际需要添加其它的组件， 在此不做具体限定。通过上述事先搭建好的高版本集群，可以免除升级控制 平面所带来的集群整体不稳定的风险，避免影响到整个Kubernetes集群。
步骤S230，根据所述高版本集群中的Kubernetes资源对所述高版本集群 中的容器进行更新，所述更新至少包括哈希值更新。
在完成Kubernetes资源的迁移后，由于原来低版本集群中的容器所处的 资源环境发生改变，因此需要根据高版本集群中的Kubernetes资源对迁移后 的高版本集群中的容器进行更新，这里的更新可以是指哈希值Hash的更新。
Kubernetes中的Kubelet可以将Hash(哈希值)来作为容器的唯一标识， 现有的升级方案由于不同版本间的哈希值Hash会发生变化，进而导致升级 过程中容器会发生重启，因此本申请实施例通过上述对容器哈希值Hash进 行更新和同步的过程，可以使低版本集群中的Kubernetes资源在迁移到高版 本集群中后，容器的哈希值Hash保持一致，避免容器发生重启。
步骤S240，将所述宿主机上的低版本Kubelet升级至高版本Kubelet，并 将高版本集群中更新后的容器由所述高版本Kubelet接管，以完成Kubernetes 升级过程。
在完成Kubernetes资源迁移和宿主机上的容器更新后，由于此时宿主机 的连接仍然是指向低版本Kubelet，因此需要在该宿主机上重新发布高版本 Kubelet，使宿主机的连接指向该高版本Kubelet，进而通过高版本Kubelet接 管该宿主机上的高版本集群中的容器，完成整个Kubernetes升级过程。
本申请实施例中的Kubernetes升级过程可以看作是一个热升级过程，所 谓热升级，实际上就是在程序/服务不停止的前提下，通过增加、修改、删除 相关功能模块，达到功能升级的目的。本申请实施例的Kubernetes热升级过 程，可以使宿主机上的容器在正常运行的情况下实现升级，用户无感知，大 大提高了用户体验。
如图3所示，提供了一种Kubernetes整体升级过程示意图。该Kubernetes 升级过程在升级平台上进行，实现将低版本集群中的Kubernetes资源迁移到 高版本集群中。本申请的Kubernetes升级方法可针对任意版本的Kubernetes 集群升级使用，通用性更强，并且降低了集群整体升级的风险，将风险降低 到宿主机维度，一台宿主机升级失败不会影响到Kubernetes集群中其它的容 器和宿主机。此外，本申请的Kubernetes升级方案解决了升级过程中容器重 启的问题，升级过程不会造成容器重启，用户无感知，提高了用户体验。
在本申请的一个实施例中，所述获取Kubernetes升级请求包括：根据所 述Kubernetes升级请求确定所述低版本Kubelet对应的宿主机；将所述宿主 机的状态设置为禁止调度状态。
如前所述，本申请实施例的Kubernetes升级过程可以是在宿主机维度上 进行的，用户在发起升级请求时，可以指明所要升级的宿主机，这样可以在 一定程度上降低Kubernetes集群整体升级的风险，将风险降低到宿主机维度， 一台宿主机升级失败不会影响到Kubernetes集群中其它的容器和宿主机。此 外，由于升级过程中，该宿主机上的容器仍然处于运行状态，为了避免升级 过程中该宿主机上出现创建或者删除容器等事件，可以先将该宿主机的状态 设置为禁止调度状态，即禁止为该宿主机分配新的节点Pod或者将该宿主机 上的Pod删除等，保证升级过程顺利进行。
在本申请的一个实施例中，所述将所述宿主机上的低版本Kubelet升级 至高版本Kubelet，并将高版本集群中更新后的容器由所述高版本Kubelet接 管，以完成Kubernetes升级过程包括：在所述Kubernetes升级过程完成后， 将所述宿主机的状态恢复为可调度状态。
在完成Kubernetes在该宿主机上的整个升级过程后，该宿主机即可以进 行正常的容器创建或者删除等操作了，因此此时可以将宿主机的状态恢复为 可调度状态，保证升级后的Kubernetes在该宿主机上的正常运行。
在本申请的一个实施例中，所述根据所述Kubernetes升级请求，将所述 低版本集群中的Kubernetes资源迁移到高版本集群中包括：通过Kubernetes 的接口服务接收待迁移数据，并检测所述待迁移数据中是否存在所述低版本 集群中的Kubernetes资源的唯一标识；若存在，则直接将所述低版本集群中 的Kubernetes资源的唯一标识作为所述高版本集群中的Kubernetes资源的唯 一标识，并将所述待迁移数据进行数据持久化处理后同步至键值数据库中； 若不存在，则为所述待迁移数据创建唯一标识，并将所述待迁移数据进行数 据持久化处理后同步至所述键值数据库中。
本申请实施例在将低版本集群中的Kubernetes资源迁移到高版本集群中 时，可以通过Kubernetes的接口服务Kube-apiserver来接收待迁移数据， Kube-apiserver是Kubernetes中负责提供应用程序接口服务的组件，它是 Kubernetes控制平面的前端，任何的资源请求或调用操作都是通过 Kube-apiserver提供的接口来进行的。也就是说，Kube-apiserver所接收到的 数据可能是各种各样的，因此在进行资源迁移之前可以先判断Kube-apiserver 所接收到的数据是否是升级流程的数据。
如图4所示，提供了一种资源迁移过程示意图，其中一个主要步骤就是 资源唯一标识UID(User Identification，用户标识)的检测，UID为Kubernetes 中唯一标识对象的字符串。如果待迁移数据中存在Kubernetes资源的UID， 则说明该数据可以用于升级流程，可以直接将该待迁移数据中存在 Kubernetes资源的UID作为高版本集群中的Kubernetes资源的唯一标识，并 将待迁移数据进行数据持久化处理后同步至键值数据库中，保证迁移数据在 高版本集群和低版本集群间的唯一性和一致性；如果不存在，则说明该数据 不是或无法用于升级流程，而可能是Kubernetes在正常生产环境下所产生的 用户请求数据等，此时可以为该数据资源创建唯一标识，并将该数据进行数 据持久化处理后同步至键值数据库中进行存储即可。
在本申请的一个实施例中，所述根据所述高版本集群中的Kubernetes资 源对所述高版本集群中的容器进行更新包括：获取所述低版本集群中的容器 的哈希值，作为所述高版本集群中的容器的第一哈希值；根据所述高版本集 群中的资源计算所述高版本集群中的容器的第二哈希值；对所述第二哈希值 和所述第一哈希值进行比较，当所述第二哈希值与所述第一哈希值不一致时， 根据所述第二哈希值对所述高版本集群中的容器的第一哈希值进行更新。
如图5所示，提供了一种Kubernetes中容器哈希值更新的过程示意图。 低版本集群中的容器在迁移前，低版本Kubelet可以根据低版本集群中的资 源计算得到各容器在该低版本集群中的哈希值，即第一哈希值，而在将低版 本集群中的Kubernetes资源包括容器等迁移到高版本集群后，高版本集群的 容器所处的资源环境相比低版本集群发生了变化，此时可以根据高版本集群 中的资源重新计算高版本集群中的容器的哈希值，得到第二哈希值。当第二 哈希值与第一哈希值不一致时，为了避免容器发生重启，可以利用第二哈希值对迁移后的高版本集群中的容器的哈希值进行更新和同步，保证容器哈希 值Hash的一致性。上述的容器同步更新过程可以通过Kubernetes的Docker 服务来进行管理，Docker可以用于管理Kubernetes中的各个容器并提供容器 运行时。本申请实施例的Hash更新过程无需侵入Kubernetes代码，实现了 工具化更新容器Hash，更新效率更高。
在本申请的一个实施例中，所述方法还包括：在Kubernetes升级过程中， 检测所述宿主机上是否发生容器重启事件；在发生容器重启事件的情况下， 中断所述Kubernetes升级过程并回滚所述Kubernetes升级过程中已完成的操 作。
正常来说，本申请实施例的Kubernetes升级过程不会出现容器重启等现 象，如果在Kubernetes升级过程中，一旦检测到宿主机上发生容器重启事件， 说明升级过程本身出现了问题，此时可以中断升级过程，进行故障排查，同 时由于之前的低版本集群中的数据仍然保留，可以通过回滚恢复Kubernetes 升级过程中已完成的操作，避免由于升级失败导致数据丢失等不可逆问题的 发生。
在本申请的一个实施例中，所述方法还包括：在所述Kubernetes升级过 程完成后，按照预设缩容算法对所述宿主机上的Kubernetes资源进行资源清 理。
如果宿主机上的Kubernetes升级过程顺利完成，该宿主机上的低版本集 群中所存在的资源数据可以认为是冗余数据或无用数据，按照预设缩容算法 可以对这些数据进行清理。现有技术中的缩容算通常是根据目标Pod资源的 若干属性确定需要缩容的Pod。然而这种缩容算法无法直接针对特定宿主机 上的特定Pod进行删除，因此本申请实施例对现有的缩容算法进行了修改， 进而可以实现对特定宿主机上的特定Kubernetes资源进行清理的目的，避免 对其他宿主机上的资源造成影响。
无状态应用是指在出现故障或者Pod删除时，相关资源都会释放，有状 态应用是指在Pod节点挂掉后，存储资源不会被删除，新创建的同名Pod可 以继续使用相关资源。本申请实施例的预设缩容算法主要是针对无状态应用 进行的缩容。当然本领域技术人员也可以根据实际需要对本申请实施例的方 案进行适应性调整以实现对有状态应用的缩容。
在本申请的一个实施例中，所述Kubernetes资源包括所述宿主机上的容 器所对应的部署单元Pod，所述按照预设缩容算法对所述宿主机上的低版本 Kubelet管理的低版本集群进行资源清理包括：确定所述宿主机的Pod的缩容 策略，所述缩容策略包括：所述Pod是否已被调度、所述Pod的状态、所述 Pod是否带有优先删除标记、所述Pod的准备就绪时间、所述Pod的重启次 数以及所述Pod的创建时间；根据所述缩容策略确定所述宿主机上的待清理 Pod，并将所述待清理Pod从所述宿主机上的低版本集群中清理掉。
本申请实施例对现有的宿主机的缩容策略进行了改进，增加了Pod优先 删除标记的判断，改进后的缩容策略的判断条件具体可以包括：Pod是否已 被调度、Pod的状态、Pod是否带有优先删除标记、Pod的准备就绪时间、Pod 的重启次数以及Pod的创建时间等。当然具体采用哪种或哪些缩容策略本领 域技术人员可根据实际情况灵活配置，在此不做具体限定。
对于上述改进后的缩容策略，具体可以按照下述逻辑顺序来执行，1)如 果Pod未被分配节点，则说明该Pod未被调度，则可优先进行删除；2)如 果Pod的当前状态处于挂起(Pending)/未知(Unknown)状态，则可考虑 优先删除该Pod；3)如果Pod的当前状态未处于准备就绪(Ready)状态， 则可优先进行删除；4)如果Pod添加了优先删除的标记或注解Annotations， 则可考虑优先删除该Pod；5)如果Pod准备就绪(Ready)时间较晚，则可 考虑优先删除该Pod；6)如果Pod重启次数较多，说明该Pod运行状态不够 稳定，则可考虑优先删除该Pod；7)如果Pod创建时间较晚，则可优先进行 删除。本申请实施例通过上述缩容策略，可快速定位到该宿主机上优先被清 理的Pod，提高数据清理效率和准确性。当然对于上述各判断条件之间的先 后执行顺序，本领域技术人员也可根据实际情况灵活设置，在此不做具体限 定。
如图6所示，提供了一种Kubernetes升级流程示意图。首先接收 Kubernetes升级请求，确定待升级的宿主机，并将该宿主机的状态设置为禁 止调度状态。然后将该宿主机上的低版本集群中的Kubernetes资源迁移到高 版本集群中，并根据高版本集群中的Kubernetes资源对高版本集群中的容器 的哈希值进行更新。之后在该宿主机上重新发布高版本Kubelet，将低版本 Kubelet升级至高版本Kubelet，并将高版本集群中更新后的容器由高版本 Kubelet接管，完成该宿主机上的Kubernetes的升级。最后可以将宿主机上保留的低版本集群中的资源进行清理，恢复宿主机的调度状态，进而完成整个 升级流程。
本申请实施例提供了一种容器集群管理系统Kubernetes升级装置700， 如图7所示，所述装置700包括：获取单元710、迁移单元720、更新单元 730和升级单元740。
本申请实施例的获取单元710，用于获取Kubernetes升级请求，其中所 述Kubernetes升级请求包括对宿主机上的低版本Kubelet进行升级的请求。
具体实施时，本申请实施例可以通过构建一个升级平台来实现 Kubernetes的升级过程，在该升级平台上可以接收到Kubernetes升级请求， 这里的Kubernetes升级请求是指将低版本的Kubernetes升级到高版本的 Kubernetes的请求，例如将Kubernetes中的低版本的Kubelet升级到高版本 的Kubelet，该升级请求中具体还可以包括升级对象，升级对象可以理解为是 指对哪个或哪些宿主机上的Kubernetes进行升级。也即本申请实施例的Kubernetes升级过程从宿主机维度来进行，这样可以在一定程度上降低集群 整体升级的风险，将风险降低到宿主机维度，一台宿主机升级失败不会影响 到集群中其它的容器和宿主机。
本申请实施例的迁移单元720，用于根据所述Kubernetes升级请求，将 低版本集群中的Kubernetes资源迁移到高版本集群中，所述Kubernetes资源 至少包括容器。
在接收到Kubernetes升级请求后，根据该升级请求可以确定需要进行升 级的宿主机，然后将该宿主机上的低版本集群中的Kubernetes资源迁移到高 版本集群中，这里的低版本集群和高版本集群不同于前面提到的Kubernetes 集群，其可以理解为是一个由Kubernetes中各个组件构成的集群结构，迁移 可以理解为是资源或数据的拷贝过程，通过这个过程，低版本集群内的数据 仍然会保留，避免后续升级失败导致数据无法恢复的问题。
Kubernetes中的所有“对象”都可以被抽象为“资源”，如部署单元Pod、节 点对象Node等都是资源。“对象”就是“资源”的实例，是持久化的实体，如某 个具体的Pod、某个具体的Node，Kubernetes使用这些实体去表示整个集群 的状态。
本申请实施例的高版本集群可根据实际升级需要事先构建好，并在高版 本集群中搭建好高版本Kubelet所对应的控制平面组件，包括Kube-apiserver (接口服务组件)、Kuber-scheduler(调度组件)和Kube-controller-manager (控制器组件)，当然本领域技术人员也可以根据实际需要添加其它的组件， 在此不做具体限定。通过上述事先搭建好的高版本集群，可以免除升级控制 平面所带来的集群整体不稳定的风险，避免影响到整个Kubernetes集群。
本申请实施例的更新单元730，用于根据所述高版本集群中的Kubernetes 资源对所述高版本集群中的容器进行更新，所述更新至少包括哈希值更新。
在完成Kubernetes资源的迁移后，由于原来低版本集群中的容器所处的 资源环境发生改变，因此需要根据高版本集群中的Kubernetes资源对迁移后 的高版本集群中的容器进行更新，这里的更新可以是指哈希值Hash的更新。
Kubernetes中的Kubelet可以将Hash(哈希值)来作为容器的唯一标识， 现有的升级方案由于不同版本间的哈希值Hash会发生变化，进而导致升级 过程中容器会发生重启，因此本申请实施例通过上述对容器哈希值Hash进 行更新和同步的过程，可以使低版本集群中的Kubernetes资源在迁移到高版 本集群中后，容器的哈希值Hash保持一致，避免容器发生重启。
本申请实施例的升级单元740，用于将所述宿主机上的低版本Kubelet 升级至高版本Kubelet，并将高版本集群中更新后的容器由所述高版本 Kubelet接管，以完成Kubernetes升级过程。
在完成Kubernetes资源迁移和宿主机上的容器更新后，由于此时宿主机 的连接仍然是指向低版本Kubelet，因此需要在该宿主机上重新发布高版本Kubelet，使宿主机的连接指向该高版本Kubelet，进而通过高版本Kubelet接 管该宿主机上的高版本集群中的容器，完成整个Kubernetes升级过程。
本申请实施例中的Kubernetes升级过程可以看作是一个热升级过程，所 谓热升级，实际上就是在程序/服务不停止的前提下，通过增加、修改、删除 相关功能模块，达到功能升级的目的。本申请实施例的Kubernetes热升级过 程，可以使宿主机上的容器在正常运行的情况下实现升级，用户无感知，大 大提高了用户体验。
在本申请的一个实施例中，所述获取单元710还用于：根据所述 Kubernetes升级请求确定所述低版本Kubelet对应的宿主机；将所述宿主机的 状态设置为禁止调度状态。
在本申请的一个实施例中，所述升级单元740还用于：在所述Kubernetes 升级过程完成后，将所述宿主机的状态恢复为可调度状态。
在本申请的一个实施例中，所述迁移单元720还用于：通过Kubernetes 的接口服务接收待迁移数据，并检测所述待迁移数据中是否存在所述低版本 集群中的Kubernetes资源的唯一标识；若存在，则直接将所述低版本集群中 的Kubernetes资源的唯一标识作为所述高版本集群中的Kubernetes资源的唯 一标识，并将所述待迁移数据进行数据持久化处理后同步至键值数据库中； 若不存在，则为所述待迁移数据创建唯一标识，并将所述待迁移数据进行数 据持久化处理后同步至所述键值数据库中。
在本申请的一个实施例中，所述更新单元730还用于：获取所述低版本 集群中的容器的哈希值，作为所述高版本集群中的容器的第一哈希值；根据 所述高版本集群中的资源计算所述高版本集群中的容器的第二哈希值；对所 述第二哈希值和所述第一哈希值进行比较，当所述第二哈希值与所述第一哈 希值不一致时，根据所述第二哈希值对所述高版本集群中的容器的第一哈希 值进行更新。
在本申请的一个实施例中，所述装置还包括：检测单元，用于在 Kubernetes升级过程中，检测所述宿主机上是否发生容器重启事件；中断单 元，用于在发生容器重启事件的情况下，中断所述Kubernetes升级过程并回 滚所述Kubernetes升级过程中已完成的操作。
在本申请的一个实施例中，所述装置还包括：清理单元，用于在所述 Kubernetes升级过程完成后，按照预设缩容算法对所述宿主机上的Kubernetes 资源进行资源清理。
在本申请的一个实施例中，所述Kubernetes资源包括所述宿主机上的容 器所对应的部署单元Pod，所述清理单元还用于：确定所述宿主机的Pod的 缩容策略，所述缩容策略包括：所述Pod是否已被调度、所述Pod的状态、 所述Pod是否带有优先删除标记、所述Pod的准备就绪时间、所述Pod的重 启次数以及所述Pod的创建时间；根据所述缩容策略确定所述宿主机上的待 清理Pod，并将所述待清理Pod从所述宿主机上的低版本集群中清理掉。
需要说明的是，上述各装置实施例的具体实施方式可以参照前述对应方 法实施例的具体实施方式进行，在此不再赘述。
综上所述，本申请的技术方案，通过获取Kubernetes升级请求，其中所 述Kubernetes升级请求包括对宿主机上的低版本Kubelet进行升级的请求； 根据所述Kubernetes升级请求，将低版本集群中的Kubernetes资源迁移到高 版本集群中，所述Kubernetes资源至少包括容器；根据所述高版本集群中的 Kubernetes资源对所述高版本集群中的容器进行更新，所述更新至少包括哈 希值更新；将所述宿主机上的低版本Kubelet升级至高版本Kubelet，并将高 版本集群中更新后的容器由所述高版本Kubelet接管，以完成Kubernetes升 级过程。本申请的Kubernetes升级方法可针对任意版本的Kubernetes集群升 级使用，通用性更强。本申请降低了集群整体升级的风险，将风险降低到宿 主机维度，一台宿主机升级失败不会影响到集群中其它的容器和宿主机。此 外，本申请解决了升级过程中容器重启的问题，升级不会造成容器重启，用 户无感知，提高了用户体验。
需要说明的是：
在此提供的算法和显示不与任何特定计算机、虚拟装置或者其它设备固 有相关。各种通用装置也可以与基于在此的示教一起使用。根据上面的描述， 构造这类装置所要求的结构是显而易见的。此外，本申请也不针对任何特定 编程语言。应当明白，可以利用各种编程语言实现在此描述的本申请的内容， 并且上面对特定语言所做的描述是为了披露本申请的最佳实施方式。
在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本 申请的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未 详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。
类似地，应当理解，为了精简本申请并帮助理解各个发明方面中的一个 或多个，在上面对本申请的示例性实施例的描述中，本申请的各个特征有时 被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开 的方法解释成反映如下意图：即所要求保护的本申请要求比在每个权利要求 中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映 的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循 具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本申请的单独实施例。
本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自 适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以 把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可 以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者 单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴 随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或 者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴 随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相 似目的的替代特征来代替。
此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其 它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组 合意味着处于本申请的范围之内并且形成不同的实施例。例如，在下面的权 利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使 用。
本申请的各个部件实施例可以以硬件实现，或者以在一个或者多个处理 器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当 理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据 本申请实施例的容器集群管理系统Kubernetes升级装置中的一些或者全部部 件的一些或者全部功能。本申请还可以实现为用于执行这里所描述的方法的 一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产 品)。这样的实现本申请的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或 者在载体信号上提供，或者以任何其他形式提供。
例如，图8示出了根据本申请一个实施例的电子设备的结构示意图。该 电子设备800包括处理器810和被安排成存储计算机可执行指令(计算机可 读程序代码)的存储器820。存储器820可以是诸如闪存、EEPROM(电可 擦除可编程只读存储器)、EPROM、硬盘或者ROM之类的电子存储器。存 储器820具有存储用于执行上述方法中的任何方法步骤的计算机可读程序代 码831的存储空间830。例如，用于存储计算机可读程序代码的存储空间830可以包括分别用于实现上面的方法中的各种步骤的各个计算机可读程序代 码831。计算机可读程序代码831可以从一个或者多个计算机程序产品中读 出或者写入到这一个或者多个计算机程序产品中。这些计算机程序产品包括 诸如硬盘，紧致盘(CD)、存储卡或者软盘之类的程序代码载体。这样的计 算机程序产品通常为例如图9所示的计算机可读存储介质。图9示出了根据 本申请一个实施例的一种计算机可读存储介质的结构示意图。该计算机可读 存储介质900存储有用于执行根据本申请的方法步骤的计算机可读程序代码 831，可以被电子设备800的处理器810读取，当计算机可读程序代码831 由电子设备800运行时，导致该电子设备800执行上面所描述的方法中的各 个步骤，具体来说，该计算机可读存储介质存储的计算机可读程序代码831 可以执行上述任一实施例中示出的方法。计算机可读程序代码831可以以适 当形式进行压缩。
应该注意的是上述实施例对本申请进行说明而不是对本申请进行限制， 并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换 实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利 要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于 元件之前的单词“一”或“一个”不排除存在多个这样的元件。本申请可以借助 于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举 了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件 项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将 这些单词解释为名称。
Claims (11)
1.一种容器集群管理系统Kubernetes升级方法，其特征在于，包括：
获取Kubernetes升级请求，其中所述Kubernetes升级请求包括对宿主机上的低版本Kubelet进行升级的请求；
根据所述Kubernetes升级请求，将低版本集群中的Kubernetes资源迁移到高版本集群中，所述Kubernetes资源至少包括容器；
根据所述高版本集群中的Kubernetes资源对所述高版本集群中的容器进行更新，所述更新至少包括哈希值更新；
将所述宿主机上的低版本Kubelet升级至高版本Kubelet，并将高版本集群中更新后的容器由所述高版本Kubelet接管，以完成Kubernetes升级过程。
2.根据权利要求1所述的容器集群管理系统Kubernetes升级方法，其特征在于，所述获取Kubernetes升级请求包括：
根据所述Kubernetes升级请求确定所述低版本Kubelet对应的宿主机；
将所述宿主机的状态设置为禁止调度状态。
3.根据权利要求2所述的容器集群管理系统Kubernetes升级方法，其特征在于，所述将所述宿主机上的低版本Kubelet升级至高版本Kubelet，并将高版本集群中更新后的容器由所述高版本Kubelet接管，以完成Kubernetes升级过程包括：
在所述Kubernetes升级过程完成后，将所述宿主机的状态恢复为可调度状态。
4.根据权利要求1所述的容器集群管理系统Kubernetes升级方法，其特征在于，所述根据所述Kubernetes升级请求，将所述低版本集群中的Kubernetes资源迁移到高版本集群中包括：
通过Kubernetes的接口服务接收待迁移数据，并检测所述待迁移数据中是否存在所述低版本集群中的Kubernetes资源的唯一标识；
若存在，则直接将所述低版本集群中的Kubernetes资源的唯一标识作为所述高版本集群中的Kubernetes资源的唯一标识，并将所述待迁移数据进行数据持久化处理后同步至键值数据库中；
若不存在，则为所述待迁移数据创建唯一标识，并将所述待迁移数据进行数据持久化处理后同步至所述键值数据库中。
5.根据权利要求1所述的容器集群管理系统Kubernetes升级方法，其特征在于，所述根据所述高版本集群中的Kubernetes资源对所述高版本集群中的容器进行更新包括：
获取所述低版本集群中的容器的哈希值，作为所述高版本集群中的容器的第一哈希值；
根据所述高版本集群中的资源计算所述高版本集群中的容器的第二哈希值；
对所述第二哈希值和所述第一哈希值进行比较，当所述第二哈希值与所述第一哈希值不一致时，根据所述第二哈希值对所述高版本集群中的容器的第一哈希值进行更新。
6.根据权利要求1所述的容器集群管理系统Kubernetes升级方法，其特征在于，所述方法还包括：
在Kubernetes升级过程中，检测所述宿主机上是否发生容器重启事件；
在发生容器重启事件的情况下，中断所述Kubernetes升级过程并回滚所述Kubernetes升级过程中已完成的操作。
7.根据权利要求1所述的容器集群管理系统Kubernetes升级方法，其特征在于，所述方法还包括：
在所述Kubernetes升级过程完成后，按照预设缩容算法对所述宿主机上的Kubernetes资源进行资源清理。
8.根据权利要求7所述的容器集群管理系统Kubernetes升级方法，其特征在于，所述Kubernetes资源包括所述宿主机上的容器所对应的部署单元Pod，所述按照预设缩容算法对所述宿主机上的低版本Kubelet管理的低版本集群进行资源清理包括：
确定所述宿主机的Pod的缩容策略，所述缩容策略包括：所述Pod是否已被调度、所述Pod的状态、所述Pod是否带有优先删除标记、所述Pod的准备就绪时间、所述Pod的重启次数以及所述Pod的创建时间；
根据所述缩容策略确定所述宿主机上的待清理Pod，并将所述待清理Pod从所述宿主机上的低版本集群中清理掉。
9.一种容器集群管理系统Kubernetes升级装置，其特征在于，包括：
获取单元，用于获取Kubernetes升级请求，其中所述Kubernetes升级请求包括对宿主机上的低版本Kubelet进行升级的请求；
迁移单元，用于根据所述Kubernetes升级请求，将低版本集群中的Kubernetes资源迁移到高版本集群中，所述Kubernetes资源至少包括容器；
更新单元，用于根据所述高版本集群中的Kubernetes资源对所述高版本集群中的容器进行更新，所述更新至少包括哈希值更新；
升级单元，用于将所述宿主机上的低版本Kubelet升级至高版本Kubelet，并将高版本集群中更新后的容器由所述高版本Kubelet接管，以完成Kubernetes升级过程。
10.一种电子设备，其中，该电子设备包括：处理器；以及被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器执行如权利要求1至8中任一项所述的容器集群管理系统Kubernetes升级方法。
11.一种计算机可读存储介质，其中，所述计算机可读存储介质存储一个或多个程序，所述一个或多个程序当被处理器执行时，实现如权利要求1至8中任一项所述的容器集群管理系统Kubernetes升级方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010716323.6A CN111897558A (zh) | 2020-07-23 | 2020-07-23 | 容器集群管理系统Kubernetes升级方法和装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010716323.6A CN111897558A (zh) | 2020-07-23 | 2020-07-23 | 容器集群管理系统Kubernetes升级方法和装置 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN111897558A true CN111897558A (zh) | 2020-11-06 |
Family
ID=73189807
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010716323.6A Pending CN111897558A (zh) | 2020-07-23 | 2020-07-23 | 容器集群管理系统Kubernetes升级方法和装置 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111897558A (zh) |
Cited By (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112650624A (zh) * | 2020-12-25 | 2021-04-13 | 浪潮(北京)电子信息产业有限公司 | 一种集群升级方法、装置、设备及计算机可读存储介质 |
| CN112835685A (zh) * | 2021-03-31 | 2021-05-25 | 中国工商银行股份有限公司 | 容器内存调整方法及装置 |
| CN113297031A (zh) * | 2021-05-08 | 2021-08-24 | 阿里巴巴新加坡控股有限公司 | 容器集群中的容器组防护方法及装置 |
| CN113422700A (zh) * | 2021-06-22 | 2021-09-21 | 汇付天下有限公司 | 无感升级方法及无感升级装置 |
| CN113626054A (zh) * | 2021-08-16 | 2021-11-09 | 聚好看科技股份有限公司 | 一种业务服务更新方法及装置 |
| CN113760461A (zh) * | 2021-09-07 | 2021-12-07 | 新华智云科技有限公司 | 一种版本升级方法及计算机可读存储介质 |
| CN114172808A (zh) * | 2021-12-07 | 2022-03-11 | 中国电信股份有限公司 | Kubernetes集群升级方法、系统、设备及存储介质 |
| CN114172729A (zh) * | 2021-12-08 | 2022-03-11 | 中国电信股份有限公司 | 基于容器的可信迁移方法和设备及存储介质 |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107515776A (zh) * | 2017-07-18 | 2017-12-26 | 深信服科技股份有限公司 | 业务不间断升级方法、待升级节点和可读存储介质 |
| US20190095253A1 (en) * | 2017-09-22 | 2019-03-28 | Vmware, Inc. | Cluster updating using temporary update-monitor pod |
| CN110286930A (zh) * | 2019-06-27 | 2019-09-27 | 腾讯科技（深圳）有限公司 | 一种云平台升级方法、装置、终端及存储介质 |
| CN110377395A (zh) * | 2019-07-03 | 2019-10-25 | 无锡华云数据技术服务有限公司 | 一种Kubernetes集群中的Pod迁移方法 |
| US20200153898A1 (en) * | 2018-11-13 | 2020-05-14 | International Business Machines Corporation | Automated infrastructure updates in a cluster environment that includes containers |
| CN111258609A (zh) * | 2020-01-19 | 2020-06-09 | 北京百度网讯科技有限公司 | Kubernetes集群的升级方法、装置、电子设备和介质 |
-
2020
- 2020-07-23 CN CN202010716323.6A patent/CN111897558A/zh active Pending
Patent Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107515776A (zh) * | 2017-07-18 | 2017-12-26 | 深信服科技股份有限公司 | 业务不间断升级方法、待升级节点和可读存储介质 |
| US20190095253A1 (en) * | 2017-09-22 | 2019-03-28 | Vmware, Inc. | Cluster updating using temporary update-monitor pod |
| US20200153898A1 (en) * | 2018-11-13 | 2020-05-14 | International Business Machines Corporation | Automated infrastructure updates in a cluster environment that includes containers |
| CN111176804A (zh) * | 2018-11-13 | 2020-05-19 | 国际商业机器公司 | 包括容器的集群环境中的自动基础设施更新 |
| CN110286930A (zh) * | 2019-06-27 | 2019-09-27 | 腾讯科技（深圳）有限公司 | 一种云平台升级方法、装置、终端及存储介质 |
| CN110377395A (zh) * | 2019-07-03 | 2019-10-25 | 无锡华云数据技术服务有限公司 | 一种Kubernetes集群中的Pod迁移方法 |
| CN111258609A (zh) * | 2020-01-19 | 2020-06-09 | 北京百度网讯科技有限公司 | Kubernetes集群的升级方法、装置、电子设备和介质 |
Cited By (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112650624A (zh) * | 2020-12-25 | 2021-04-13 | 浪潮(北京)电子信息产业有限公司 | 一种集群升级方法、装置、设备及计算机可读存储介质 |
| CN112650624B (zh) * | 2020-12-25 | 2023-05-16 | 浪潮(北京)电子信息产业有限公司 | 一种集群升级方法、装置、设备及计算机可读存储介质 |
| CN112835685A (zh) * | 2021-03-31 | 2021-05-25 | 中国工商银行股份有限公司 | 容器内存调整方法及装置 |
| CN113297031A (zh) * | 2021-05-08 | 2021-08-24 | 阿里巴巴新加坡控股有限公司 | 容器集群中的容器组防护方法及装置 |
| CN113422700A (zh) * | 2021-06-22 | 2021-09-21 | 汇付天下有限公司 | 无感升级方法及无感升级装置 |
| CN113422700B (zh) * | 2021-06-22 | 2022-04-26 | 汇付天下有限公司 | 无感升级方法及无感升级装置 |
| CN113626054A (zh) * | 2021-08-16 | 2021-11-09 | 聚好看科技股份有限公司 | 一种业务服务更新方法及装置 |
| CN113760461A (zh) * | 2021-09-07 | 2021-12-07 | 新华智云科技有限公司 | 一种版本升级方法及计算机可读存储介质 |
| CN113760461B (zh) * | 2021-09-07 | 2023-09-05 | 新华智云科技有限公司 | 一种版本升级方法及计算机可读存储介质 |
| CN114172808A (zh) * | 2021-12-07 | 2022-03-11 | 中国电信股份有限公司 | Kubernetes集群升级方法、系统、设备及存储介质 |
| CN114172729A (zh) * | 2021-12-08 | 2022-03-11 | 中国电信股份有限公司 | 基于容器的可信迁移方法和设备及存储介质 |
| CN114172729B (zh) * | 2021-12-08 | 2024-03-26 | 中国电信股份有限公司 | 基于容器的可信迁移方法和设备及存储介质 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111897558A (zh) | 容器集群管理系统Kubernetes升级方法和装置 | |
| US10635473B2 (en) | Setting support program, setting support method, and setting support device | |
| US9442813B2 (en) | Replaying jobs at a secondary location of a service | |
| US9405630B2 (en) | Methods and apparatus to perform site recovery of a virtual data center | |
| US10949401B2 (en) | Data replication in site recovery environment | |
| JP2014142678A (ja) | 仮想サーバ移行計画作成方法およびシステム | |
| US20210311717A1 (en) | Desired state model for managing lifecycle of virtualization software | |
| US8990608B1 (en) | Failover of applications between isolated user space instances on a single instance of an operating system | |
| US11650804B2 (en) | Validation of desired software state image for hardware incompatibilities | |
| US20230342181A1 (en) | Validation of combined software/firmware updates | |
| CN111506388A (zh) | 容器性能探测方法、容器管理平台及计算机存储介质 | |
| US11461131B2 (en) | Hosting virtual machines on a secondary storage system | |
| CN115858086A (zh) | 数据恢复方法、数据恢复系统、设备及存储介质 | |
| US11573779B2 (en) | Creating and upgrading of solutions for deployment in a virtualized computing environment | |
| CN115277398A (zh) | 一种集群的网络配置方法和装置 | |
| CN109101253B (zh) | 云计算系统中主机的管理方法和装置 | |
| CN113703823A (zh) | 一种bmc固件升级方法、装置、电子设备及存储介质 | |
| US10877771B2 (en) | Virtual machine booting using disk metadata | |
| CN113157476A (zh) | 虚拟云环境中显卡故障的处理方法及装置 | |
| US11435996B2 (en) | Managing lifecycle of solutions in virtualization software installed in a cluster of hosts | |
| US20230305900A1 (en) | Workload execution on backend systems | |
| US11435997B2 (en) | Desired state model for managing lifecycle of virtualization software installed in heterogeneous cluster of hosts | |
| US20220188091A1 (en) | Automatic self-adjusting software image recommendation | |
| CN113760446A (zh) | 资源调度方法、装置、设备及介质 | |
| CN117097615A (zh) | 容器集群扩容的控制方法、装置和电子设备 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |