3. 集群安装规划
OpenShift 集群安装规划的核心，是在真正执行 openshift-install 之前，把“集群要长成什么样”确定下来。安装程序本身只负责把规划结果落地，规划错了，安装成功也可能在生产环境中留下隐患。本节围绕四个相互制约的维度展开：节点角色、网络拓扑、存储与计算资源、高可用要求。
一、节点角色规划
OpenShift 4.x 的节点角色由 MachineConfigPool 和节点标签共同决定，规划阶段至少要明确三类角色：控制平面节点（control plane / master）、基础设施节点（infra）和工作负载节点（worker）。控制平面节点运行 etcd、kube-apiserver、controller-manager、scheduler 以及集群自带的 Operator，它们对延迟和磁盘 IO 非常敏感，不应承载普通业务 Pod。
基础设施节点用于承载路由（Ingress Controller）、镜像仓库（Image Registry）、监控（Prometheus、Alertmanager）、日志（Loki/Elasticsearch）和集群日志转发等组件。把这些组件从 worker 上分离出来，可以避免业务负载与平台组件争抢资源，也便于单独扩容和打标签。工作负载节点则按业务类型进一步细分，例如通过标签区分 node-role.kubernetes.io/app、node-role.kubernetes.io/gpu，配合 taint/toleration 与 nodeSelector 实现调度隔离。
一个常见的教学示例规划如下：3 台控制平面节点（每台 8 vCPU / 32 GB / 200 GB SSD）、3 台基础设施节点（每台 8 vCPU / 32 GB / 200 GB SSD）、若干工作负载节点（按业务规模 16 vCPU / 64 GB 起）。控制平面节点数量必须是奇数，以保证 etcd 的 quorum 机制正常工作。
二、网络拓扑设计
网络规划需要同时考虑三类地址：节点管理网、集群内部 Pod 网络和 Service 网络，以及对外暴露的 Ingress/VIP 地址。安装前必须确定以下参数：
- machineNetwork：节点所在子网，例如
192.168.10.0/24，用于节点间通信和 API 访问。 - clusterNetwork：Pod CIDR，默认
10.128.0.0/14，需确保与现有企业网络不冲突。 - serviceNetwork：Service CIDR，默认
172.30.0.0/16，同样不能与外部路由重叠。 - API VIP 与 Ingress VIP：通常由 keepalived 或外部负载均衡器提供，例如
192.168.10.10和192.168.10.11。
如果企业已有 DNS 和负载均衡设备，推荐使用外部 LB 模式：由 F5、HAProxy 或云负载均衡器将 api.cluster.example.com:6443 和 *.apps.cluster.example.com:443 分别转发到控制平面节点和基础设施节点。若没有外部 LB，则使用安装程序内置的 keepalived + HAProxy 方案，此时需要预留两个 VIP。
三、存储与计算资源评估
计算资源评估要从“平台自身开销 + 业务负载 + 预留余量”三部分考虑。控制平面节点上，etcd 对磁盘延迟最敏感，建议使用本地 NVMe SSD，IOPS 不低于 3000，且不要与其他高 IO 组件共享磁盘。基础设施节点需要为 Prometheus 预留持久卷，默认保留 15 天指标时，每 100 个节点大约需要 100～200 GB 存储。
存储方面，OpenShift 通过 StorageClass 对接后端存储。规划时要明确：镜像仓库使用哪种 StorageClass（建议支持 RWX 或至少 RWO 的块存储）、监控和日志使用哪种（建议独立 StorageClass，避免与业务争抢 IO）、是否需要动态供给。常见后端包括 Ceph RBD/CephFS、NFS、iSCSI、云厂商块存储等。若使用本地存储 Operator（LSO），需要提前规划每块磁盘的盘符和所属节点。
一个可参考的容量估算方法是：先统计业务 Pod 的 requests/limits 总和，再乘以 1.3～1.5 的冗余系数，得到工作负载节点总资源；控制平面和基础设施节点单独计算，不参与业务调度。例如业务总 requests 为 200 vCPU / 400 GB，冗余系数 1.4，则工作负载节点至少需要 280 vCPU / 560 GB 可调度资源。
四、高可用要求
高可用规划要覆盖控制平面、基础设施和工作负载三个层面。控制平面必须为 3 台或 5 台，分布在不同物理机、机架或可用区，确保单点故障不会导致 etcd 失去 quorum。基础设施节点同样建议 3 台，Ingress Controller 默认 2 副本，可调整为 3 副本并配置反亲和性，使副本分散到不同节点。
工作负载的高可用由业务自身决定，但平台侧要提供 PodDisruptionBudget、拓扑分布约束（topologySpreadConstraints）和节点反亲和性等能力。规划阶段应明确：是否跨可用区部署、节点故障时业务能否自动迁移、存储是否支持跨节点访问。若使用本地存储，Pod 迁移后无法访问原数据，这类有状态业务必须配合应用层复制或使用支持多节点的存储方案。
install-config.yaml 的填写依据，避免安装过程中反复修改。综合来看，节点角色决定“谁跑什么”，网络拓扑决定“怎么连通”，存储与计算评估决定“够不够用”，高可用要求决定“坏了怎么办”。四者需要在安装前统一确认，任何一项缺失都会在后续运维中放大为故障风险。