一、核心原则（工业产线优先）
- 不停业务 ：利用 K8s 自愈、滚动更新、节点腾空，实现在线升级
- 窗口选择 ：优先选业务低峰期 （深夜、停产、午休），严格走 ITIL变更管理流程
- 先测试后生产：测试集群验证版本、兼容性、应用适配，再上生产
- 必有回滚方案：升级异常一键回退，杜绝产线瘫痪
- 分批灰度：节点分批升级，不整集群同时操作
工业场景红线：严禁高峰期全集群停机升级
二、主流升级方式 & 选型（按场景）
1. 原地滚动升级（最常用，RKE/RKE2/K3s 原生）
适用 ：现有集群在线平滑升级，不新增机器，成本低、速度快原理：逐节点驱逐 Pod → 节点离线升级 K8s 组件 → 节点重新上线 → 下一个节点Pod 会被调度到其他正常节点，业务无感知。
2. 蓝绿 / 新建集群迁移（高要求、核心工业业务）
适用：大版本跨代升级（如 1.24→1.28）、架构改造、担心原地升级风险原理：
- 新建同配置新版本 K8s 集群（蓝集群）
- 全量部署应用、配置、存储、中间件，完成功能 & 压力验证
- 切换流量（Istio/Ingress/ 负载均衡切流）
- 旧集群（绿）观察一段时间后下线优点：风险最低，出问题直接切回旧集群；缺点：需要额外服务器资源。
3. 增量扩容升级（折中方案）
新增新版本节点加入旧集群，逐步把 Pod 调度到新节点，再下线旧节点并升级，最后完成全集群迭代。
三、标准落地流程（原地滚动升级，工业生产通用）
以 Rancher 管理的 RKE2/K3s 集群 为例，分升级前 → 升级中 → 升级后，全程遵循 ITIL 变更流程。
（一）升级前准备（重中之重，规避 80% 故障）
1. 流程合规（ITIL 变更管理）
- 提交变更申请单：写明升级版本、时间窗口、影响范围、回滚方案、责任人
- 内部评审、产线 / 业务部门确认，预约低峰维护窗口
- 通知相关运维、产线负责人，做好值守安排
2. 环境 & 兼容性检查
- 版本兼容性
- 确认 K8s 版本升级路径（禁止跨多个大版本跳跃升级，例如 1.25 → 1.26 → 1.27 逐版本升）
- 检查周边组件适配：Rancher、Istio、Redis、Zabbix Agent、容器镜像、PV 存储插件、CNI 网络插件
- 集群状态预检
bash
运行
# 节点全部 Ready，无污点、异常
kubectl get nodes
# Pod 全部 Running/Completed，无 CrashLoopBackOff
kubectl get pods -A
# 查看事件，提前清理现有异常
kubectl get events -A --sort-by=.metadata.creationTimestamp
# 检查存储、PVC、PV、挂载状态
kubectl get pv,pvc -A- 资源预留 确保集群剩余资源充足，单个节点驱逐后，其余节点能承载全部业务 Pod，避免资源不足导致 Pod pending。
3. 全量备份（必做）
- 集群资源备份：
etcd快照（K8s 核心数据） - 配置备份：Namespace、Deployment、Service、Ingress、ConfigMap、Secret、RBAC
- 持久化数据：数据库、Redis、MES 业务数据、共享存储数据
- Rancher 集群配置导出
4. 预演
在测试集群完整走一遍升级流程，验证应用启动、网络、存储、监控、Istio 流量功能正常。
（二）分步滚动升级操作（逐节点升级，业务不中断）
K8s 节点分为三类：控制平面节点（Master）、工作节点（Worker）、混合节点 升级顺序：先 Worker 节点 → 再 Master 控制节点
步骤 1：封锁 + 驱逐单个工作节点
- 节点设为不可调度，禁止新 Pod 调度进来
bash
运行
kubectl cordon <节点名>- 驱逐该节点上所有 Pod（Pod 自动漂移到其他正常节点）
bash
运行
kubectl drain <节点名> --ignore-daemonsets --delete-emptydir-data--ignore-daemonsets：忽略 DaemonSet（如 Zabbix、日志组件，节点必备）--delete-emptydir-data：删除临时目录数据，持久化数据不受影响
步骤 2：升级当前节点 K8s 组件
- Rancher 环境：Web 界面选中集群 → 编辑版本 → 对单节点执行升级；或通过 RKE2/K3s 命令行升级二进制 / 包
- 原生 K8s ：升级
kubeadm/kubelet/kubectl，重启对应服务 - 等待节点组件重启、网络 / 代理恢复
步骤 3：恢复节点调度
节点升级完成、状态变为 Ready 后，解除封锁：
bash
运行
kubectl uncordon <节点名>步骤 4：循环执行
逐个节点 重复「cordon → drain → 升级 → uncordon」，直到所有 Worker 节点升级完毕。
步骤 5：升级控制平面（Master 节点）
控制节点同样采用滚动方式，多 Master 集群逐个升级，保证集群控制面始终可用：
- 同样执行 cordon + drain
- 升级 kube-apiserver、etcd、scheduler、controller-manager
- 验证控制面正常，解除封锁
单 Master 集群风险更高，优先建议生产用3 节点高可用控制面
（三）升级后验证 & 收尾
- 全局状态检查
bash
运行
kubectl get nodes # 所有节点 Ready、版本统一
kubectl get pods -A # 所有业务Pod正常运行- 业务功能验证
- 访问 MES/SCADA 前端、接口、数据采集链路
- 验证中间件：Redis、消息队列、数据库读写正常
- 验证网络：Istio 流量、Ingress 访问、跨 Pod 通信
- 监控校验查看 Zabbix/Prometheus 指标：CPU、内存、网络、请求延迟、错误率无异常
- 解除变更、归档文档
- 关闭变更工单，记录升级日志、版本、问题点
- 保留备份文件一段时间，观察 1~3 个业务周期无异常再清理
四、异常处理 & 回滚方案（工业核心，应急必备）
1. 升级中节点无法启动
现象：节点状态 NotReady，kubelet 启动失败处理：
- 暂时跳过该节点，先升级其他节点，保证集群整体可用
- 排查日志
journalctl -u kubelet，修复依赖 / 配置 - 修复失败 → 执行版本回滚
2. Pod 漂移后无法启动
原因：镜像兼容、存储插件、网络插件新版本不兼容处理：
- 临时还原对应组件版本
- 若大面积故障：整体回滚集群版本，切回旧版本
3. 标准回滚流程
- 停止剩余节点升级操作
- 逐个节点回退 K8s 版本
- 恢复全部节点调度，确认业务恢复
- 复盘根因，优化后再择机升级
蓝绿集群模式回滚最简单：直接把流量切回旧集群即可。
五、Rancher 环境专属升级（你日常在用）
Rancher 管理集群分两层，升级顺序：1. 先升级 Rancher Server 本身 → 2. 再升级下游 K8s 集群
- 升级 Rancher 服务：遵循官方版本对应关系，先备份，滚动升级 Rancher 所在集群
- 升级下游集群：
- 界面操作：集群详情 → 升级 Kubernetes 版本
- Rancher 内置滚动升级逻辑，自动逐节点排空、升级、恢复
- 可设置升级并发数，控制同时升级节点数量（工业建议并发 = 1，最稳）
六、Istio 配套升级（微服务场景）
集群升级完成后，再滚动升级 Istio，避免版本不兼容：
- 先升级 istiod 控制平面
- 逐个节点重启 Sidecar（Envoy），流量平滑切换
- 验证灰度发布、mTLS、调用链、熔断功能正常
七、面试标准答题（精简版，直接背诵）
问题：如何在不影响业务的情况下升级 K8s 集群？
答：
- 严格遵循 ITIL 变更流程，选择业务低峰窗口，提前完成etcd、配置、数据全量备份，并在测试集群验证版本兼容性。
- 优先采用滚动升级 方案：先对单个节点执行
cordon封锁调度、drain驱逐 Pod，Pod 自动漂移至其他节点，保证业务不中断。 - 对腾空节点执行 K8s 组件升级，节点恢复 Ready 后解除调度限制，逐个完成所有工作节点升级，再滚动升级多 Master 控制节点。
- 升级完成后全面校验节点、Pod、网络、存储、业务功能与监控指标。
- 提前制定回滚预案，一旦出现兼容故障立即版本回退；高风险大版本升级可采用蓝绿新建集群 + 流量切换方案，进一步降低风险。
- 若集群部署 Istio 等组件，在 K8s 升级完成后再配套滚动升级。
八、关键总结（工业运维要点）
- 版本不跨跳：逐小版本升级，降低兼容风险；
- 必备份 + 预演：测试环境跑通再上生产；
- 滚动分批：单节点操作，利用 K8s 调度实现业务无感；
- 流程合规：走 ITIL 变更，窗口值守，留痕归档；
- 兜底方案：原地升级配版本回滚，重大升级优先蓝绿迁移。