2. OpenShift架构总览
OpenShift 是建立在 Kubernetes 之上的企业级容器平台，它的架构可以理解为“一套控制平面 + 两类工作负载节点 + 一组平台服务”的组合。理解这套架构的关键，不是记住组件名称，而是看清每个组件部署在哪里、由谁管理、承担什么职责，以及一次部署请求从提交到容器运行之间，数据和控制信号如何在集群中流动。
一、节点角色划分
从节点角色看，OpenShift 集群通常包含三类节点：
- 控制平面节点（control plane）：运行集群的“大脑”，包括 API Server、etcd、Controller Manager、Scheduler，以及 OpenShift 特有的 API Server 和 OAuth 等。它负责接收请求、存储期望状态、驱动实际状态收敛。
- 工作节点（worker）：运行用户业务容器。每个工作节点上运行 kubelet、CRI-O 容器运行时、kube-proxy 或 OVN-Kubernetes 网络代理，以及可选的监控、日志采集组件。
- 基础设施节点（infra）：承载平台自身服务，如内部镜像仓库、路由 Router、监控 Prometheus、日志 Elasticsearch/Loki、注册表、集群指标等。把平台服务与业务负载分开，可以避免平台组件抢占业务资源，也便于独立扩缩容。
在小型实验集群中，这三类角色可能合并到同一批节点；但在生产环境中，通常至少 3 台控制平面、若干工作节点和 3 台基础设施节点，以保证高可用和资源隔离。
二、核心组件与交互关系
控制平面内部，etcd 是唯一持久化存储集群状态的地方，所有对象（Pod、Deployment、Service、Route、BuildConfig 等）最终都写入 etcd。kube-apiserver 是所有请求的唯一入口，负责认证、授权、准入控制，并把对象变更写入 etcd。Controller Manager 通过 watch API Server 感知期望状态，并驱动实际状态向期望状态收敛。Scheduler 负责为新创建的 Pod 选择合适的工作节点。
OpenShift 在 Kubernetes 之上增加了若干关键组件：OpenShift API Server 提供 Route、BuildConfig、ImageStream 等扩展资源；OAuth Server 负责用户登录与令牌签发；Image Registry 提供内部镜像仓库；Router 基于 HAProxy 实现外部流量入口；Operator Lifecycle Manager 管理 Operator 的安装与升级。这些组件大多以 Pod 形式运行在基础设施节点上，由对应的 Operator 或 Deployment 管理。
三、一次部署请求的数据流
以“用户提交一个 Deployment”为例，可以清晰看到各组件如何协作：
- 用户通过
oc apply -f deployment.yaml把请求发送到 API Server。API Server 完成认证、授权和准入控制后，把 Deployment 对象写入 etcd。 - Deployment Controller 通过 watch 感知到新对象，创建对应的 ReplicaSet；ReplicaSet Controller 再创建 Pod 对象，同样写入 etcd。
- Scheduler 监听到“未绑定节点”的 Pod，根据资源请求、亲和性、污点容忍等规则，选择一个工作节点，并把绑定结果写回 API Server。
- 目标工作节点上的 kubelet 通过 watch 感知到“有 Pod 被绑定到本节点”，调用 CRI-O 拉取镜像、创建容器、配置网络。
- OVN-Kubernetes 为新 Pod 分配 IP 并更新网络转发规则；如果 Pod 需要对外暴露，Router 会根据 Route 或 Service 配置更新 HAProxy 后端。
- kubelet 持续把 Pod 状态上报给 API Server，Controller Manager 据此判断实际状态是否与期望状态一致，不一致则继续驱动收敛。
这条链路中，API Server 是唯一读写 etcd 的组件，其他组件都通过 API Server 间接访问集群状态。这种设计保证了状态一致性和访问控制的可审计性。
四、基础设施节点为什么单独划分
把 Router、Registry、Prometheus、日志存储等平台服务放在基础设施节点，主要出于三点考虑：
- 资源隔离：平台服务通常有稳定的资源需求，与业务 Pod 混部时容易互相影响。独立节点可以设置专用资源配额和调度策略。
- 可用性：基础设施节点可以单独扩缩容和升级，不会因为业务负载波动而影响平台服务。
- 安全边界：Router 和 Registry 往往需要暴露端口或访问外部存储，独立节点便于设置网络策略和防火墙规则。
在实际部署中，可以通过节点标签和污点把平台服务“固定”到基础设施节点。例如给节点打上 node-role.kubernetes.io/infra 标签，并配置 nodeSelector 或 tolerations，让 Router、Registry 等组件的 Pod 只调度到这些节点。
五、组件交互中的关键观察点
排查集群问题时，可以按以下顺序观察组件状态：
| 观察对象 | 常用命令 | 判断依据 |
|---|---|---|
| 控制平面 Pod | oc get pods -n openshift-kube-apiserver |
API Server、etcd、Controller Manager 是否 Running |
| 节点状态 | oc get nodes |
节点是否 Ready，角色标签是否正确 |
| 集群 Operator | oc get clusteroperators |
AVAILABLE、PROGRESSING、DEGRADED 三个状态 |
| Router 后端 | oc get route -A |
Route 是否被正确解析到 Service |
| 镜像仓库 | oc get pods -n openshift-image-registry |
Registry Pod 是否 Running，存储是否可写 |
oc get nodes 看到节点角色，但基础设施节点通常不会单独出现。生产环境建议至少 3 台控制平面、3 台基础设施节点和若干工作节点，以保证高可用和资源隔离。
理解 OpenShift 架构的核心，是建立“控制平面负责决策与状态存储、工作节点负责运行用户负载、基础设施节点负责承载平台服务”的分层认知。当出现部署失败、Pod 无法调度、外部访问不通等问题时，沿着“API Server → etcd → Controller → Scheduler → kubelet → CRI-O → 网络”这条链路逐段排查，就能快速定位问题发生在哪一层。