2. 升级前的集群健康评估
OpenShift 升级不是一次简单的版本替换，而是一次对控制平面、etcd、节点、网络、存储、证书和 Operator 协同状态的整体切换。升级前健康评估的目标，是在变更窗口开始之前，把“集群当前是否具备升级准入条件”转化为一组可采集、可判断、可留档的证据。评估结论通常只有三种：准入（可进入升级窗口）、有条件准入（先修复明确项，再复检）、不准入（存在阻断性故障，禁止开始升级）。
评估应围绕六类对象展开：集群版本与升级路径、ClusterOperator 状态、etcd 健康、节点状态、证书有效期、以及 must-gather 证据包。它们不是并列的“检查项清单”，而是有依赖关系的证据链：版本路径决定目标版本，ClusterOperator 反映控制平面组件是否稳定，etcd 决定集群数据面能否安全滚动，节点决定工作负载能否迁移，证书决定升级过程中组件能否继续通信，must-gather 则是所有判断的原始证据。
一、版本与升级路径：先确认“能升到哪”
第一步不是看节点，而是确认当前版本与目标版本之间是否存在受支持的升级路径。OpenShift 采用 z 流（补丁版本）与 EUS（扩展更新支持）通道，跨多个次版本通常需要经过中间版本。使用以下命令查看当前状态：
oc adm upgrade --include-not-ready
oc get clusterversion version -o yaml | grep -E "channel|desired|current"输出中需要关注 current 与 desired 是否一致、channel 是否指向正确的稳定通道（如 stable-4.14），以及是否存在 Upgradeable=False 的条件。若 Upgradeable 为 False，必须先查看 reason 与 message，常见原因包括：某 Operator 未完成升级、MCP 处于暂停状态、或存在不兼容的 API。示例判断：若当前为 4.12.18，目标为 4.14.6，则通常需要先升至 4.13 的最新 z 流，再进入 4.14，不能直接跨版本。
二、ClusterOperator：控制平面的“体检报告”
ClusterOperator 是升级准入最直接的信号。执行 oc get co，逐行检查 AVAILABLE、PROGRESSING、DEGRADED 三列。准入要求是：所有 Operator 的 AVAILABLE 为 True，DEGRADED 为 False，PROGRESSING 为 False（或仅短暂为 True 且已收敛）。
oc get co
oc get co -o json | jq -r '.items[] | select(.status.conditions[] | select(.type=="Degraded" and .status=="True")) | .metadata.name'重点关注 kube-apiserver、etcd、kube-controller-manager、network、authentication、ingress 等核心 Operator。若 network 处于 DEGRADED，升级过程中 Pod 网络可能中断；若 authentication 异常，升级后可能无法登录。对每个 DEGRADED 项，应记录其 message 与最近事件时间，判断是历史遗留还是当前活跃故障。
三、etcd 健康：数据面的安全底线
etcd 是集群唯一的有状态核心，升级期间控制平面会滚动重启，etcd 必须处于健康且稳定的状态。评估要点包括：成员是否全部健康、是否存在 leader、DB 大小与配额、碎片率、以及磁盘延迟。
oc exec -n openshift-etcd etcd-<node> -- etcdctl endpoint health --cluster
oc exec -n openshift-etcd etcd-<node> -- etcdctl endpoint status --cluster -w table
oc exec -n openshift-etcd etcd-<node> -- etcdctl alarm list判断标准：所有 endpoint 返回 healthy: true；DB SIZE 建议低于 2 GB（默认配额 8 GB，但过大将显著拖慢升级）；RAFT TERM 与 RAFT INDEX 应稳定增长，若频繁变化说明存在选举抖动；alarm list 必须为空，若存在 NOSPACE 告警，必须先扩容或清理。碎片率可通过 etcdctl defrag 前的 DB SIZE - DB SIZE IN USE 估算，若碎片超过 30%，建议在升级前安排 defrag。
四、节点状态与 MCP：工作负载能否安全迁移
节点评估关注三件事：是否 Ready、是否可调度、以及 MCP（MachineConfigPool）是否处于更新中。执行：
oc get nodes
oc get mcp
oc get node -o json | jq -r '.items[] | select(.spec.unschedulable==true) | .metadata.name'准入要求：所有节点 Ready；除维护窗口内主动 cordon 的节点外，不应存在 SchedulingDisabled；所有 MCP 的 UPDATED 与 UPDATING 应满足 UPDATED=True、UPDATING=False、DEGRADED=False。若 MCP 正在更新，说明上一轮配置变更尚未收敛，此时开始升级会造成 MachineConfig 版本冲突。此外应检查节点资源余量：升级采用滚动驱逐，若单节点 CPU/内存余量不足，Pod 可能无法迁移，导致升级卡住。
五、证书有效期：容易被忽略的“定时炸弹”
OpenShift 内部组件大量使用证书通信，升级过程中 kube-apiserver、etcd、ingress、kubelet 等证书会重新签发。若升级前证书已接近过期，升级可能因 TLS 握手失败而中断。检查方法：
oc get secret -n openshift-kube-apiserver -o json | jq -r '.items[] | select(.metadata.name|test("cert")) | .metadata.name'
oc get csr
oc adm certificate approve --help更直接的方式是使用 oc get secret 导出证书并查看 notAfter，或通过 openshift-kube-apiserver、openshift-etcd 命名空间下的 secret 逐一核对。建议所有关键证书剩余有效期大于 30 天；若小于 7 天，应先触发轮换或手动批准 CSR，再进入升级窗口。
六、must-gather：把证据留在升级之前
must-gather 是升级前必须执行的证据归档动作。它采集集群所有命名空间的资源定义、事件、日志、Operator 状态和 etcd 快照信息，形成一份可离线分析的基线包。升级失败时，这份基线是回滚比对和 Red Hat 支持定位问题的关键依据。
oc adm must-gather --dest-dir=/data/upgrade-baseline-$(date +%F)
oc adm inspect clusteroperator --dest-dir=/data/upgrade-baseline-$(date +%F)建议在升级窗口开始前 24 小时内执行，确保基线反映的是“即将升级”的真实状态。归档后应记录文件大小、采集时间、集群版本，并与升级后的 must-gather 做差异比对。
七、升级准入检查清单（可直接填写）
| 检查项 | 命令/方法 | 准入标准 | 结果 |
|---|---|---|---|
| 版本路径 | oc adm upgrade --include-not-ready | Upgradeable=True，路径受支持 | □通过 □不通过 |
| ClusterOperator | oc get co | 全部 AVAILABLE=True，DEGRADED=False | □通过 □不通过 |
| etcd 健康 | etcdctl endpoint health/status | 全 healthy，无 alarm，DB<2GB | □通过 □不通过 |
| 节点状态 | oc get nodes | 全部 Ready，无异常 SchedulingDisabled | □通过 □不通过 |
| MCP 状态 | oc get mcp | UPDATED=True，UPDATING=False | □通过 □不通过 |
| 证书有效期 | 检查关键 secret notAfter | 剩余 > 30 天 | □通过 □不通过 |
| must-gather | oc adm must-gather | 基线包已归档并记录 | □通过 □不通过 |
完成以上评估后，你得到的不是一份“感觉没问题”的判断，而是一条从版本路径到证据归档的完整证据链。它既能支撑升级决策，也能在升级出现异常时，快速回答“升级前是什么状态、变化发生在哪一步”。