2. OpenShift核心组件与故障域映射

OpenShift 的稳定性不是由某一个组件单独决定的，而是由控制面、节点运行时、网络与入口、以及 Operator 编排层共同构成的“故障域链”。理解这条链的关键，不是背组件清单，而是建立一张映射表：每个组件负责什么、它失效时最先出现什么现象、哪些现象会被误判成别的组件故障。本节围绕 API Server、etcd、Controller Manager、Scheduler、kubelet、CRI-O、SDN、Ingress、Operator 展开，重点讲清它们的故障表现与关联关系。

一、控制面：API Server 是“总入口”，etcd 是“唯一真相源”

API Server 是所有声明式操作的唯一入口。kubectl、Operator、控制器、kubelet 都通过它读写对象。它本身通常是无状态的多副本 Deployment，故障表现具有明显的“入口特征”：kubectl 报 Unable to connect to the server、503、etcdserver: request timed out，或大量 apiserver 日志出现 context deadline exceeded。此时要区分是 API Server 自身过载、后端 etcd 慢，还是网络到 API Server 的 VIP/负载均衡不通。

etcd 保存集群全部对象状态，是唯一真相源。它一旦不可用，API Server 会从“可读可写”退化为“不可写甚至不可读”，表现为创建/更新对象超时、Leader 选举频繁、etcdserver: leader changed、磁盘 fsync 延迟升高。etcd 的故障域非常“硬”：它不依赖上层组件，但上层全部依赖它。因此排障顺序上，etcd 的健康度优先于任何控制器现象。

二、控制器与调度器：负责“把期望变成现实”

Controller Manager 运行各类控制器（Deployment、ReplicaSet、Node、Endpoint 等），持续把实际状态向期望状态收敛。它失效时，典型现象是“对象存在但不动”：Deployment 不创建 ReplicaSet、ReplicaSet 不补 Pod、Node 状态不更新、Service 的 Endpoint 不刷新。注意，这类现象常被误判为“Pod 调度失败”，实际是控制器没有工作。

Scheduler 只负责为未绑定的 Pod 选择节点。它失效时，Pod 会停留在 Pending，事件里出现 no nodes available 或 FailedScheduling。与 Controller Manager 的区别是：Scheduler 不创建 Pod，只做绑定决策；如果 Pod 根本没被创建，问题在控制器而非调度器。

三、节点侧：kubelet 与 CRI-O 是“执行末端”

kubelet 是节点上的代理，负责 Pod 生命周期、探针、卷挂载、状态上报。它异常时，节点会变为 NotReady，Pod 被标记为 Unknown，事件出现 NodeNotReady、PLEG is not healthy。CRI-O 是容器运行时，负责真正拉镜像、起容器。它异常时，kubelet 日志出现 failed to run pod sandbox、image pull failed，Pod 卡在 ContainerCreating。两者关系是：kubelet 调用 CRI-O，CRI-O 失败会表现为 kubelet 报错，但根因在运行时。

四、网络与入口：SDN 与 Ingress 决定“通不通、进不进得来”

SDN（OpenShift 中常见 OVN-Kubernetes 或 OpenShift SDN）负责 Pod 网络、Service 负载均衡、网络策略。它故障时，Pod 可能 Running 但跨节点不通、Service ClusterIP 无法访问、DNS 解析异常、NetworkPolicy 误拦截。Ingress（Router）负责集群外部 HTTP/HTTPS 入口，故障表现为外部访问 503/504、路由不生效、证书错误，而集群内部 Service 仍正常。区分点：内部通、外部不通，优先查 Ingress；内部也不通，优先查 SDN 与 DNS。

五、Operator：把“组件运维”变成“声明式对象”

OpenShift 大量组件由 Operator 管理，如 ClusterVersionOperator、etcd Operator、Ingress Operator、网络 Operator。Operator 故障时，表现为对应 ClusterOperator 的 DEGRADED=True 或 PROGRESSING 长时间不结束。它既是故障源，也是排障入口：oc get clusteroperators 能快速定位哪个域异常。

六、故障域关联：不要孤立看现象

这些组件不是并列关系，而是有明确依赖方向：Operator 管理控制面与网络组件；API Server 依赖 etcd；Controller Manager 与 Scheduler 依赖 API Server；kubelet 依赖 API Server 与 CRI-O；SDN 为所有 Pod 提供网络；Ingress 依赖 SDN 与 Service。因此一个现象往往对应多个可能域。例如“Pod 一直 Pending”，可能是 Scheduler 没工作，也可能是节点 NotReady 导致无可调度节点，还可能是资源不足或污点。再如“Service 访问不通”，可能是 SDN 故障、Endpoint 未生成（Controller Manager 问题）、或 NetworkPolicy 拦截。

七、排障检查表示例