关于k8s 集群版本升级的一些笔记(不能跨次要版本升级)
那认识一切而不为任何事物所认识的,就是主体 —–《作为意志和表象的世界》(第一篇 世界作为表象初论)
写在前面
- 分享一些 K8s 集群版本升级的笔记
- 博文为根据官方文档的版本升级记录
- 以及不同组件的版本偏差要求
- 理解不足小伙伴帮忙指正
那认识一切而不为任何事物所认识的,就是主体 —–《作为意志和表象的世界》(第一篇 世界作为表象初论)
升级 K8S集群
分享一些 基本 kubeadm 升级 K8s 集群版本的笔记, 下面为实际的升级记录,这里一定要注意,不能跨次要版本升级,可以跨补丁版本,即可以 1.26.x 升级到 1.26.y(其中 y > x+1) 或者 1.22.x 升级到 1.23.x ,不能 1.22.x 升级到 1.26.x。
Kubernetes 版本以 x.y.z
表示,其中 x 是主要版本
, y 是次要版本
,z 是补丁版本
,遵循语义版本控制术语。
支持的版本偏差
kube-apiserver
: 在高可用性(HA)集群中(可以单纯理解为多 master 节点的情况), 最新版和最老版的 kube-apiserver 实例版本偏差最多为一个次要版本,即多个 master 节点 的 kube-apiservice
版本要求。
kubelet
: kubelet 版本不能比 kube-apiserver 版本新,并且最多只可落后两个次要版本。如果 HA 集群中的 kube-apiserver 实例之间存在版本偏差,这会缩小允许的 kubelet 版本范围。
kube-controller-manager、kube-scheduler 和 cloud-controller-manager
: kube-controller-manager、kube-scheduler 和 cloud-controller-manager 不能比与它们通信的 kube-apiserver 实例新。 它们应该与 kube-apiserver 次要版本相匹配
,但可能最多旧一个次要版本
。
kubectl
:kubectl 在 kube-apiserver 的一个次要版本(较旧或较新)中支持。
kube-proxy
: kube-proxy 和节点上的 kubelet 必须是相同的次要版本。kube-proxy 版本不能比 kube-apiserver 版本新。kube-proxy 最多只能比 kube-apiserver 落后两个次要版本。
升级工作的基本流程如下
- 升级 master 所有节点
- 升级 node 所有节点
这里升级版本为 1.21.1 升级 1.22.2 ,下面为具体的升级步骤,实际操作一般以官方文档为准,尤其涉及一些重大版本变更,比如 1.23 之后不支持 docker
,只能使用 containerd
,还用 docker
的话只能添加垫片之类的东西。如果升级版本太低不被支持,只能找其他相关资料。 版本迭代很快,虽然旧版本也一直在维护。还是建议有稳定版本就升级。
确定要升级到哪个版本
1 | ┌──[root@vms81.liruilongs.github.io]-[~] |
现有环境
1 | ┌──[root@vms81.liruilongs.github.io]-[~/ansible] |
升级 master
控制节点上的升级过程应该每次处理一个节点。 首先选择一个要先行升级的控制面节点。该节点上必须拥有 /etc/kubernetes/admin.conf
文件。 即管理员使用的 kubeconfig 证书文件
执行 “kubeadm upgrade”
升级 kubeadm:
1 | # 用最新的补丁版本号替换 1.22.x-0 中的 x |
验证下载操作正常,并且 kubeadm 版本正确:
1 | ┌──[root@vms81.liruilongs.github.io]-[~] |
验证升级计划:
此命令检查你的集群是否可被升级,并取回你要升级的目标版本。 命令也会显示一个包含组件配置版本状态的表格。
1 | ┌──[root@vms81.liruilongs.github.io]-[~] |
选择要升级到的目标版本,运行合适的命令
1 | ┌──[root@vms81.liruilongs.github.io]-[~] |
k8s 官网提到这里需要升级 CNI 组件,这里要根据实际情况具体分析, 当前不需要。这里如果有其他的 master 节点 ,则需要运行 sudo kubeadm upgrade node
设置进入维护模式
通过将节点标记为不可调度并腾空节点为节点作升级准备:
1 | # 将 <node-to-drain> 替换为你要腾空的控制面节点名称 |
升级 kubelet 和 kubectl
1 | # 用最新的补丁版本号替换 1.22.x-00 中的 x |
重启 kubelet
1 | ┌──[root@vms81.liruilongs.github.io]-[~] |
解除节点的保护
1 | ┌──[root@vms81.liruilongs.github.io]-[~] |
master 节点版本以已经替换
1 | ┌──[root@vms81.liruilongs.github.io]-[~] |
升级工作节点 Node
工作节点上的升级过程应该一次执行一个节点,或者一次执行几个节点, 以不影响运行工作负载所需的最小容量。
升级 kubeadm
1 | ┌──[root@vms81.liruilongs.github.io]-[~/ansible] |
腾空节点,设置维护状态
1 | ┌──[root@vms81.liruilongs.github.io]-[~/ansible] |
升级 kubelet 和 kubectl
1 | ┌──[root@vms81.liruilongs.github.io]-[~/ansible] |
重启 kubelet
1 | ┌──[root@vms81.liruilongs.github.io]-[~/ansible] |
1 | ┌──[root@vms81.liruilongs.github.io]-[~/ansible] |
取消对节点的保护
1 | ┌──[root@vms81.liruilongs.github.io]-[~] |
kubeadm upgrade apply 做了以下工作:
- 检查你的集群是否处于可升级状态:
- API 服务器是可访问的
- 所有节点处于 Ready 状态
- 控制面是健康的
- 强制执行版本偏差策略。
- 确保控制面的镜像是可用的或可拉取到服务器上。
- 如果组件配置要求版本升级,则生成替代配置与/或使用用户提供的覆盖版本配置。
- 升级控制面组件或回滚(如果其中任何一个组件无法启动)。
- 应用新的 CoreDNS 和 kube-proxy 清单,并强制创建所有必需的 RBAC 规则。
- 如果旧文件在 180 天后过期,将创建 API 服务器的新证书和密钥文件并备份旧文件。
kubeadm upgrade node 在其他控制平节点上执行以下操作:
- 从集群中获取 kubeadm ClusterConfiguration。
- (可选操作)备份 kube-apiserver 证书。
- 升级控制平面组件的静态 Pod 清单。
- 为本节点升级 kubelet 配置
kubeadm upgrade node 在工作节点上完成以下工作:
- 从集群取回 kubeadm ClusterConfiguration。
- 为本节点升级 kubelet 配置。
博文参考
https://kubernetes.io/zh-cn/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/
关于k8s 集群版本升级的一些笔记(不能跨次要版本升级)
https://liruilongs.github.io/2022/12/14/K8s/API 学习/关于 Kubernetes 集群版本升级的一些笔记(不能跨版本升级)/
1.K8s 集群高可用master节点ETCD全部挂掉如何恢复?
2.K8s 集群高可用master节点故障如何恢复?
3.K8s 镜像缓存管理 kube-fledged 认知
4.K8s集群故障(The connection to the server <host>:<port> was refused - did you specify the right host or port)解决
5.关于 Kubernetes中Admission Controllers(准入控制器) 认知的一些笔记
6.K8s Pod 创建埋点处理(Mutating Admission Webhook)
7.关于AI(深度学习)相关项目 K8s 部署的一些思考
8.K8s Pod 安全认知:从openshift SCC 到 PSP 弃用以及现在的 PSA