雨中的风铃 发表于 2021-12-22 17:41:57

智汇华云 | 使用Kubeadm进行Kubernetes集群版本升级

https://www.z4a.net/images/2021/12/22/21.png


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节点上的以下组件:
Kubernetes API Server
Kubernetes Scheduler
Kubernetes Controller Manager
Kubelet
Kubeadm
第一步、在 Master 节点上安装新版本的 kubeadm


第二步、执行以下命令进行升级:
kubeadm upgrade apply v1.20.0
此升级过程会针对 Kubernetes API Server、Kubernetes Scheduler 和 Kubernetes Controller Manager 这三个组件生成新版本的配置文件覆盖旧版本的,Master 节点上的 Kubelet 会 Watch 到这些改动,会重建对应的 Pod。另外还会重新生成 Kube-Proxy DaemonSet 的配置,Node 节点上所有的 Kube-Proxy 相关的 Pod 会进行重建。


第三步、腾空节点
通过将节点标记为不可调度并腾空节点为节点作升级准备:
kubectl drain node_name --ignore-daemonsets


第四步、升级 Kubelet
升级后需要重启 Kubelet
sudo systemctl daemon-reload
sudo systemctl restart kubelet


第五步、解除节点的保护
通过将节点标记为可调度,让其重新上线:
kubectl uncordon node_name
如果集群的控制平面是 HA 的情况,在 API Server 前端应该有类似 HAProxy的负载均衡软件,高可用依赖 HAProxy 对于后端的 API Server 周期性的检测机制,如果某个 Mater 正在升级,这时 HAProxy 会检测到,然后后续的请求就不会转发到这个 Master 节点。等升级完成后,状态恢复正常,这时 HAProxy 将其作为正常的后端进行请求转发。


升级数据平面(Node 节点)


数据平面是指 Node节点上的Kubectl和Kubelet等组件。


如果用户的某个应用只有一个 Pod,这种情况下无法做到升级过程中业务不会中断。另外,如果Kubernetes集群只有一个Node节点,在这升级这一个Node节点的过程中,这个Pod会被驱逐,并且由于没有其它节点可以调度,因此会一直处于pending状态,在这段时间内业务会完全中断。


第一步、在 Node 节点上安装新版本的kubectl。


第二步、腾空节点
通过将节点标记为不可调度并腾空节点为节点作升级准备:
kubectl drain node_name --ignore-daemonsets
注意,这一步需要保证业务流量不受到影响,如果某个业务有多个 Pod,则需要保证其它节点上的 Pod 处于正常运行状态。


第三步、升级 Kubelet
升级后需要重启 Kubelet
sudo systemctl daemon-reload
sudo systemctl restart kubelet


第四步、解除节点的保护
通过将节点标记为可调度,让其重新上线:
kubectl uncordon node_name


升级其它组件


其它组件不仅包括CNI Driver、CSI Driver等基础能力组件,还包括Ingress Controller、Dashboard、Prometheus、Metric-Server 等用户或管理员安装的辅助组件。


当 Kubernetes 集群进行版本升级时,这些组件是否需要升级或者变更需要参考各组件与 Kubernetes 的版本兼容性,本文不再进行深入阐述。


几点解释


关于 "腾空节点"的操作
在升级控制平面和数据平面的时候都要先做一个"腾空节点"的操作,这个操作会首先驱逐当前节点上的 Pod(不包含控制面Pod和DaemonSet的Pod),然后将当前节点标记为不可调度。待升级完成后,执行 uncordon 命令将节点恢复正常状态。这是 Kubernetes 官方推荐的维护某一个节点的标准流程。


如果一个节点同时作为 Master 和 Node 节点,如何处理?
按照正常的控制面升级流程即可。


API 转换的问题
目前,整个升级过程,不会涉及到具体业务的 API 升级问题,比如从alpha升级到beta版本。用户如果有这方面的需求,可以使用 kubectl convert 命令在不同 API 版本之间转换清单。例如:kubectl convert -f pod.yaml --output-version v1 & kubectl apply -fpod.yaml 的内容,在新的清单文件中,kind 被设置为 Pod(未变),但 apiVersion 则被修订了。


升级后,负载是否需要手动重启
升级后,因为容器的 spec 中的哈希值已更改,所有容器都会被重新启动。由于在升级数据面的时候已经对 Pod 做了驱逐操作,因此所有的Pod 都已经完成了重建操作。


页: [1]
查看完整版本: 智汇华云 | 使用Kubeadm进行Kubernetes集群版本升级