3. OpenShift升级路径规划与版本选择
升级路径规划的核心不是“把集群升到最新版”，而是在支持的升级图（Upgrade Graph）中，找到一条从当前版本到目标版本、且经过官方验证的可行路线。OpenShift 的版本号形如 4.y.z，其中 4.y 称为次版本（minor），z 称为补丁版本（patch）。升级规划主要围绕次版本展开：补丁升级（如 4.14.5 → 4.14.9）风险低、随时可做；次版本升级（如 4.14 → 4.15）则必须遵循官方升级图，不能随意跨版本跳跃。
一、先理解三条硬约束
规划任何路线前，必须先确认三条约束，它们决定了“哪些路根本走不通”。
- 只能沿升级图前进：OpenShift 不支持跨多个次版本直接升级，例如 4.12 不能直接升到 4.16。通常一次只能前进一个次版本，个别版本允许跳过（如 4.13 → 4.15），但必须以官方发布的升级图为准。
- 不能降级：次版本升级不可逆。一旦升到 4.15，就无法回退到 4.14，只能通过备份恢复重建。因此升级前的 etcd 备份和关键工作负载备份是硬性前提。
- EUS 到 EUS 是长周期路径：EUS（Extended Update Support，延长更新支持）版本提供更长的维护窗口，典型 EUS 版本为 4.12、4.14、4.16、4.18 等偶数版本。EUS 到 EUS 允许跨多个次版本升级，例如 4.12 → 4.14 → 4.16，这是生产环境最常用的“少折腾”策略。
二、奇数版与偶数版策略
OpenShift 的次版本按奇偶形成两种节奏。偶数版本（4.12、4.14、4.16、4.18）通常是 EUS 版本，支持周期长，适合作为生产集群的“落脚点”。奇数版本（4.13、4.15、4.17）是过渡版本，支持周期短，主要作用是作为通往下一个 EUS 的跳板。
由此形成两种典型策略：
- EUS 到 EUS（推荐生产）：集群长期停留在 EUS 版本，只在下一个 EUS 发布并稳定后，沿官方 EUS 路径升级。例如 4.12 → 4.14 → 4.16。升级次数少、每次跨度大，但每一步都经过官方验证。
- 逐版本跟进（适合紧跟特性）：每个次版本都升，例如 4.14 → 4.15 → 4.16。升级频繁、单次风险小，但需要持续投入维护精力，且奇数版本支持窗口短，容易“追不上”。
三、用升级图确定可行路线
官方升级图以有向图形式发布，节点是具体版本（含 z 版本），边表示“可从 A 升级到 B”。规划时按以下顺序操作：
- 确认当前版本，例如
4.12.31。 - 确定目标版本，例如希望落到下一个 EUS
4.14。 - 在升级图中查找从 4.12 出发、能到达 4.14 的路径。若图中存在 4.12 → 4.14 的边，则可直接升级；若不存在，则需经过中间版本，例如 4.12 → 4.13 → 4.14。
- 检查路径上每个目标版本是否已发布稳定的 z 版本，优先选择该次版本的最新 z 版本作为升级目标。
- 确认路径上每个版本都满足平台、Operator、硬件和存储的兼容性要求。
下面这张图展示了从 4.12 到 4.16 的典型 EUS 路径与逐版本路径的对比，以及升级图中“允许”和“不允许”的边。
四、版本选择的具体判断依据
确定路径后，还要为路径上的每个节点选择具体 z 版本。判断依据如下：
| 判断项 | 要求 | 示例 |
|---|---|---|
| 目标次版本 | 必须是升级图中当前版本的直接后继或 EUS 允许的后继 | 4.12 → 4.14 |
| 目标 z 版本 | 优先选择该次版本最新稳定 z，避免刚发布的早期 z | 4.14.12 而非 4.14.1 |
| Operator 兼容性 | 已安装 Operator 需声明支持目标版本 | 检查 CSV 的 olm.skipRange 与 supported |
| 平台与硬件 | 目标版本需支持当前云平台、CPU 架构、存储插件 | vSphere、AWS、裸金属 |
| 维护窗口 | 控制面升级通常 30–60 分钟，节点重启需逐台滚动 | 预留 2–4 小时窗口 |
五、实操：用命令行确认可行路径
在集群内可以直接查询当前版本和可用更新，辅助判断路径。以下命令在示例集群上执行，输出为合理假设的示例结果。
# 查看当前集群版本
$ oc get clusterversion
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS
version 4.12.31 True False 12d Cluster version is 4.12.31
# 查看当前通道与可用更新
$ oc adm upgrade
Cluster version is 4.12.31
Upstream: https://api.openshift.com/api/upgrades_info/v1/graph
Channel: eus-4.12
Recommended updates:
VERSION IMAGE
4.12.33 quay.io/openshift-release-dev/ocp-release:4.12.33-x86_64
4.14.12 quay.io/openshift-release-dev/ocp-release:4.14.12-x86_64
输出中 Channel: eus-4.12 表示当前处于 EUS 通道，推荐更新里同时出现 4.12.33（补丁）和 4.14.12（下一个 EUS），说明升级图允许从 4.12 直接到 4.14。若推荐列表中没有 4.14，则说明当前 z 版本尚未被升级图纳入该路径，需要先升到某个中间 z 版本，或改走 4.13 过渡。
oc adm upgrade --to=4.14.12 时，若该版本不在推荐列表中，命令会拒绝执行。强行绕过会跳过官方验证，可能导致控制面组件不兼容。六、规划成果：一张可执行的升级路线表
把上述判断固化成一张路线表，作为升级执行的依据。以下为示例，字段可根据实际环境调整。
| 阶段 | 起始版本 | 目标版本 | 路径类型 | 预计窗口 | 前置检查 |
|---|---|---|---|---|---|
| 1 | 4.12.31 | 4.12.33 | 补丁升级 | 30 分钟 | etcd 备份、节点健康 |
| 2 | 4.12.33 | 4.14.12 | EUS 直连 | 2 小时 | Operator 兼容、存储插件 |
| 3 | 4.14.12 | 4.14.15 | 补丁升级 | 30 分钟 | 观察 1 周后执行 |
这张表把“当前版本 → 目标版本”拆成可验证的小步：先补丁对齐，再跨 EUS，最后补丁收尾。每一步都有明确的起始、目标、窗口和检查项，执行时只需按行推进，出现异常也能定位到具体阶段。
七、常见误区
- 直接跳到最新版：4.12 直接升 4.16 在升级图中不存在，命令会被拒绝。
- 忽略奇数版本支持窗口：4.13 支持周期短，若计划经 4.13 到 4.14，需确认 4.13 仍在支持期内。
- 只看控制面不看 Operator：控制面升级成功不代表业务 Operator 兼容，需提前检查 CSV 声明。
- 不做备份就升级：次版本不可降级，etcd 备份是唯一回退手段。
总结来说，升级路径规划就是三步：确认当前版本与目标版本，在官方升级图中找到可行边，再为每个节点选择稳定 z 版本并核对兼容性。生产环境优先走 EUS 到 EUS，把升级次数降到最低，同时保留每一步的备份与验证。