集群升级制品库废弃API检测与节点排空 - 第1节
1.1 集群升级治理的重要性
在 Kubernetes 集群的完整生命周期中，升级是最具风险的操作之一。一个缺乏治理的升级过程可能导致服务中断、数据丢失或配置回退困难。集群升级治理的核心目标是在可控性、可观测性和可重复性之间建立平衡，确保每次版本跃迁都经过验证、记录和审计。
治理三要素：
- 版本合规 — 集群版本始终处于上游支持的补丁通道内，避免 CVE 暴露。
- 变更可追溯 — 每次升级的组件清单、参数变更、检查结果均被持久化。
- 回滚预案 — 升级前必须验证回滚路径，确保 etcd 快照与节点快照可用。
下图展示了集群升级治理的闭环流程，从版本基线建立到升级后验证，每个阶段都依赖制品库中的标准化模板来驱动。
1.2 模板制品库的概念
模板制品库（Template Artifact Repository）是集群升级治理的单一可信源。它将升级过程中使用的所有可复用资产——包括 YAML 清单、Helm Chart、Kustomize 覆盖层、升级前检查脚本、节点排空策略——统一版本化存储，并通过 CI/CD 管道按需分发。
| 制品类型 | 内容说明 | 版本管理方式 |
|---|---|---|
| 升级基线模板 | 目标版本 kubeadm 配置、组件镜像标签、CNI 版本 | SemVer + 集群环境标签 |
| API 废弃检查规则 | 针对每个 K8s 版本的废弃 API 清单与替换建议 | 按 K8s 版本号归档 |
| 节点排空策略 | PodDisruptionBudget 模板、排空超时参数、Graceful 节点关闭脚本 | Git 标签 + 环境变量覆盖 |
| 升级后验证套件 | Conformance 测试用例、自定义健康检查 Job、审计日志采集配置 | 与集群版本绑定 |
实践建议：制品库应使用 OCI 兼容的存储后端（如 Harbor、GitHub Container Registry），使模板能够像容器镜像一样被拉取、签名和扫描。每个模板制品必须包含
README.md 和 CHANGELOG.md，确保运维人员理解变更上下文。
1.3 API 废弃检查与节点排空计划的关联
在集群升级路径中，API 废弃检查和节点排空计划是两个最容易被低估但影响最大的前置步骤。它们之间存在明确的依赖关系：
- API 废弃检查 确保集群中运行的 workloads 在目标版本中仍然兼容。如果未通过检查，排空操作可能触发 Pod 调度失败或控制器崩溃。
- 节点排空计划 依赖 API 废弃检查的结果来调整排空顺序和超时策略。例如，当检测到某个 Deployment 使用了废弃的
extensions/v1beta1API 时，排空计划需要为该 Deployment 预留额外的迁移窗口。
下图展示了两个检查项在升级前准备阶段的协作关系：
常见陷阱：部分团队在升级前只做节点排空演练，而忽略 API 废弃检查。这会导致排空过程中出现“Pod 无法调度”或“控制器无法创建新副本”的故障，最终升级失败。正确的做法是将 API 废弃检查作为排空计划的前置门禁，只有检查通过后才能进入排空阶段。