Kubernetes集群通常使用 Kubeadm进行版本升级，当前支持跨一个大版本的升级，例如从 1.19.x 升级到 1.20.x，不支持一个大版本内的不同小版本之间的升级，也不支持跨超过 1 个以上的大版本进行升级。

在进行一个Kubernetes 集群版本升级过程中，集群应始终保持在可用状态，集群中已经部署的业务对于升级过程也是无感知的 (如果要做到完全无感知，需要业务使用的存储可以随着 Pod 的驱逐实现跨节点迁移) 。

本文中以从1.19.0升级到1.20.0为例进行说明，具体升级方法是针对不同类型的节点上的组件分别进行升级。例中的升级步骤主要分为以下4 步：

• 集群预检

• 升级控制平面

• 升级数据平面

• 升级其它组件

预检这一步骤主要是为了在 Kubernetes 升级之前对集群的各个组件的状态进行检测，以便提高集群升级的成功率，当检测出现异常时则停止后续的升级步骤。预检的内容主要包括两大类：

集群节点环境的检查：

• 虚机或者裸机节点的健康状态检查

• 节点内部系统服务的检查：例如NTP、防火墙、内核配置等

• 多Master集群的控制平面和数据平面的高可用状态的检查

• 等等

集群K8s状态的检查：

• 控制面和数据面节点是否都处于 Ready 状态。

• Etcd 集群的可用状态检

• 负载和服务的可用状态检查

• 等等

注意:

• 上面检查的步骤都不是必须实现的，可以根据需要选择一些来完成。

• 除了上述预检之外，kubeadm在执行升级步骤中也会进行即时性的环境检测，以保证升级的成功率。

升级控制平面（Master节点）

控制平面主要是指Master节点上的以下组件：

• Kubernetes API Server

• Kubernetes Scheduler

• Kubernetes Controller Manager

• Kubelet

• Kubeadm

第一步、在 Master 节点上安装新版本的 kubeadm

第二步、执行以下命令进行升级：

kubeadm upgrade apply v1.20.0

此升级过程会针对 Kubernetes API Server、Kubernetes Scheduler 和 Kubernetes Controller Manager 这三个组件生成新版本的配置文件覆盖旧版本的，Master 节点上的 Kubelet 会 Watch 到这些改动，会重建对应的 Pod。另外还会重新生成 Kube-Proxy DaemonSet 的配置，Node 节点上所有的 Kube-Proxy 相关的 Pod 会进行重建。

第三步、腾空节点

通过将节点标记为不可调度并腾空节点为节点作升级准备：

kubectl drain node_name --ignore-daemonsets

第四步、升级 Kubelet

升级后需要重启 Kubelet

sudo systemctl daemon-reload

sudo systemctl restart kubelet

第五步、解除节点的保护

通过将节点标记为可调度，让其重新上线：

kubectl uncordon node_name

如果集群的控制平面是 HA 的情况，在 API Server 前端应该有类似 HAProxy的负载均衡软件，高可用依赖 HAProxy 对于后端的 API Server 周期性的检测机制，如果某个 Mater 正在升级，这时 HAProxy 会检测到，然后后续的请求就不会转发到这个 Master 节点。等升级完成后，状态恢复正常，这时 HAProxy 将其作为正常的后端进行请求转发。

数据平面是指 Node节点上的Kubectl和Kubelet等组件。

如果用户的某个应用只有一个 Pod，这种情况下无法做到升级过程中业务不会中断。另外，如果Kubernetes集群只有一个Node节点，在这升级这一个Node节点的过程中，这个Pod会被驱逐，并且由于没有其它节点可以调度，因此会一直处于pending状态，在这段时间内业务会完全中断。

第一步、在 Node 节点上安装新版本的kubectl。

第二步、腾空节点

通过将节点标记为不可调度并腾空节点为节点作升级准备：

kubectl drain node_name --ignore-daemonsets

注意，这一步需要保证业务流量不受到影响，如果某个业务有多个 Pod，则需要保证其它节点上的 Pod 处于正常运行状态。

第三步、升级 Kubelet

升级后需要重启 Kubelet

sudo systemctl daemon-reload

sudo systemctl restart kubelet

第四步、解除节点的保护

通过将节点标记为可调度，让其重新上线：

kubectl uncordon node_name

其它组件不仅包括CNI Driver、CSI Driver等基础能力组件，还包括Ingress Controller、Dashboard、Prometheus、Metric-Server 等用户或管理员安装的辅助组件。

当 Kubernetes 集群进行版本升级时，这些组件是否需要升级或者变更需要参考各组件与 Kubernetes 的版本兼容性，本文不再进行深入阐述。

关于 "腾空节点"的操作

在升级控制平面和数据平面的时候都要先做一个"腾空节点"的操作，这个操作会首先驱逐当前节点上的 Pod(不包含控制面Pod和DaemonSet的Pod)，然后将当前节点标记为不可调度。待升级完成后，执行 uncordon 命令将节点恢复正常状态。这是 Kubernetes 官方推荐的维护某一个节点的标准流程。

如果一个节点同时作为 Master 和 Node 节点，如何处理？

按照正常的控制面升级流程即可。

API 转换的问题

目前，整个升级过程，不会涉及到具体业务的 API 升级问题，比如从alpha升级到beta版本。用户如果有这方面的需求，可以使用 kubectl convert 命令在不同 API 版本之间转换清单。例如：kubectl convert -f pod.yaml --output-version v1 & kubectl apply -fpod.yaml 的内容，在新的清单文件中，kind 被设置为 Pod(未变)，但 apiVersion 则被修订了。

升级后，负载是否需要手动重启

升级后，因为容器的 spec 中的哈希值已更改，所有容器都会被重新启动。由于在升级数据面的时候已经对 Pod 做了驱逐操作，因此所有的Pod 都已经完成了重建操作。