转载：KubeKey 升级 KubeSphere 和 Kubernetes 补丁版本实战指南
知识点
-
定级：入门级
-
KubeKey 如何升级 KubeSphere 补丁版本
-
KubeKey 如何升级 Kubernetes 补丁版本
-
KubeSphere 和 Kubernetes 升级准备及验证
-
KubeKey 升级 KubeSphere 和 Kubernetes 的常见问题
实战服务器配置 (架构 1:1 复刻小规模生产环境，配置略有不同)
| 主机名 | IP | CPU | 内存 | 系统盘 | 数据盘 | 用途 |
|---|---|---|---|---|---|---|
| k8s-master-1 | 192.168.9.91 | 4 | 16 | 40 | 100 | KubeSphere/k8s-master |
| k8s-master-2 | 192.168.9.92 | 4 | 16 | 40 | 100 | KubeSphere/k8s-master |
| k8s-master-3 | 192.168.9.93 | 4 | 16 | 40 | 100 | KubeSphere/k8s-master |
| k8s-worker-1 | 192.168.9.95 | 8 | 16 | 40 | 100 | k8s-worker/CI |
| k8s-worker-2 | 192.168.9.96 | 8 | 16 | 40 | 100 | k8s-worker |
| k8s-worker-3 | 192.168.9.97 | 8 | 16 | 40 | 100 | k8s-worker |
| k8s-storage-1 | 192.168.9.81 | 4 | 16 | 40 | 100/100/100/100/100 | ElasticSearch/GlusterFS/Ceph-Rook/Longhorn/NFS/ |
| k8s-storage-2 | 192.168.9.82 | 4 | 16 | 40 | 100/100/100/100 | ElasticSearch/GlusterFS/Ceph-Rook/Longhorn/ |
| k8s-storage-3 | 192.168.9.83 | 4 | 16 | 40 | 100/100/100/100 | ElasticSearch/GlusterFS/Ceph-Rook/Longhorn/ |
| registry | 192.168.9.80 | 4 | 8 | 40 | 100 | Sonatype Nexus 3 |
| 合计 | 10 | 52 | 152 | 400 | 2000 |
实战环境涉及软件版本信息
-
操作系统：CentOS 7.9 x86_64
-
KubeSphere：v3.4.0 to v3.4.1
-
Kubernetes：v1.24.12 to v1.24.14
-
Containerd：1.6.4
-
KubeKey: v3.0.13
1. 简介
1.1 Kubernetes 版本升级概述
KubeSphere v3.4.1 已于 2023 年 11 月 10 日正式发布，升级说明详见 Releases-v3.4.1 发布说明。该发布版修复了 v3.4.0 中存在的许多问题，建议所有人更新。
KubeSphere 官方的升级文档 操作比较简单。但是，实际升级过程还是遇到 2 个小问题。正好借此机会，写一篇完整版的 KubeSphere 和 Kubernetes 补丁版本升级完全实战指南。
为什么强调 补丁版本？这里就要简单点介绍一下 Kubernetes 版本命名规则及升级策略。
Kubernetes 版本以 x.y.z 表示，其中 x 是主要版本， y 是次要版本，z 是补丁版本。Kubernetes 跨版本升级从 v1.28 开始支持 3 个次要版本，v1.28 以前支持 2 个次要版本。但是在升级时，高可用性（HA）集群 和 单节点集群，不同组件之间的偏差要求也不尽相同，具体信息可参考 Kubernetes 官方文档的版本偏差策略。
原生的 Kubeadm 和 Kubekey 都支持跨次版本升级，当使用 KubeKey 升级 Kubernetes 次要版本时，将从一个次要版本升级到下一个次要版本，直到目标版本。例如，v1.22 升级到 v.1.24 您会发现升级过程先从 v1.22 先升级到 v1.23 然后再升级到 v1.24，而不是直接从 v1.22 升级到 v1.24。
本文只适用于 KubeSphere 和 Kubernetes 组件的补丁版本升级，不涉及次要版本升级。
-
KubeSphere v3.4.0 升级到 v3.4.1（理论上未来的 v3.4.x 都适用）
-
Kubernetes v1.24.x 升级到 v1.24.y
-
且只适用于小规模集群，中大规模集群有待验证
本期为什么暂时不涉及次要版本升级（仅作为个人观点）？
-
没有十足把握（谁敢说有？），生产环境不建议升级次要版本，尤其是跨越多个次要版本（升级失败导致业务停摆的案例比比皆是）
-
必须要升级时，建议采用「建设新版本集群 + 迁移业务应用 」 的解决方案（适用于有全局负载或是网关，存算分离即 Kubernetes 和 后端存储耦合性不强的场景）
-
一定要原地跨次要版本升级，在做好充分备份、测试验证后，自求多福吧
-
升级有风险，操作需谨慎（纯属废话）
当然，为了技术学习，也为了积累原地升级的实战经验，后期还是会推出次要版本升级指南。
KubeKey 支持 All-in-One 集群和多节点集群两种升级场景，本文只实战演示多节点集群的升级场景， All-in-One 集群请参考官方升级指南。
1.2 KubeSphere 和 Kubernetes 升级流程概述
本文演示多节点集群升级场景。在该场景下我们分别升级 KubeSphere 和 Kubernetes。 KubeKey 本身支持一键直接升级 KubeSphere 和 Kubernetes。但是，个人建议生产环境建议分别升级、分别验证。
具体的升级流程如下：
-
备份（必须）
-
下载最新版 KubeKey
-
生成集群部署配置文件并修改
-
升级并验证 KubeSphere
-
升级并验证 Kubernetes
-
验证测试
第一步，备份是一定要做的。具体备份啥？本文没有涉及，这个没有通用标准（说实在的我也不知道）。我个人理解 Kubernetes 相关的 Etcd、集群配置是必须的，再有其他业务重要数据。可用备份迁移工具 Velero 完整备份，但是这也需要大量的额外存储。KubeKey 部署的 Kubernetes 集群自带定时备份 Etcd 的策略。
对于备份有以下想法意见仅供参考：
-
无论集群规模大小，只要是生产集群，就有必要建立日常备份、重大操作备份的备份方案
-
如果日常有备份的习惯建议定期根据备份做恢复演练，验证备份是否可用（实操很难）
-
现有的备份方案是否真的能恢复集群？能恢复集群到什么状态？
-
自用 Kubernetes 集群，建议将所有集群管理 YAMl 和业务部署 YAML 存入 GitLab 进行版本控制（利于备份恢复失败或无备份时快速重建业务，但是数据另算）
-
尽量设计存算分离的架构，让计算集群和存储集群松耦合，避免计算集群崩溃造成数据丢失。同时，也有利于计算集群崩溃重建的业务快速恢复。
2. 升级实战前提条件
为了进行实战演示，我们将使用 KubeKey 工具提前安装和部署一套 KubeSphere 和 Kubernetes 集群。同时，为了模拟真实的业务场景，我们将创建一些测试资源。在验证之前，我们还需要记录当前集群的一些关键信息。
2.1 集群环境
-
安装 v3.4.0 KubeSphere，并启用大部分插件
-
安装 v1.24.x 的 Kubernetes 集群（本文使用 v1.24.12）
-
对接 NFS 存储或是其他存储作为持久化存储（本文测试环境选用 NFS）
2.2 查看当前集群环境信息
下面查看的当前集群环境信息并不充分，只是查看几个具有代表性的资源，肯定有被忽略的组件和信息。
-
查看所有的 Deployment 使用的 Image，方便升级后对比
# 受限于篇幅，输出结果略，请自己保存结果
kubectl get deploy -A -o wide-
查看命名空间
kubesphere-system内的常用资源（还有其他命名规则 kubesphere- 的命名空间，本文略）
[root@k8s-master-1 ~]# kubectl get pod,deployment,sts,ds -o wide -n kubesphere-system
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod/ks-apiserver-7d7f8c7456-cr6hs 1/1 Running 3 (143m ago) 4d23h 10.233.88.111 k8s-worker-1 <none> <none>
pod/ks-console-697f467f5c-bkfkl 1/1 Running 3 (143m ago) 4d23h 10.233.88.115 k8s-worker-1 <none> <none>
pod/ks-controller-manager-755cbdf744-xllxj 1/1 Running 8 (141m ago) 4d23h 10.233.88.116 k8s-worker-1 <none> <none>
pod/ks-installer-69b7c7cf6c-kkz8w 1/1 Running 5 (143m ago) 4d23h 10.233.74.87 k8s-worker-2 <none> <none>
pod/minio-746f646bfb-4h7xj 1/1 Running 3 (143m ago) 4d23h 10.233.88.119 k8s-worker-1 <none> <none>
pod/openldap-0 1/1 Running 4 (143m ago) 4d23h 10.233.88.100 k8s-worker-1 <none> <none>
pod/openpitrix-import-job-plzc5 0/1 Completed 0 139m 10.233.85.48 k8s-master-2 <none> <none>
NAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTOR
deployment.apps/ks-apiserver 1/1 1 1 4d23h ks-apiserver registry.cn-beijing.aliyuncs.com/kubesphereio/ks-apiserver:v3.4.0 app=ks-apiserver,tier=backend
deployment.apps/ks-console 1/1 1 1 4d23h ks-console registry.cn-beijing.aliyuncs.com/kubesphereio/ks-console:v3.4.0 app=ks-console,tier=frontend
deployment.apps/ks-controller-manager 1/1 1 1 4d23h ks-controller-manager registry.cn-beijing.aliyuncs.com/kubesphereio/ks-controller-manager:v3.4.0 app=ks-controller-manager,tier=backend
deployment.apps/ks-installer 1/1 1 1 4d23h installer registry.cn-beijing.aliyuncs.com/kubesphereio/ks-installer:v3.4.0 app=ks-installer
deployment.apps/minio 1/1 1 1 4d23h minio registry.cn-beijing.aliyuncs.com/kubesphereio/minio:RELEASE.2019-08-07T01-59-21Z app=minio,release=ks-minio
NAME READY AGE CONTAINERS IMAGES
statefulset.apps/openldap 1/1 4d23h openldap-ha registry.cn-beijing.aliyuncs.com/kubesphereio/openldap:1.3.0-
查看 Kubernetes 资源（受限于篇幅，不展示 pod 结果）
[root@k8s-master-1 ~]# kubectl get pods,deployment,sts,ds -o wide -n kube-system
NAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTOR
deployment.apps/calico-kube-controllers 1/1 1 1 4d23h calico-kube-controllers registry.cn-beijing.aliyuncs.com/kubesphereio/kube-controllers:v3.26.1 k8s-app=calico-kube-controllers
deployment.apps/coredns 2/2 2 2 4d23h coredns registry.cn-beijing.aliyuncs.com/kubesphereio/coredns:1.8.6 k8s-app=kube-dns
deployment.apps/metrics-server 1/1 1 1 4d23h metrics-server registry.cn-beijing.aliyuncs.com/kubesphereio/metrics-server:v0.4.2 k8s-app
最低0.47元/天 解锁文章
扫一扫
1223
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
