了解了两种集群升级方式之后，我们以阿里云容器服务Kubernetes目前所支持的原地升级方式为例，对集群升级功能展开讲解。
首先我们来看集群升级状态机。如图12-4所示，客户进行升级操作之后，集群的状态会从“运行中”转换为“升级中”状态，如果升级顺利结束，则集群会转入“运行中”状态。
如果客户主动暂停升级，或者遭遇升级失败，那么集群会转为集群暂停状态。在升级暂停状态中的集群会暂停集群升级的进程，已经开始升级的节点会继续升级直到完成，没开始升级的节点则不会继续升级。
在暂停状态之下，我们可以将集群状态转为“升级中”，也可以取消本次升级。取消升级之后集群的状态会转为“运行中”。这时已经完成升级的节点不会回滚，未升级的节点也不会继续升级。
图12-4 集群升级状态机
整体升级过程如图12-5所示，可以划分为如下三个步骤。
（1）滚动升级Master节点。
（2）分批升级Worker节点。
（3）升级核心系统组件。
图12-5 集群升级过程
下面我们来对三个步骤中的具体操作进行介绍。
升级集群的第一步是升级Master节点。因为Kubernetes社区会保证Master对Kubelet有向下两个版本的兼容性，例如1.16版的Master可以兼容1.14版的Kubelet。但是Kubernetes社区不保证低版本Kubelet对高版本Master的兼容性。
在前面章节我们介绍过，Master上运行的主要是kube-apiserver、kube-scheduler和kube-controller-manager三大管控组件。升级Master主要就是对这三大组件的升级。
在专有版集群中，Master三大组件是依靠静态Pod机制运行的，所以升级过程中会依次在所有Master节点上进行如下操作。
（1）备份节点上的相关配置，主要包括系统组件的Yaml文件。
（2）修改节点的上配置文件，以适应新版本的Kubernetes。
（3）升级节点上的kubeadm（升级static Pod的工具）。
（4）使用kubeadm将static Pod升级到目标版本。
（5）升级节点上的GPU相关配置（如果有的话）。
（6）根据备份信息对全新的static Pod进行个性化配置。
在托管版集群中，Master是部署在管控集群中的三个Deployment。我们在对Master进行升级的时候，需要将这三个Deployment更新为目标版本。
在完成Master升级之后，我们就可以开始对Worker节点进行升级了。节点的版本是通过节点上的Kubelet进行上报的，也就是说Kubelet的版本号决定了节点的版本号。
节点升级的主要工作，是升级Kubelet核心组件及其相关配置，具体操作如下。
（1）备份节点上的相关配置，包括Kubelet的配置文件等。
（2）将节点上的CNI升级到与目标版本相匹配的版本。
（3）将节点上的Kubectl升级到目标版本。
（4）将节点上的Kubelet升级到目标版本。
（5）根据节点的信息和Kubelet的目标版本对其进行个性化配置。
为了控制节点的升级节奏，更好地控制原地升级带来的风险，我们自主研发了用于控制升级任务的CRD。这个CRD的开源版本就是OpenKruise中的BroadcastJob。通过使用该CRD的能力，用户可以对升级过程执行以下精细化的操作。
● 升级暂停：暂停正在进行的升级任务，已经开始升级的节点会完成升级，没开始升级的节点会暂停升级。
● 升级恢复：继续整个升级流程，开始对未升级的节点进行升级。
● 升级取消：在暂停整个升级流程后，可以取消本次集群升级。取消升级后，已经完成升级的节点不会回滚，尚未进行升级的节点不会进行升级。
● 批量升级：可以对每个批次升级的节点数目进行控制。
● 慢启动：再开始启动升级后，第一批次先对一个节点进行升级，后面每批次升级的节点数按2的幂指数规律增长，直到达到设定的批次最大值（默认为10%）。
在成功升级Master与Worker之后，我们会对集群中的核心组件进行升级。目前跟随Kubernetes一起进行升级的核心组件主要为kube-proxy和CoreDNS。
其中kube-proxy的版本号是跟随Kubernetes集群的版本进行统一管理的，两者的版本号是一致的。我们在升级Kubernetes集群的过程中，会将kube-proxy升级到相应的版本。
而CoreDNS有着自己的版本声明管理周期，其版本号并不与Kubernetes保持一致。为了保证CoreDNS与Kubernetes的版本兼容性，Kubernetes社区为CoreDNS的版本与Kubernetes版本设定了一个对应矩阵。在升级Kubernetes集群的过程中，我们会按照版本矩阵将CoreDNS升级到对应的版本。