2. OpenShift多集群架构与核心对象

在单集群 OpenShift 中，我们习惯把 ClusterVersion、MachineConfig、Infrastructure、ClusterOperator 当作“集群内部对象”来理解。但一旦进入多集群运维与灾备场景，这些对象的含义会发生微妙而关键的变化：它们不再只是描述“本集群是什么状态”，而是成为跨集群比对、漂移检测、故障定位和恢复决策的锚点。理解它们在多集群中的角色与关系，是后续所有运维动作的基础。

一、四个核心对象在多集群中的定位

ClusterVersion（CV）是集群版本与升级状态的唯一权威来源。它记录期望版本（desiredUpdate）、当前版本（version）、可用更新通道（channel）以及升级条件（conditions）。在多集群中，CV 的价值在于横向比对：同一批集群是否处于同一 OCP 版本、是否卡在某个 Progressing 条件、升级历史是否一致。灾备场景下，主备集群的 CV 版本必须匹配，否则恢复后的工作负载可能因 API 版本差异而失败。

MachineConfig（MC）描述节点级别的期望配置，包括内核参数、kubelet 配置、systemd 单元、文件内容等。它由 MachineConfigPool（MCP）按节点角色分组管理。多集群中，MC 是“配置漂移”最敏感的指标：不同集群的 worker MCP 若渲染出不同的 MachineConfig，往往意味着节点配置不一致，进而影响网络、存储或安全策略的一致性。

Infrastructure（Infra）对象记录集群的基础设施属性，例如平台类型（AWS、vSphere、BareMetal）、API Server 地址、控制面拓扑、云区域等。它决定了集群“长什么样”。在多集群中，Infra 是判断集群是否可纳入同一灾备域、是否共享网络出口、是否具备相同存储类的重要依据。

ClusterOperator（CO）是各功能组件的健康与版本汇总器，如 network、storage、authentication、ingress 等。每个 CO 报告 available、progressing、degraded 三类条件。多集群运维中，CO 是快速定位“哪个集群、哪个组件异常”的第一入口，也是判断集群是否适合承接流量或执行切换的前置检查项。

二、对象之间的依赖与影响链

这四个对象并非孤立，而是存在清晰的依赖链。Infrastructure 决定平台与拓扑，进而影响 MachineConfig 中可用的配置项（例如云平台特有的 kubelet 参数）；MachineConfig 通过 MCP 驱动节点重启与配置生效，节点就绪后 ClusterOperator 才能达到 Available；ClusterVersion 则协调整个升级过程，升级期间会触发新的 MachineConfig 渲染，并观察各 CO 是否健康。因此，在多集群中排查问题时，应沿着“Infra → MC/MCP → 节点 → CO → CV”的方向逐层确认，而不是直接跳到 CV 看版本。

三、多集群中的实际比对与判断

假设我们管理三个集群：A 为主集群，B 为同城灾备，C 为边缘集群。日常巡检时，不应逐个集群登录查看，而应通过统一采集脚本或 ACM（Advanced Cluster Management）的 observability 能力，把四个对象的关键字段拉齐比对。以下是一段可直接参考的采集命令示例，用于导出每个集群的核心对象摘要：

# 在每个集群的 kubeconfig 上下文下执行，输出关键字段
oc get clusterversion version -o jsonpath='{.status.desired.version}{"\n"}'
oc get infrastructure cluster -o jsonpath='{.status.platform}{" / "}{.status.platformStatus.aws.region}{"\n"}'
oc get machineconfigpool worker -o jsonpath='{.status.configuration.name}{"\n"}'
oc get clusteroperators -o custom-columns=\
'NAME:.metadata.name,AVAILABLE:.status.conditions[?(@.type=="Available")].status,\
DEGRADED:.status.conditions[?(@.type=="Degraded")].status'

比对时重点关注四类信号。第一，CV 的 desired.version 是否一致；若 A、B 为 4.14.12 而 C 为 4.13.9，则 C 不能直接纳入同一灾备切换组。第二，Infrastructure 的 platform 与 region 是否匹配；跨平台（AWS 与 vSphere）意味着存储类、网络插件和节点驱动可能不同，恢复策略必须区分。第三，worker MCP 的 configuration.name 是否一致；该字段实际指向当前渲染出的 MachineConfig 名称，名称不同即代表节点配置存在漂移。第四，CO 中是否存在 Degraded=True；只要有一个 CO 降级，就应暂停对该集群的切换或升级操作。

四、灾备切换前的对象检查顺序

当需要把业务从 A 切换到 B 时，对象检查应遵循依赖链顺序，而不是随机查看。先确认 B 的 Infrastructure 与 A 处于同一平台和区域，确保存储与网络可达；再确认 B 的 worker MCP 与 A 渲染一致，避免节点配置差异导致 Pod 无法调度；接着检查 B 的 ClusterOperator 是否全部 Available 且无 Degraded；最后确认 B 的 ClusterVersion 与 A 版本一致，且没有正在进行的升级。只有这四步全部通过，才进入应用层切换。

反过来，如果切换后发现异常，也应逆着依赖链回查：应用报错 → 看 CO 是否降级 → 看节点 MCP 是否完成渲染 → 看 MachineConfig 是否被意外修改 → 看 Infrastructure 是否被变更。这条链路能显著缩短多集群故障的定位时间。

五、常见误区

• 只看 CV 版本就认为集群一致。版本相同不代表 MachineConfig 和 Infrastructure 相同，配置漂移同样会导致恢复失败。
• 忽略 MCP 的渲染状态。MachineConfigPool 处于 Updating 时，节点正在滚动重启，此时切换会带来额外风险。
• 把 CO 的 Available 当作唯一健康标准。Available=True 但 Degraded=True 的组件仍可能影响特定功能，必须同时检查两类条件。
• 在 Infra 平台不同的集群间直接做灾备。跨平台恢复需要额外的存储与网络适配，不能默认对等。

把 ClusterVersion、MachineConfig、Infrastructure、ClusterOperator 四个对象放在多集群视角下理解，本质上是在建立一套“可比对、可追溯、可放行”的一致性基线。后续的升级编排、漂移修复和灾备演练，都将围绕这条基线展开。