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节点上的以下组件：
KubernetesAPIServer
KubernetesScheduler
KubernetesControllerManager
Kubelet
Kubeadm
第一步、在Master节点上安装新版本的kubeadm
第二步、执行以下命令进行升级：
kubeadmupgradeapplyv1.20.0
此升级过程会针对 KubernetesAPIServer、KubernetesScheduler和KubernetesController Manager这三个组件生成新版本的配置文件覆盖旧版本的，Master节点上的Kubelet会Watch到这些改动，会重建对应的 Pod。另外还会重新生成Kube-ProxyDaemonSet的配置，Node节点上所有的Kube-Proxy相关的Pod 会进行重建。
第三步、腾空节点
通过将节点标记为不可调度并腾空节点为节点作升级准备：
kubectldrainnode_name--ignore-daemonsets
第四步、升级Kubelet
升级后需要重启Kubelet
sudosystemctldaemon-reload
sudosystemctlrestartkubelet
第五步、解除节点的保护
通过将节点标记为可调度，让其重新上线：
kubectluncordonnode_name
如果集群的控制平面是 HA的情况，在APIServer前端应该有类似HAProxy的负载均衡软件，高可用依赖HAProxy对于后端的API Server周期性的检测机制，如果某个Mater正在升级，这时HAProxy会检测到，然后后续的请求就不会转发到这个Master 节点。等升级完成后，状态恢复正常，这时HAProxy将其作为正常的后端进行请求转发。
升级数据平面（Node节点）
数据平面是指Node节点上的Kubectl和Kubelet等组件。
如果用户的某个应用只有一个 Pod，这种情况下无法做到升级过程中业务不会中断。另外，如果Kubernetes集群只有一个Node节点，在这升级这一个Node节点的过程中，这个Pod会被驱逐，并且由于没有其它节点可以调度，因此会一直处于pending状态，在这段时间内业务会完全中断。
第一步、在Node节点上安装新版本的kubectl。
第二步、腾空节点
通过将节点标记为不可调度并腾空节点为节点作升级准备：
kubectldrainnode_name--ignore-daemonsets
注意，这一步需要保证业务流量不受到影响，如果某个业务有多个Pod，则需要保证其它节点上的Pod处于正常运行状态。
第三步、升级Kubelet
升级后需要重启Kubelet
sudosystemctldaemon-reload
sudosystemctlrestartkubelet
第四步、解除节点的保护
通过将节点标记为可调度，让其重新上线：
kubectluncordonnode_name
升级其它组件
其它组件不仅包括CNIDriver、CSIDriver等基础能力组件，还包括IngressController、Dashboard、Prometheus、Metric-Server等用户或管理员安装的辅助组件。
当Kubernetes集群进行版本升级时，这些组件是否需要升级或者变更需要参考各组件与Kubernetes的版本兼容性，本文不再进行深入阐述。
几点解释
关于"腾空节点"的操作
在升级控制平面和数据平面的时候都要先做一个"腾空节点"的操作，这个操作会首先驱逐当前节点上的 Pod(不包含控制面Pod和DaemonSet的Pod)，然后将当前节点标记为不可调度。待升级完成后，执行uncordon 命令将节点恢复正常状态。这是Kubernetes官方推荐的维护某一个节点的标准流程。
如果一个节点同时作为Master和Node节点，如何处理？
按照正常的控制面升级流程即可。
API转换的问题
目前，整个升级过程，不会涉及到具体业务的 API升级问题，比如从alpha升级到beta版本。用户如果有这方面的需求，可以使用kubectlconvert命令在不同API 版本之间转换清单。例如：kubectlconvert-fpod.yaml--output-versionv1& kubectlapply-fpod.yaml的内容，在新的清单文件中，kind被设置为Pod(未变)，但apiVersion 则被修订了。
升级后，负载是否需要手动重启
升级后，因为容器的spec中的哈希值已更改，所有容器都会被重新启动。由于在升级数据面的时候已经对Pod做了驱逐操作，因此所有的Pod都已经完成了重建操作。
【广告】
（免责声明：此文内容为本网站刊发或转载企业宣传资讯，仅代表作者个人观点，与本网无关。仅供读者参考，并请自行核实相关内容。）
