4. 交付前环境评估与容量规划
OpenShift 的交付质量，很大程度上在集群还没安装之前就已经决定了。如果客户现有基础设施的实际情况与设计假设不一致，或者容量估算过于乐观，后续无论安装过程多么顺利，集群上线后都可能出现 Pod 频繁驱逐、etcd 写入延迟升高、镜像拉取缓慢甚至节点 NotReady 等问题。因此，交付前的环境评估与容量规划不是“填一张表”，而是把客户现状、业务负载预期和 OpenShift 的硬性要求对齐，最终输出一份可执行的集群规模与拓扑设计。
一、客户现有基础设施调研
调研的目标是回答三个问题：现有资源能不能承载目标集群？哪些资源可以直接复用？哪些必须新增或改造？调研应覆盖计算、存储、网络、虚拟化平台和机房条件五个方面。
计算侧要记录物理机或虚拟机的 CPU 型号与核数、内存容量、NUMA 结构、是否开启超线程，以及虚拟化平台（VMware vSphere、KVM、裸金属）的类型和版本。OpenShift 对底层虚拟化有明确兼容性要求，例如 vSphere 需要匹配受支持的版本，且必须提供足够的 vCPU 与内存超分余量。存储侧要区分 etcd 所需的低延迟块存储、镜像仓库所需的对象存储或文件存储，以及业务持久化存储，分别记录 IOPS、吞吐和延迟指标。网络侧要确认可用 VLAN、MTU、DNS 解析、NTP 源、负载均衡器能力和出口带宽。机房侧则关注机柜空间、电力、散热和双路供电情况。
调研结果建议整理成一张现状清单，字段包括：资源类型、现有规格、可用余量、是否满足 OpenShift 要求、处置建议（复用/扩容/新增）。例如某客户现有 6 台物理服务器，每台 32 核 256GB 内存，但其中 2 台已被其他业务占用 60% 资源，则实际可用于 OpenShift 的只有 4 台加部分余量，必须据此重新计算。
二、资源评估与集群规模设计
资源评估的核心是把“业务需求”翻译成“节点数量与规格”。OpenShift 集群的资源消耗分为三部分：控制平面开销、集群基础组件开销、业务工作负载开销。
控制平面节点（master）运行 etcd、API Server、Controller Manager、Scheduler 等组件。官方建议控制平面节点至少 4 vCPU、16GB 内存，生产环境推荐 8 vCPU、32GB 内存，并使用 SSD 或 NVMe 存储，etcd 的 fsync 延迟应稳定低于 10ms。三个控制平面节点组成高可用仲裁，因此数量必须是 3 或 5，不能是 2。
基础组件包括 Ingress Router、镜像仓库、监控（Prometheus）、日志（Loki/Elasticsearch）、Operator 等。这些组件通常以 DaemonSet 或 Deployment 形式分布在工作节点上，需要预留约 10%～15% 的集群资源。以 3 节点工作集群为例，若每节点 16 vCPU、64GB，则基础组件大约占用 5～8 vCPU 和 15～20GB 内存。
业务负载评估要结合客户提供的应用清单，统计每个应用的副本数、CPU/内存 request 与 limit、是否有状态、是否需要 GPU 或特殊网络。一个实用的估算公式是：
所需工作节点数 = ceil( (业务总 request + 基础组件预留) / 单节点可分配资源 )
单节点可分配资源 = 节点总资源 × 0.75 // 预留 25% 给系统与突发例如业务总 request 为 120 vCPU、360GB 内存，基础组件预留 20 vCPU、60GB，则合计 140 vCPU、420GB。若单节点 32 vCPU、128GB，可分配约 24 vCPU、96GB，则至少需要 6 台工作节点（按 CPU 和内存分别计算取较大值）。实际设计还应增加 1～2 台冗余节点，以应对单节点故障和滚动升级。
三、节点规格选型与高可用拓扑设计
节点规格选型要避免“一刀切”。控制平面节点强调低延迟存储和稳定 CPU，建议独立部署，不与业务混跑；工作节点按业务类型分层，例如通用计算节点、内存优化节点、GPU 节点、边缘节点。基础设施节点（Infra 节点）可单独承载 Router、监控和日志，避免与业务争抢资源。
高可用拓扑设计需要同时考虑节点级、机架级和机房级故障域。三个控制平面节点必须分布在不同物理主机或不同机架上，etcd 才能容忍单点故障。工作节点也应跨机架分布，配合 Pod 反亲和性和拓扑分布约束，避免同一应用的多个副本落在同一故障域。如果客户有双机房，可采用“主备”或“延伸集群”模式，但延伸集群对网络延迟要求极高（etcd 节点间 RTT 通常要求小于 10ms），必须谨慎评估。
下图展示了一个典型的三控制平面、六工作节点、双机架分布的高可用拓扑，以及各层资源预留关系。
拓扑确定后，还需要把设计固化成可核对的参数表。以下是一份示例容量规划表，字段和数值均为教学假设，实际交付时应以客户真实调研数据替换。
| 节点角色 | 数量 | 单节点规格 | 存储要求 | 故障域分布 | 资源预留 |
|---|---|---|---|---|---|
| 控制平面 | 3 | 8 vCPU / 32GB | NVMe SSD ≥ 200GB，fsync < 10ms | 跨 3 个机架或物理主机 | 不承载业务 Pod |
| 基础设施 | 2 | 16 vCPU / 64GB | SSD ≥ 500GB | 跨 2 个机架 | Router/监控/日志专用 |
| 通用工作节点 | 6 | 32 vCPU / 128GB | 本地盘 + 网络存储 | 跨 2 个机架，每架 3 台 | 可分配 75% |
| 合计 | 11 | — | — | — | 业务可用约 144 vCPU / 576GB |
fsync 延迟是否稳定低于 10ms；工作节点 CPU/内存分配率是否长期低于 75%；单节点故障时业务 Pod 能否在剩余节点上完成重新调度。若任一条件不满足，应回到资源评估阶段调整节点规格或数量。
最后需要强调的是，环境评估与容量规划的输出不是一份静态文档，而是一组可验证的假设。交付前应把调研数据、估算公式、节点规格和拓扑图整理成设计说明，并与客户逐项确认。安装完成后，再用实际监控数据回头校验这些假设，才能形成从规划到验收的完整闭环。