2. 核心概念：集群升级治理、模板制品库、版本偏差、清单化验收的定义与关系
在进入具体的验收流程之前，必须对四个核心概念建立统一、精确的认知。这四个概念构成了本课程的方法论基石，它们之间既有明确的职责边界，又通过“交付前验收”这一场景形成闭环。
2.1 概念定义
| 概念 | 英文/缩写 | 定义 | 核心关注点 |
|---|---|---|---|
| 集群升级治理 | Cluster Upgrade Governance | 围绕集群版本升级全生命周期，建立策略、流程、标准与审计机制的管理体系。 | 合规性、可追溯性、风险控制 |
| 模板制品库 | Template Artifact Repository | 存储经过审批、版本化、不可变的基础设施配置模板（如 Helm Chart、Kustomize 基线、Operator 版本）的中央仓库。 | 一致性、版本锁定、不可变性 |
| 版本偏差 | Version Drift / Version Skew | 目标集群当前运行的组件版本与模板制品库中声明的期望版本之间的差异。 | 偏差类型、偏差量级、偏差趋势 |
| 清单化验收 | Checklist-based Acceptance | 将验收标准转化为可执行、可量化的检查项清单，逐项比对并记录结果的过程。 | 可执行性、可量化、审计证据 |
术语辨析：“版本偏差”不同于“配置漂移”。配置漂移通常指非预期的运行时配置变更；而版本偏差特指制品版本号的差异，是集群升级治理中最先需要被捕获和阻断的异常信号。
2.2 四者关系：从治理到验收的闭环
四个概念并非孤立存在，而是形成了一条从“策略制定”到“执行验证”的完整链路。下图展示了它们之间的核心关系与数据流向。
2.3 关系深度解析
为了更清晰地理解四者在实际交付场景中的协作方式，下表从输入、输出、触发条件三个维度进行拆解。
| 关系对 | 输入 | 输出 | 触发条件 |
|---|---|---|---|
| 治理 → 模板库 | 版本兼容性矩阵、安全基线、废弃API清单 | 版本化的制品模板、审批记录 | 新版本发布、安全漏洞通告、架构变更 |
| 模板库 → 版本偏差 | 制品库中的期望版本号 | 偏差报告（组件级差异列表） | 集群巡检、升级前扫描、CI/CD触发 |
| 版本偏差 → 清单化验收 | 偏差报告、治理策略中的阈值 | 验收检查项、通过/失败/豁免标记 | 交付前门禁、变更审批流程 |
| 清单化验收 → 治理 | 验收结果、偏差根因分析 | 治理策略优化、流程改进、审计日志 | 验收不通过、周期性复盘、合规审计 |
2.4 为什么必须“清单化”？
在集群升级场景中，版本偏差往往不是单一维度的。一个典型的 Kubernetes 集群升级，需要检查的组件可能包括：
- 控制面组件：kube-apiserver, kube-controller-manager, kube-scheduler, etcd
- 节点组件：kubelet, kube-proxy, 容器运行时 (containerd/CRI-O)
- 核心插件：CoreDNS, kube-ovn/calico, metrics-server, csi-driver
- 治理强制组件：gatekeeper/OPA, cert-manager, istio/服务网格控制面
如果没有清单化验收，仅靠人工比对或零散脚本，极易出现漏检、误判、无法追溯等问题。清单化验收将上述检查项固化为可重复执行的清单，确保每次交付前都执行相同标准的验证。
核心原则：模板制品库是“期望状态”的唯一权威来源；版本偏差是“期望”与“实际”的差值；清单化验收是发现差值后，按照治理规则执行的结构化裁决过程。三者缺一不可，共同构成集群升级治理的“铁三角”。
2.5 偏差类型与验收策略
版本偏差并非只有“版本号不同”这一种形态。在实际治理中，需要区分以下三种偏差类型，并采取不同的验收策略。
| 偏差类型 | 定义 | 示例 | 验收策略 |
|---|---|---|---|
| 主版本偏差 | Major 版本号不一致（如 v1.27 vs v1.28） | 模板要求 kubelet v1.28.3，实际运行 v1.27.9 | 强制阻断，不允许交付 |
| 次版本偏差 | Minor 版本号不一致（如 v1.28.2 vs v1.28.5） | 模板要求 containerd 1.7.20，实际运行 1.7.16 | 根据安全公告和补丁级别判定，可设置豁免条件 |
| 补丁版本偏差 | Patch 版本号不一致（如 v1.28.3 vs v1.28.3+hotfix） | 模板要求 coredns 1.11.1，实际运行 1.11.1-custom | 需验证自定义补丁是否经过审批，否则视为偏差 |
清单化验收的核心价值，就是将上述偏差类型与对应的验收策略，转化为机器可读、人工可审的检查项。例如：
# 清单项示例：检查 kubelet 主版本偏差
- 检查项ID: CHK-CORE-001
- 组件: kubelet
- 期望版本: v1.28.3 (来自模板制品库)
- 实际版本: v1.27.9 (来自集群实时状态)
- 偏差类型: 主版本偏差
- 验收结果: FAIL
- 阻断动作: 阻止制品入库，触发升级流程回退通过这种结构化的清单，每一次验收都留下了完整的审计轨迹，为集群升级治理提供了可量化的数据支撑。