2. OpenShift集群架构与交付边界
在OpenShift企业项目交付中，架构认知不是背景知识，而是划定交付范围、分配责任、识别风险的第一依据。很多项目在验收阶段出现争议，根源往往不在技术实现失败，而在于双方对“哪些组件属于交付方责任、哪些属于客户或平台既有能力”理解不一致。因此，在动手部署之前，必须先把集群的物理与逻辑架构拆解清楚，再据此建立责任矩阵。
一、四类节点的角色与交付含义
OpenShift集群在标准企业部署中通常划分为四类节点角色，每类节点承载不同的工作负载，也对应不同的交付动作和验收标准。
控制平面节点（Control Plane / Master）运行Kubernetes API Server、etcd、Controller Manager、Scheduler，以及OpenShift特有的API聚合层和OAuth服务。控制平面是集群的“大脑”，其高可用性直接决定集群可用性。交付时通常要求至少3台节点组成奇数etcd集群，部署前需确认节点间网络时延低于10ms、时钟同步偏差小于1秒。控制平面节点一般不承载业务Pod，交付边界上属于平台底座，验收重点是etcd健康状态、API响应延迟和证书有效期。
计算节点（Worker / Compute）是业务工作负载的实际运行位置，运行kubelet、CRI-O容器运行时和SDN/OVN网络代理。计算节点的交付范围通常包括节点注册、标签与污点配置、资源预留（system-reserved、kube-reserved）、以及节点级别的监控采集。验收时关注节点Ready状态、可分配资源、Pod密度和调度成功率。
基础设施节点（Infra）是OpenShift特有的角色划分，用于承载集群级共享服务：内部镜像仓库（Image Registry）、监控（Prometheus、Alertmanager）、日志（Loki或EFK）、路由（Ingress Router）、以及集群指标。将基础设施组件从计算节点分离，可以避免业务负载与平台服务争抢资源。交付时需通过节点选择器（nodeSelector）和污点（taint）确保这些组件被正确调度到Infra节点。
网络与存储组件横跨所有节点。网络侧包括OVN-Kubernetes或OpenShift SDN、Ingress Controller、DNS（CoreDNS）、以及可选的NetworkPolicy；存储侧包括CSI驱动、StorageClass、以及持久卷的动态供给能力。这两类组件是交付中最容易与客户既有基础设施产生交界的部分，必须在责任矩阵中明确“谁提供底层能力、谁负责集成配置”。
二、交付边界的三个关键切面
架构图给出的是技术视图，而交付边界需要在此基础上回答三个问题：谁提供、谁配置、谁验收。
第一个切面是基础设施层。物理服务器、虚拟机、交换机、负载均衡器、DNS、NTP、存储后端通常由客户或IDC提供。交付方的责任从操作系统层开始：确认RHCOS或RHEL节点可被正确引导、网络可达、时钟同步、订阅可用。如果客户提供的底层环境不满足要求，交付方应出具环境检查清单，而不是直接承担修复责任。
第二个切面是平台层。OpenShift自身的安装、配置、证书管理、etcd备份策略、监控告警规则、日志采集管道、镜像仓库配置、路由暴露方式，属于交付方的核心交付范围。这一层的验收标准应具体到可观测指标，例如：API Server 99分位延迟低于1秒、etcd leader切换时间小于15秒、Prometheus目标采集成功率高于99%。
第三个切面是应用接入层。命名空间规划、RBAC策略、资源配额、NetworkPolicy、CI/CD对接、镜像构建与推送流程，通常需要交付方与客户应用团队共同完成。边界划分建议以“平台能力就绪”和“应用可部署”为分界点：交付方保证平台侧就绪，应用团队负责自身工作负载的配置与验证。
三、责任矩阵的落地方式
责任矩阵不应停留在文档层面，而应嵌入交付流程。推荐做法是在项目启动阶段就建立一张RACI表，按组件维度逐项确认。以下是一个可参考的简化示例，实际项目中应根据客户环境和合同范围调整。
| 组件/能力 | 客户责任 | 交付方责任 | 验收依据 |
|---|---|---|---|
| 物理/虚拟基础设施 | 提供服务器、网络、存储后端 | 环境合规性检查 | 节点清单与连通性报告 |
| 控制平面 | 提供满足HA要求的节点 | 安装、证书、etcd备份策略 | etcd健康、API延迟、证书有效期 |
| 计算节点 | 提供节点资源 | 纳管、标签、污点、资源预留 | 节点Ready、调度成功率 |
| 基础设施节点 | 确认资源规格 | 调度策略、组件部署 | Registry/Monitoring/Logging可用 |
| 网络集成 | 提供底层网络与LB | OVN/SDN配置、Ingress暴露 | Pod互通、外部访问路由 |
| 存储集成 | 提供存储后端与凭据 | CSI驱动部署、StorageClass配置 | PVC动态供给、Pod挂载验证 |
四、常见边界争议与处理建议
在实际项目中，最容易产生争议的边界有三处。第一是网络策略与防火墙：客户安全团队可能要求所有Pod间流量经过防火墙审计，而OpenShift的OVN默认提供的是分布式网络策略，不经过集中防火墙。此时需要提前对齐安全要求，必要时引入NetworkPolicy或Service Mesh来满足合规。第二是存储性能：客户提供的存储后端IOPS不足导致数据库Pod性能不达标，责任容易扯皮。建议在交付前进行存储基准测试，将结果写入验收基线。第三是证书管理：集群入口证书、API证书、etcd证书的签发与轮换责任需要明确，避免到期时无人处理。
理解架构是划定边界的前提，而边界清晰是交付可控的基础。控制平面、计算节点、基础设施节点、网络与存储组件各自承担不同职责，也对应不同的交付动作和验收标准。把这些关系在项目早期就固化下来，后续的部署、测试和验收才能有据可依。