2. OpenShift集群规划与节点设计

OpenShift 集群规划不是简单地把若干服务器装成一台“大机器”，而是围绕控制平面、工作节点、网络出口、存储后端和故障域，提前确定拓扑形态、节点角色、副本数量与资源余量。规划阶段做出的决定，会直接影响后续升级窗口、故障恢复时间、Pod 密度上限以及扩容成本。本节围绕集群拓扑、控制平面与工作节点规划、高可用部署模式、资源容量评估与节点规格选型展开，并给出可落地的估算方法与示例参数。

一、集群拓扑：先确定故障域，再决定节点分布

拓扑设计的核心问题是：当一台物理机、一个机柜、一个可用区甚至一个机房失效时，集群还能不能继续提供服务。OpenShift 的控制平面组件（etcd、kube-apiserver、controller-manager、scheduler）对延迟和一致性敏感，因此控制平面节点通常要求部署在同一低延迟网络内，推荐分布在三个独立故障域（三台物理机或三个可用区）。工作节点则可以根据业务容忍度跨机柜、跨可用区分布，但必须考虑跨区网络延迟对存储和 Service 流量的影响。

常见拓扑形态有三类：单机房三控制平面加多工作节点，适合大多数企业内部私有云；三可用区均衡部署，控制平面与工作节点均跨三区，适合对可用性要求高的生产环境；边缘加中心两级拓扑，中心承载控制平面与核心业务，边缘节点就近处理数据采集或低延迟业务。选择时先明确业务可接受的 RTO/RPO，再反推故障域数量和副本策略，而不是先买机器再补拓扑。

OpenShift 三可用区高可用拓扑与故障域示意 可用区 A（故障域 1） 控制平面节点 cp-1 etcd / apiserver / scheduler 工作节点 worker-a1 业务 Pod / 路由入口 工作节点 worker-a2 业务 Pod / 监控代理 存储后端 A 本地盘 / 分布式存储副本 可用区 B（故障域 2） 控制平面节点 cp-2 etcd / apiserver / scheduler 工作节点 worker-b1 业务 Pod / 路由入口 工作节点 worker-b2 业务 Pod / 监控代理 存储后端 B 本地盘 / 分布式存储副本 可用区 C（故障域 3） 控制平面节点 cp-3 etcd / apiserver / scheduler 工作节点 worker-c1 业务 Pod / 路由入口 工作节点 worker-c2 业务 Pod / 监控代理 存储后端 C 本地盘 / 分布式存储副本 etcd 同步 etcd 同步 任一可用区整体失效时，剩余两个控制平面节点仍可维持 etcd 多数派（2/3），工作负载由其余区节点继续承载

二、控制平面与工作节点规划

控制平面节点承载 etcd 与 API Server，对磁盘 IOPS 和网络延迟最敏感。生产环境建议至少 3 台，规格不低于 8 vCPU / 32 GB 内存 / 低延迟 SSD，且 etcd 数据盘独立于系统盘。etcd 的写入延迟直接决定 API 响应速度，若使用共享存储或高延迟网络盘，集群在大量对象变更时会出现明显卡顿。控制平面节点不调度普通业务 Pod，避免业务负载抢占资源。

工作节点按业务类型分层是常见做法：通用节点承载普通微服务，计算型节点配置高主频 CPU 或 GPU，内存型节点承载缓存与大数据组件，边缘节点则靠近数据源。分层后通过 nodeSelector、taint/toleration 或 MachineSet 标签把工作负载约束到对应节点池。每类节点池应至少保留 1 台冗余，且同一节点池内节点规格尽量一致，便于容量估算和故障替换。

三、高可用部署模式

高可用不是“多买几台机器”，而是让每个关键组件都有冗余路径。控制平面采用三节点 etcd 集群，容忍 1 个节点故障；工作节点通过副本数、PodDisruptionBudget 和反亲和性，保证同一服务的多个副本分散在不同节点甚至不同可用区。入口层使用多个 Router/Ingress 副本并配合外部负载均衡健康检查；存储层根据后端能力选择三副本或跨区复制。

需要特别注意的是，高可用模式与升级策略相互影响。滚动升级时，若某节点池只有 1 台节点，升级会导致该池业务全部中断。因此规划阶段应保证每个节点池至少有 2 台节点，并预留可临时承载被驱逐 Pod 的余量。对于 etcd，升级期间必须逐台进行并确认成员健康后再继续。

四、资源容量评估与节点规格选型

容量评估从业务侧资源需求出发，而不是从机器规格倒推。先统计所有工作负载的 requests 总和，再叠加系统组件开销和预留余量。OpenShift 自身组件（监控、日志、网络插件、镜像仓库、Router 等）通常需要额外占用约 15%～25% 的集群资源。建议生产集群整体资源使用率控制在 60%～70%，为故障迁移和突发流量留出空间。

下面给出一个示例估算过程（参数为教学假设，非实测结果）：假设某业务共有 120 个 Pod，每个 Pod requests 为 0.5 vCPU / 1 GiB 内存，则业务总需求为 60 vCPU / 120 GiB。系统组件按 20% 计，需 12 vCPU / 24 GiB。再按 65% 目标使用率反推，集群可调度容量应约为 (60+12)/0.65 ≈ 111 vCPU，(120+24)/0.65 ≈ 222 GiB。若选用 16 vCPU / 64 GiB 的工作节点，并预留 2 vCPU / 4 GiB 给系统组件，则每台可调度约 14 vCPU / 60 GiB，至少需要 8 台工作节点；考虑 1 台冗余，规划 9 台。

示例容量估算（教学假设）：
业务 Pod 数：120
单 Pod requests：0.5 vCPU / 1 GiB
业务总需求：60 vCPU / 120 GiB
系统组件开销（20%）：12 vCPU / 24 GiB
目标使用率：65%
所需可调度容量：约 111 vCPU / 222 GiB
单节点可调度：14 vCPU / 60 GiB（16 vCPU / 64 GiB 规格）
所需节点数：ceil(111/14)=8，加 1 台冗余 → 9 台

节点规格选型还要关注单节点 Pod 密度上限。OpenShift 默认每节点最多 250 个 Pod，但实际受 CPU、内存、IP 地址池和网络性能限制。若单节点规划 40 个 Pod，9 台节点可承载约 360 个 Pod，满足 120 个业务 Pod 加系统 Pod 的需求。同时要检查节点 CIDR 是否足够：若每节点分配 /23 子网，可提供约 510 个 IP，足够 250 个 Pod 使用。

规划时建议同时输出一张节点清单，至少包含：节点角色、可用区、规格、可调度资源、所属节点池、承载业务类型、冗余数量。该清单可直接用于后续 MachineSet 创建和容量复核。
不要把控制平面节点与工作节点混部在资源紧张的生产集群中。etcd 对磁盘延迟敏感，业务 Pod 的突发 IO 可能拖慢 etcd，进而放大 API 延迟，严重时触发集群不可用。

综上，OpenShift 集群规划应遵循“先故障域、再角色、后容量”的顺序：拓扑决定冗余边界，角色划分决定调度策略，容量评估决定节点数量与规格。三者一致时，集群才能在故障、升级和扩容场景下保持稳定；若只关注单机规格而忽略故障域和余量，后续很难通过补机器彻底解决可用性问题。

← 上一章 📖 返回目录 下一章 →