一、需求

k8s 1.18.5的环境升级到1.21.5版本，预期目标是：
1.升级过程中k8s集群正常运行
2.运行在k8s集群中的业务不中断
3.升级过程中失败能快速回退

二、思路

Kubernetes版本号格式为x.y.z，其中x为大版本号，y为小版本号，z为补丁版本，各个组件之间最大的版本偏差如下（参考Kubernetes版本偏差）：

1. kube-apiserver之间最多差一个小版本，如果升级了一个实例至1.21，那么其他的apiserver的版本号必须是1.21或者1.20；
2. kubelet最多比apiserver低2个小版本，不能高于apiserver,，如果3个apiserver实例的版本号都是1.21了，那么kubelet可以是1.21、1.20或者1.19；
3. kube-controller-mannager、kube-scheduler不能高于apiserver，允许比kube-apiserver低一个版本；
4. kubectl 与apiserver的偏差允许在一个小版本以内，如果apiserver是1.20，那么kubectl可以是1.21,1.20,1.19；
5. 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. 实施方须知
   为了满足热升级需求，具体升级内容以及顺序如下：
   （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；
2. 应用方须知
   要达到业务不中断的效果，无状态的业务必须是多副本，并将实例打散，不能调度到同一个节点上，可使用pod的反亲和性，这个要在升级前做好。有状态应用或者有数据持久化到本地的应用，要考虑是否有数据迁移的问题，有问题要提前暴露，具体问题具体分析。

作者：姜博文