3. 交付前环境冻结

环境冻结是验收交付前最关键的一道“闸门”。它的目标不是把集群锁死不动，而是把当前可交付状态固化成一份可复现、可审计、可回退的基线：集群版本、节点配置、网络插件、存储类与 Operator 版本必须彼此匹配，且所有变更在冻结窗口内停止。冻结之后，任何改动都要走变更审批，否则验收结论将失去意义。

一、冻结对象与一致性维度

冻结不是单一动作，而是对五类对象的联合约束。它们之间存在明确的依赖关系：集群版本决定可用的 API 与 Operator 兼容矩阵；节点配置决定 kubelet、容器运行时与内核参数；网络插件版本必须与集群版本匹配；存储类依赖 CSI 驱动与后端存储版本；Operator 则依赖前四者提供的运行时与存储能力。任何一项单独升级都可能打破一致性。

因此，冻结前必须完成一次“横向对齐”：以集群版本为基准，逐项核对节点、网络、存储与 Operator 的版本区间。例如，OpenShift 4.14 对应 OVN-Kubernetes 的特定版本、CSI 驱动的最低版本，以及各 Operator 的订阅通道。若某 Operator 仍停留在旧通道，即使集群版本已达标，也不能视为一致。

二、一致性检查的实际操作

检查应从集群版本开始。使用 oc get clusterversion 确认当前版本与目标版本一致，并记录 status.desired.version 与 status.history 中的最近一次升级时间。若集群仍处于升级中或存在 Updating 状态，必须等待其完成后再冻结。

# 查看集群版本与升级状态
oc get clusterversion version -o jsonpath='{.status.desired.version}{"\n"}'
oc get clusterversion version -o jsonpath='{.status.conditions[?(@.type=="Progressing")].status}{"\n"}'

# 查看节点配置一致性
oc get machineconfigpool
oc describe machineconfigpool worker | grep -A5 "Updated"

# 查看网络插件类型与版本
oc get network.operator cluster -o jsonpath='{.spec.defaultNetwork.type}{"\n"}'
oc get csv -n openshift-ovn-kubernetes

# 查看存储类与 CSI 驱动
oc get storageclass
oc get csv -n openshift-cluster-csi-drivers

# 查看 Operator 订阅与版本
oc get subscriptions -A -o custom-columns=NS:.metadata.namespace,NAME:.metadata.name,CHANNEL:.spec.channel,CURRENT:.status.currentCSV

节点配置检查的重点是 MachineConfigPool 是否全部处于 Updated=True 且 Degraded=False。若某个节点池仍在滚动更新，说明配置尚未收敛，此时冻结会导致节点间配置漂移。网络插件方面，需确认 defaultNetwork.type 与集群版本匹配，并检查 OVN-Kubernetes 的 CSV 版本是否在支持区间内。存储类则要核对每个 StorageClass 的 provisioner 是否对应已安装的 CSI 驱动，且驱动 CSV 版本与集群版本兼容。

Operator 检查最容易遗漏。除了查看订阅通道，还要确认 status.currentCSV 与 status.installedCSV 一致，避免出现“已安装但未生效”的中间态。对于依赖特定 API 的 Operator，还需检查其 CRD 是否已随集群版本更新。

三、冻结流程与基线固化

一致性检查通过后，进入冻结执行阶段。冻结的核心动作包括四项：停止自动升级、锁定 MachineConfig、固定 Operator 订阅通道、生成基线快照。

停止自动升级可通过将 ClusterVersion 的 spec.channel 固定为当前通道，并设置 spec.desiredUpdate 为空来实现。更稳妥的做法是使用 oc adm upgrade --clear 清除待升级目标，并确认 Progressing 为 False。锁定 MachineConfig 则是确保没有新的 MachineConfigPool 变更被触发，可通过暂停 MachineConfigOperator 的滚动更新来实现，但需注意这会影响后续节点维护，因此冻结窗口应尽量短。

Operator 订阅通道固定后，应记录每个订阅的 channel、currentCSV 与 installedCSV。若使用 Operator Lifecycle Manager 的自动升级策略，需将其改为手动批准，防止冻结期间意外升级。

基线快照建议包含以下内容：集群版本与节点版本、所有 MachineConfigPool 状态、网络插件 CSV、StorageClass 列表与 CSI 驱动版本、所有 Operator 订阅与 CSV 版本、关键命名空间的资源配额与 LimitRange。快照以 YAML 或 JSON 形式归档，并计算校验和，作为验收比对依据。

四、冻结后的变更控制与回退

冻结不是终点，而是变更控制的起点。冻结后任何改动——包括节点扩容、Operator 升级、存储类参数调整——都必须经过审批，并重新执行一致性检查。若检查不通过，应回退到冻结基线。回退的依据正是基线快照：通过比对当前状态与快照，可以快速定位偏差项，并决定是修复还是回滚。

实际交付中，建议将冻结清单作为验收报告附件，逐项签字确认。清单应包含检查项、期望值、实际值、偏差说明与处理结论。这样，验收方可以清晰看到环境在冻结时刻的真实状态，而不是依赖口头承诺。

最后，冻结流程应与交付文档同步。将基线快照、冻结清单、变更审批记录一并归档，形成可追溯的交付证据链。这样，即使交付后出现版本不一致问题，也能快速回溯到冻结时刻的状态，判断是冻结前遗留还是冻结后引入。