一、需求
k8s 1.18.5的环境升级到1.21.5版本，预期目标是：
1.升级过程中k8s集群正常运行
2.运行在k8s集群中的业务不中断
3.升级过程中失败能快速回退
二、思路
Kubernetes版本号格式为x.y.z，其中x为大版本号，y为小版本号，z为补丁版本，各个组件之间最大的版本偏差如下（参考Kubernetes版本偏差）：
- kube-apiserver之间最多差一个小版本，如果升级了一个实例至1.21，那么其他的apiserver的版本号必须是1.21或者1.20；
- kubelet最多比apiserver低2个小版本，不能高于apiserver,，如果3个apiserver实例的版本号都是1.21了，那么kubelet可以是1.21、1.20或者1.19；
- kube-controller-mannager、kube-scheduler不能高于apiserver，允许比kube-apiserver低一个版本；
- kubectl 与apiserver的偏差允许在一个小版本以内，如果apiserver是1.20，那么kubectl可以是1.21,1.20,1.19；
- kube-proxy必须跟节点上的kubelet版本号一致，kube-proxy不能比kube apiserver新,kube-proxy最多比apiserver低2个小版本。
受限于上述因素，从1.18.5升级到1.21.5要达到k8s服务不中断的的效果必须得经过1.19、1.20版本过渡，更新各个组件的配置文件、二进制文件或者是镜像，基本思路如下：
（1）先逐台升级apiserver到1.19，然后再逐台升级kube-controller-mannager、kube-scheduler到1.19
（2）逐台升级kubectl到1.20
（3）先逐台升级apiserver到1.20，然后再逐台升级kube-controller-mannager、kube-scheduler到1.20
（4）kubelet允许比apiserver低两个版本，在master节点升级完毕之后，逐台升级node节点，升级到1.20
（5）升级kube-proxy，要与kubelet的版本一致，因此跨过1.19版本，升级到1.20；在升级kube-proxy时，尽量不要操作集群中的业务
（6）先逐台升级apiserver到1.21.5，然后再逐台升级kube-controller-mannager、kube-scheduler到1.21.5
（7）逐台升级kubectl到1.21.5
（8）逐台升级kubelet到1.21.5
（9）逐台升级kube-proxy到1.21.5
（10）升级etcd
三、升级需知
- 实施方须知
为了满足热升级需求，具体升级内容以及顺序如下：
（1）导入镜像至镜像仓库；
（2）升级apiserver、kube-controller-mannager、kube-scheduler，从1.18.5升级到1.19；
（3）升级kubectl到1.20；
（4）升级apiserver、kube-controller-mannager、kube-scheduler，从1.19升级到1.20；
（5）升级kubelet，从1.18.5升级到1.20；
（6）升级kube-proxy，从1.18.5升级到1.20；
（7）升级apiserver、kube-controller-mannager、kube-scheduler，从1.20升级到1.21.5；
（8）升级kubectl到1.21.5；
（9）升级kubelet到1.21.5；
（10）升级kube-proxy到1.21.5；
（11）升级etcd，从1.18.5升级到1.21.5； - 应用方须知
要达到业务不中断的效果，无状态的业务必须是多副本，并将实例打散，不能调度到同一个节点上，可使用pod的反亲和性，这个要在升级前做好。有状态应用或者有数据持久化到本地的应用，要考虑是否有数据迁移的问题，有问题要提前暴露，具体问题具体分析。
作者：姜博文