1. OpenShift复杂故障诊断全景

OpenShift 的复杂故障之所以“复杂”，往往不是因为单个组件坏了，而是因为控制面、网络、存储、认证、调度与工作负载之间存在多层耦合。一个 Pod 反复重启，可能根因在 etcd 的写延迟；一次路由 503，可能根因在 SDN 的 OVS 流表或 DNS 解析链路。因此，本章先建立一张“诊断全景图”：把故障按层次与性质分类，明确诊断时应遵循的原则，再给出恢复策略的选择逻辑，最后搭建一套可反复演练的实战环境。

一、故障分类：按“层次”与“性质”双维度切分

在 OpenShift 中，建议用两个维度同时定位故障。第一个维度是层次：基础设施层（节点、内核、容器运行时 CRI-O、kubelet）、控制面层（etcd、kube-apiserver、controller-manager、scheduler）、网络层（OVN-Kubernetes/OpenShift SDN、DNS、Ingress Router、Service/Endpoint）、存储层（PV/PVC、CSI 驱动、后端存储）、认证与权限层（OAuth、RBAC、SCC）、应用层（Deployment、Pod、探针、配置与镜像）。第二个维度是性质：可用性故障（服务不可达、Pod 不调度）、性能故障（延迟升高、etcd 慢查询）、一致性故障（状态漂移、Operator 反复调和）、配置故障（错误 ConfigMap、证书过期）、以及安全类故障（SCC 拒绝、镜像拉取被拒）。

把两个维度交叉，就能快速缩小范围。例如“Pod 一直 Pending”属于应用层+可用性，但根因可能落在调度器、节点资源或 PVC 绑定；而“Router 间歇性 503”属于网络层+性能，根因可能在 Endpoint 抖动或 OVN 流表收敛。分类的价值在于：它决定了你第一眼看什么、用什么命令、以及是否需要升级为集群级事件。

二、诊断原则：先证据，后结论

复杂故障诊断最容易犯的错误是“凭经验直接跳到结论”。建议遵循四条原则。第一，先建立时间线：记录故障首次出现时间、最近一次变更时间、告警触发时间，三者对齐往往能直接锁定嫌疑对象。第二，自下而上排查：先确认节点 Ready、kubelet 与 CRI-O 正常，再看 etcd 与 apiserver 健康，然后看网络与 DNS，最后才看应用。第三，交叉验证：不要只信一个信号，例如 Pod 事件说“镜像拉取失败”，还要看节点上的 CRI-O 日志与镜像仓库连通性。第四，变更即嫌疑：任何配置、证书、Operator 升级、网络策略变更都应优先回看。

三、恢复策略：按“影响面”与“可逆性”选择

恢复策略不是越激进越好，而是按影响面和可逆性排序。对于单 Pod 异常，优先 oc delete pod 触发重建；对于节点异常，先 oc adm drain 驱逐再修复；对于配置错误，优先回滚 ConfigMap/Secret 并重启相关工作负载；对于证书过期，使用 oc adm certificate approve 或重新签发；对于 etcd 性能问题，先扩容或调整磁盘，再考虑碎片整理。每一步都要记录“做了什么、观察到什么、是否恢复”，形成可复盘的证据链。

四、实战环境搭建：可反复演练的沙箱

本课程需要一个可反复破坏与恢复的环境。推荐使用单节点 OpenShift（SNO）或三节点 UPI 集群，至少 8 vCPU、32 GB 内存、200 GB SSD。安装完成后，先验证核心组件：

oc get nodes
oc get clusteroperators
oc get pods -n openshift-etcd
oc get pods -n openshift-ovn-kubernetes
oc get route -n openshift-console

随后部署一个用于演练的示例应用，包含 Deployment、Service、Route 与 PVC，便于后续制造网络、存储、探针类故障：

oc new-project fault-lab
oc create deployment web --image=quay.io/openshifttest/hello-openshift:1.2.0 --replicas=2
oc expose deployment web --port=8080
oc expose service web
oc set probe deployment/web --readiness --get-url=http://:8080/ --initial-delay-seconds=5

建议同时准备一个“故障注入清单”，例如：删除某个 Pod、修改 Service selector、设置错误就绪探针、模拟节点 NotReady、制造 PVC 绑定失败。每次演练前记录基线状态，演练后对比 oc get events、oc logs、oc describe 的输出，形成自己的诊断手册。