开发者学堂课程【云原生实践公开课：第五步如何升级一个Kubernetes集群】学习笔记，与课程紧密联系，让用户快速学习知识
课程地址：https://developer.aliyun.com/learning/course/698/detail/12270
第五步如何升级一个Kubernetes集群
内容介绍：
一、 升级的必要性&难点
二、 两种常见的升级方式
三、 集群升级三部曲
四、 升级一个ACK集群
一、 升级的必要性&难点
集群升级的必要性&难点
在Kubernetes领域，得益于活跃的开源社区，Kubernetes 的迭代速度较快，目前保持在每个季度发行一个新版本的节奏。新版本的
Kubernetes有着更为先进的新特性、更加全面的安全加固和漏洞修复。
1. 集群升级的必要性:
- 可以使用新的feature，新的安全补丁，和诸多的 bugfix，充分享受Kubernetes
社区的发展红利。
- 对于多集群的用户可以对集群的版本进行收敛，拉齐所管理的集群版本，从而
减少维护成本。
2. 集群升级的难点
- 集群经过长时间的运行，积累了复杂的运行时状态。
- 集群已经被进行了各种个性化配置。
那么这个时候再去对集群进行升级，就相当于是“给飞行中的飞机换引擎”，是一个非常复杂的事情。
二、 两种常见的升级方式
1. 两种常见的升级方式–原地升级
在软件升级领域，有两种主流的软件升级方式，即原地升级和替换升级。这两种升级方式同样适用于 Kubernetes 集群。这两种方式采用了不同的思路，存在着各自的利弊。
原地升级:
原地升级会通过在 ECS 上原地替换 Kubernetes 组件的方式，完成整个集群的升级工作。阿里云容器服务 Kubernetes 为客户提供的集群升级就是基于这种方式的。
以版本1.14升级到1.16为例，会通过直接升级节点上 Kubelet 及其配置的方式，将集群所有节点升级到1.16。好处是，在这个过程中节点保持运行，ECS的相关配置也不会被修改。如图所示。
原地升级会通过在 ECS 上原地替换 Kubernetes 组件的方式，完成整个集群的升级工作。阿里云容器服务 Kubernetes 为客户提供的集群升级就是基于这种方式的。
优点:
原地升级通过原地替换的方式对节点进行升级，从而保证了节点上的Pod不会因为集群升级而重建，确保了业务的连贯性。该种升级方式不对底层ECS进行修改和替换，保证了依赖特定节点调度的业务可以正常运行，也对ECS的包年包月客户更加友好。
缺点:
原地升级方式需要在节点上进行一系列升级操作，才能完成整个节点的升级工作。这就导致整个升级过程不够原子化，可能会在中间的某一步骤失败，从而导致该节点升级失败。原地升级的另一个缺点是需要预留一定量的资源，只有在资源足够的情况下升级程序才能在ECS上完成对节点的升级。
2. 两种常见的升级方式–替换升级
在软件升级领域，有两种主流的软件升级方式，即原地升级和替换升级。这两种升级方式同样适用于 Kubernetes 集群。这两种方式采用了不同的思路，存在着各自的利弊。
替换升级:
替换升级又称轮转升级。替换升级会逐个将旧版本的节点从集群中移除，并用新版本全新的节点来替换，从而完成整个 Kubernetes 集群的升级工作。
同样以版本1.14升级到1.16为例，替代轮转方式，会将集群中1.14版本的节点依次进行排水并从集群中移除，并直接加入1.16版本的节点。完成所有节点的轮转之后，整个集群就升级到1.16了。如图所示。
替换升级又称轮转升级。替换升级会逐个将旧版本的节点从集群中移除，并用新版本全新的节点来替换，从而完成整个Kubernetes集群的升级工作。
优点:
替代升级通过将旧版本的节点替换为新版本的节点从而完成集群升级。这个替换的过程相较于原地升级更为原子化，也不存在那么复杂的中间状态。所以也不需要在升级之前进行太多的前置检查。
缺点:
- 替代升级将集群内的节点全部进行替换和重置，所有节点都会经历排水的过
程，这就会使集群内的pod进行大量的迁移重建。对于pod重建容忍度比较低的业务、只有单副本的应用、stateful set相关应用可能会因此发生不可用或者故障。
- 节点经历重置，储存在节点本地磁盘上的数据都会丢失。
- 这种升级方式可能会带来宿主机IP变化等问题，对包年包月用户也不够友好。
三、集群升级三部曲
前面的课程中，已经了解到，一个Kubernetes集群主要由master , worker和众多系统组件组成。那么对一个Kubernetes集群升级，也就是对集群中的这三个部分进行分别升级。故集群升级的三部曲为:
- 滚动升级master
- 分批升级worker
- 系统组价升级( CoreDNS，kube-proxy)
滚动升级 master:
升级 master 主要是对管控面的三大件进行版本升级，主要包括:
- 升级kube-apiserver
- 升级kube-controller-manager
- 升级kube-scheduler
为了保证 Kubernetesapiserver 的可用性不中断，kube-apiserver最少需要有两个，这样才可以实现滚动升级。
分批升级worker:
Worker升级主要是对节点上的kubelet及其依赖组件(如cni等)进行升级。为了保证集群中worker不会同时发生大批量的 kubelet重启，所以需要对worker节点进行分批升级。
核心系统组件:
为了保证集群中各个组件的兼容性，需要在升级集群的同时对集群中的核心系统组件进行同步升级，主要包括
- Dns组件:CoreDNS
- 网络转发组件:Kube-proxy
四、 升级一个ACK集群
ACK中提供了成熟稳定的集群升级功能。为客户提供了各项高阶功能。
- 前置检查:检查集群中潜在的隐患，确保集群升级平稳运行;
- 升级暂停:可以随时暂停集群升级，检查集群中应用的状态;
- 升级取消:可以在暂停升级之后取消升级
1. 手动升级一个ACK集群
演示：
首先打开容器服务的控制台，点击急需升级，来到了急需升级的页面。看到kubelet的版本是1.14.8,可以通过console命令查看APSO的版本，可以看到的Gitversion也是1.14. 8的。
开始集群的升级操作，来到集群升级页面，点击升级，可以看到，最先触发的是集训升级的前置检查功能，前置检查功能会帮检查集群的各项升级隐患。
完成了集群升级的前置检查工作，并且master已经完成升级，对升级进行一下暂停。可以再通过control命令去查看一下对应的APSO的版本，可以看到Gitversion已经从1.14.8升级到了1.16.9。
继续点击升级，设计管控系统会对集群内的所有 Kubernetes 节点进行升级。可以在这里看到节点的升级进度。
为了实现，原地升级，可以看到在 kube-upgrade 这个 name space，下面运行的一些升级的 completed。目前已经有一个 completed 是处于完成状态了，说明已经有一个节点完成升级，可以查看该节点的情况。可以看到已经有一个节点升级到1.16.9。
第二个节点的升级任务还在 running中，等待第二个节点升级完成。
进行升级的页面上，实时查看整个升级的进度。可以看到已经完成了整个地区的升级。
目前。正在进行相关资源的一个清理工作。可以看到。Kubectl get ns 证明用的 ns已经被删除掉了，然后来看一下整个node个审计情况。好，可以看到三个node都已经完成了升级。然后整个集群，已经完成了升级工作，整个地区已经成功从1.14.8升级到了1.16.9，这样就动手完成了一个 ACK 集群的升级工作。
总结起来主要有以下几个步骤，
(1） 在容器服务控制台，点击集群升级
(2） 在升级页面点击升级
(3） 等待前置检查完成
(4） 等待升级 master 完成
(5） 等待升级 worker 完成
(6） 集群升级完成
2. 集群升级的状态机
从一个集群正在运行中，开始升级到升级中，然后可以点击暂停，点击继续升级。从完全升级也可以再升级，暂停的时候取消升级，然后集群也会回到一个运行中的过程。
