3. 多集群安装与部署模式

在 OpenShift 多集群工程中，安装方式决定了后续运维的边界。集群一旦以某种模式落地，其升级路径、故障恢复手段、节点替换流程乃至灾备切换的自动化程度都会被这一初始选择长期约束。因此，理解 IPI、UPI、Agent-based 安装以及托管控制平面（Hosted Control Plane，HCP）的差异，并据此选择多集群拓扑，是灾备工程的第一道决策关口。

四种安装模式的本质区别

IPI（Installer-Provisioned Infrastructure）由安装程序全权负责基础设施生命周期：它会调用云平台 API 创建 VPC/VNet、子网、负载均衡器、DNS 记录、安全组，再创建控制平面与计算节点。运维者只需提供 install-config.yaml 与凭据。其代价是必须使用受支持的云平台，且集群与云账号强绑定。IPI 集群天然支持 Machine API，节点扩缩容、故障自愈由 MachineSet 驱动，是多集群自动化运维成本最低的模式。

UPI（User-Provisioned Infrastructure）把基础设施的创建责任交还给运维者。安装程序只生成 ignition 配置和引导资源，VPC、负载均衡、DNS、节点主机全部由用户预先准备。UPI 适用于本地 IDC、私有云、国产化平台或已有严格网络规范的场景。它的代价是：节点替换需要人工介入，Machine API 通常不可用（除非额外配置 bare metal 或平台集成），升级与扩容的自动化程度显著下降。

Agent-based 安装是近年面向边缘与受限网络的重要方式。它把安装逻辑打包进一个可引导的 ISO，节点从 ISO 启动后由内置的 Agent 服务完成发现、角色分配与集群装配。它不需要外部 bootstrap 节点，也不需要预先存在的管理集群，特别适合无外网、无 PXE、无 BMC 的“三无”边缘站点。其核心输入是 install-config.yaml 与 agent-config.yaml，后者用于声明每个节点的角色、MAC 地址与静态网络。

托管控制平面（HCP）改变了控制平面与工作负载的耦合关系。控制平面以 Pod 形式运行在一个管理集群（Management Cluster）中，工作负载集群只保留 worker 节点。这样，一个管理集群可以承载多个轻量级数据平面，控制平面的升级、备份、恢复由管理集群统一编排。HCP 显著降低了每集群的控制平面成本，但也引入了新的依赖：管理集群本身成为关键故障域，必须优先保障其高可用与备份。

安装模式如何决定灾备能力

灾备的核心指标是 RTO（恢复时间目标）与 RPO（恢复点目标）。安装模式直接决定这两个指标的可达范围。

IPI 集群的控制平面节点由 MachineSet 管理，节点故障后会自动重建，etcd 成员恢复由 Machine API 与 ClusterOperator 协同完成。若配合 OADP（OpenShift API for Data Protection）做应用级备份，RPO 可控制在分钟级。但 IPI 依赖云平台 API，一旦云区域整体不可用，跨区恢复必须依赖预先在另一区域部署的备用集群。

UPI 集群的节点替换需要人工重装或重新引导，etcd 恢复通常依赖预先配置的外部 etcd 或定期快照。其 RTO 往往以小时计，因此 UPI 场景下必须把“备份可用性验证”纳入日常演练，而不能只依赖安装时的静态配置。

Agent-based 安装的集群通常位于网络受限站点，备份介质往往只能落地本地。此时 RPO 取决于本地备份频率，RTO 取决于现场人员到达时间。工程上常见的做法是在中心管理集群保存一份配置与密钥的加密副本，站点重建时通过 U 盘或带外通道注入。

HCP 的灾备逻辑与前三种不同：控制平面数据（etcd、API Server 状态）位于管理集群，因此备份对象是管理集群中的 HostedCluster 与 NodePool 资源，以及控制平面命名空间下的 etcd 数据。数据面 worker 节点本身无状态，重建成本低。这意味着 HCP 的 RTO 主要取决于管理集群的恢复速度，而非数据面节点数量。

多集群拓扑选择的判断路径

实际工程中，拓扑选择可以按以下顺序收敛：

1. 确定故障域边界。是单区域多集群、跨区域双活，还是中心—边缘分层？故障域决定了哪些组件必须独立部署。
2. 确定网络与介质约束。站点是否有外网、是否有 PXE、是否有 BMC、是否允许云 API 调用。这直接排除或锁定 Agent-based 与 IPI。
3. 确定自动化运维预算。若团队规模有限，应优先选择 IPI 或 HCP，把节点生命周期交给平台；若必须使用 UPI，则需为节点替换与 etcd 恢复单独编制 SOP。
4. 确定恢复优先级。控制面优先还是数据面优先？HCP 把控制面集中，意味着管理集群必须先恢复；UPI 把控制面分散，意味着每个集群都要独立恢复能力。

示例：跨区域双活集群的安装参数取舍

假设某业务要求同城双活，两个机房各部署一个 OpenShift 集群，应用通过 Global Load Balancer 分流，数据库采用异步复制。此时安装模式的选择依据如下：

综合后，较合理的方案是：两个机房各用 Agent-based 安装一个三节点控制面集群，中心部署一个 HCP 管理集群用于承载非关键业务的托管控制面，关键业务仍保留独立控制面。etcd 快照每 5 分钟推送至对端机房的 S3 兼容存储，应用通过 OADP 每 10 分钟备份一次。切换时先恢复 etcd 或直接启用备用集群，再由 GLB 切流。

# agent-config.yaml 片段示例（声明节点角色与静态网络）
apiVersion: v1beta1
kind: AgentConfig
metadata:
  name: dc1-cluster
rendezvousIP: 10.20.0.10
hosts:
  - hostname: master-0
    role: master
    interfaces:
      - name: eno1
        macAddress: 52:54:00:aa:01:01
    networkConfig:
      interfaces:
        - name: eno1
          type: ethernet
          state: up
          ipv4:
            enabled: true
            address:
              - ip: 10.20.0.11
                prefix-length: 24
            dhcp: false
      dns-resolver:
        config:
          server:
            - 10.20.0.2
      routes:
        config:
          - destination: 0.0.0.0/0
            next-hop-address: 10.20.0.1
            next-hop-interface: eno1

该配置的关键点在于：rendezvousIP 指定了引导节点，各主机通过 MAC 地址与静态 IP 绑定，避免依赖 DHCP。安装完成后，可用 oc get nodes 与 oc get clusteroperators 确认控制面就绪，再用 oc get etcd 检查 etcd 成员健康。若某节点未加入，应优先检查 agent-config 中的 MAC 是否与实际网卡一致，以及 rendezvousIP 是否可达。

托管控制平面的额外考量

采用 HCP 时，管理集群本身成为单点故障域。工程上要求管理集群至少三节点、etcd 独立加密备份、控制平面命名空间资源配额充足。HostedCluster 的 etcd 数据默认存储在管理集群的持久卷中，若使用本地存储，则管理集群节点故障会导致多个托管集群同时不可用。因此 HCP 场景下，管理集群的存储应优先选择复制型存储类，并单独配置备份策略。

此外，HCP 的升级顺序与独立集群不同：先升级管理集群，再升级 HostedCluster 的控制平面，最后滚动更新 NodePool 中的 worker。这一顺序若颠倒，可能导致控制平面与数据面版本不匹配。灾备演练时应把这一顺序纳入切换脚本的检查项。

综上，安装模式不是单纯的部署工具选择，而是灾备架构的起点。IPI 换取自动化，UPI 换取可控性，Agent-based 换取离线适应力，HCP 换取密度与集中编排。多集群拓扑的选择，本质上是在故障域、自动化能力与恢复手段之间做权衡。明确 RTO/RPO 与网络约束后，安装模式与拓扑自然收敛。