集群升级基础概念
集群升级是 Kubernetes 生命周期管理中最关键的操作之一。理解集群版本语义、控制平面与节点的升级关系、以及不同部署策略的差异，是设计可靠回滚策略的前提。本节将系统梳理这些基础概念，为后续的流水线集成测试验证奠定理论基础。
2.1 集群版本与语义化版本
Kubernetes 遵循 语义化版本 2.0（SemVer）规范，版本号格式为 vMAJOR.MINOR.PATCH。版本差异决定了升级路径的兼容性与风险等级。
| 版本段 | 示例 | 变更含义 | 升级风险 |
|---|---|---|---|
| MAJOR | v1 → v2 | 不兼容的 API 变更，需迁移资源对象 | 极高，通常需重建集群 |
| MINOR | v1.27 → v1.28 | 功能新增、API 弃用、行为调整 | 中高，需关注弃用 API 迁移 |
| PATCH | v1.28.1 → v1.28.3 | 安全修复、Bug 修复，API 不变 | 低，可滚动热修复 |
版本偏差策略： Kubernetes 官方支持控制平面最多比节点高 2 个 MINOR 版本，节点不能比控制平面高。升级时必须先升级控制平面，再升级节点，且每次只能跳 1 个 MINOR 版本。
2.2 控制平面升级 vs 节点升级
集群升级分为两个独立但有序的阶段：控制平面升级 和 节点升级。两者在组件构成、影响范围和回滚方式上有本质区别。
| 维度 | 控制平面升级 | 节点升级 |
|---|---|---|
| 组件 | kube-apiserver, kube-controller-manager, kube-scheduler, etcd | kubelet, kube-proxy, 容器运行时 |
| 影响范围 | 整个集群的 API 可用性、调度、控制器 | 单个节点上的 Pod 调度与运行 |
| 升级顺序 | 必须先升级 | 控制平面升级完成后才能升级 |
| 回滚难度 | 高，涉及 etcd 数据兼容性 | 中，可逐节点回滚 kubelet 版本 |
| 停机窗口 | 需要 API 服务短暂中断或 HA 切换 | 可逐节点排空后升级，业务无感 |
关键原则： 控制平面升级是集群升级的 前置条件 和 最大风险点。控制平面升级失败时，节点即使已升级也无法正常工作。因此，回滚策略必须优先保障控制平面的可回退性。
2.3 滚动升级与蓝绿部署
在节点升级或工作负载更新场景中，滚动升级 和 蓝绿部署 是两种主流的部署策略。它们对业务连续性和回滚速度有直接影响。
2.4 节点升级的滚动策略
节点升级通常采用 滚动升级 模式，通过逐节点排空（drain）和升级来最小化业务影响。标准流程如下：
- 节点排空：
kubectl drain <node> --ignore-daemonsets --delete-emptydir-data，将 Pod 迁移到其他节点。 - 节点升级： 更新 kubelet 和 kube-proxy 版本，重启节点或重新安装组件。
- 节点恢复：
kubectl uncordon <node>，允许新 Pod 调度到该节点。 - 健康检查： 验证节点状态为
Ready，节点上的系统 Pod 正常运行。 - 下一节点： 重复上述步骤，直到所有节点升级完成。
避坑提示： 节点排空前务必确认集群有足够的剩余资源承载被迁移的 Pod。如果集群资源利用率超过 80%，建议先扩容节点池或降低升级并发数，避免 Pod 调度失败导致级联故障。
2.5 蓝绿部署在集群升级中的应用
虽然蓝绿部署常用于工作负载，但在 控制平面升级 场景中同样可以借鉴其思想：
- 蓝环境： 当前稳定版本的控制平面（v1.27）。
- 绿环境： 新版本的控制平面（v1.28），使用独立的 etcd 实例或快照。
- 流量切换： 通过负载均衡器将 API Server 流量从蓝环境切换到绿环境。
- 验证与回滚： 绿环境运行稳定后，销毁蓝环境；若出现问题，立即切回蓝环境。
| 策略 | 资源消耗 | 回滚时间 | 数据一致性 | 推荐场景 |
|---|---|---|---|---|
| 滚动升级 | 低（复用节点） | 分钟级（逐节点回滚） | 强（共享 etcd） | PATCH 升级、节点升级 |
| 蓝绿部署 | 高（双倍环境） | 秒级（流量切换） | 需 etcd 同步或快照 | MINOR 升级、高风险变更 |
2.6 升级路径与版本兼容性矩阵
Kubernetes 官方推荐的升级路径是 逐 MINOR 版本升级，不支持跨版本直接升级。例如从 v1.25 升级到 v1.28，必须经过 v1.26 → v1.27 → v1.28 三个步骤。
版本兼容性检查清单：
- 确认当前版本与目标版本之间的 API 弃用清单，提前迁移资源对象。
- 检查集群中所有 CustomResourceDefinition (CRD) 的兼容性。
- 验证 etcd 版本 是否在目标 Kubernetes 版本的兼容范围内。
- 确认 节点操作系统 和 容器运行时 是否支持目标版本。
2.7 升级策略选择决策树
在实际生产环境中，选择哪种升级策略取决于集群规模、业务容忍度和回滚能力。以下决策树可帮助快速判断：
- 是否为 PATCH 升级？ → 是 → 使用 滚动升级，逐节点升级，风险最低。
- 是否为 MINOR 升级且集群节点数 < 50？ → 是 → 使用 滚动升级，但需提前验证 API 兼容性。
- 是否为 MINOR 升级且集群节点数 ≥ 50？ → 是 → 推荐 蓝绿部署 控制平面，节点使用滚动升级。
- 是否为 MAJOR 升级？ → 是 → 建议 新建集群 并迁移工作负载，避免原地升级风险。
- 回滚时间要求 < 5 分钟？ → 是 → 必须使用 蓝绿部署 或保留完整备份。
最佳实践： 无论选择哪种策略，升级前必须对 etcd 做 全量快照，并记录当前集群的 组件版本清单。这是回滚操作的最后一道防线。