2. K8s架构与故障边界：控制平面与数据平面的故障隔离
在Kubernetes集群中，故障域（Failure Domain）的划分首先取决于架构分层。控制平面（Control Plane）与数据平面（Data Plane）的故障隔离策略完全不同：控制平面组件故障通常导致集群管理能力丧失，但已运行的Pod不受影响；数据平面故障则直接影响工作负载的可用性。理解这一边界是精准排错的前提。
2.1 控制平面组件故障影响范围
控制平面由etcd、API Server、Scheduler、Controller Manager四个核心组件构成。下表总结了各组件的故障模式与影响范围：
| 组件 | 故障模式 | 直接影响 | 间接影响 | 恢复手段 |
|---|---|---|---|---|
| etcd | Leader丢失、磁盘IO Hang、网络分区 | API Server不可读写，集群状态冻结 | 所有kubectl操作失败，调度/控制器停摆 | etcd集群多数节点恢复；快照重建 |
| API Server | OOM、证书过期、RBAC配置错误 | kubectl/自动化工具无法连接 | Webhook、准入控制、CRD失效 | 重启kube-apiserver容器；更新证书 |
| Scheduler | 调度队列阻塞、节点过滤错误 | 新Pod无法调度，Pending状态 | Deployment/HPA扩容卡住 | 重启scheduler；检查nodeSelector/taint |
| Controller Manager | Leader选举失败、循环控制器死锁 | Deployment/StatefulSet/Job不调谐 | Node Controller失联，节点状态异常 | 重启kube-controller-manager；检查--leader-elect |
关键原则：控制平面故障不会杀死已运行的Pod。即使API Server完全不可用，节点上的kubelet仍会维持现有Pod的运行状态，但无法执行滚动更新、扩缩容、健康检查回调等依赖API Server的操作。
2.2 数据平面故障影响范围
数据平面主要指工作节点（Worker Node）及其上的kubelet、容器运行时（containerd/CRI-O）、kube-proxy、CNI插件。故障影响直接作用于Pod：
- kubelet故障：节点状态变为NotReady，Pod状态无法上报，但Pod进程可能仍在运行；kubelet重启后恢复。
- 容器运行时故障：无法创建/销毁容器，Pod启动失败；已有容器不受影响，但无法响应健康检查。
- kube-proxy故障：Service规则未同步，ClusterIP/NodePort访问异常；Pod间通信可能中断。
- CNI插件故障：Pod网络不通，无法分配IP；跨节点通信完全中断。
排错陷阱：不要将节点NotReady等同于Pod已死。kubelet故障时，Pod进程可能仍在运行，但kubectl get pods会显示Unknown状态。此时应直接SSH到节点检查容器运行时状态，而非盲目删除Pod。
2.3 故障隔离边界：控制平面 vs 数据平面
下图展示了控制平面与数据平面的故障隔离边界，以及各组件故障的传播路径：
排错口诀：“控制面挂了，Pod还在跑；数据面挂了，Pod就没了。” 遇到集群故障时，先判断是控制平面还是数据平面问题，再决定排错路径。
2.4 故障场景与kubectl debug切入点
基于故障边界，我们可以制定针对性的kubectl debug策略：
| 故障现象 | 故障域 | kubectl debug命令 | 预期输出 |
|---|---|---|---|
kubectl get nodes 超时 |
控制平面（API Server/etcd） | kubectl get --raw /healthz |
返回ok或具体错误码 |
| Pod一直Pending | 控制平面（Scheduler） | kubectl describe pod <pod> |
Events中显示FailedScheduling |
| 节点NotReady | 数据平面（kubelet） | kubectl get node <node> -o yaml |
status.conditions显示HeartbeatFailure |
| Service不通 | 数据平面（kube-proxy/CNI） | kubectl exec <pod> -- curl <cluster-ip> |
连接超时或拒绝 |
| Deployment不滚动 | 控制平面（Controller Manager） | kubectl get deployment <deploy> -o yaml |
status.observedGeneration与metadata.generation不一致 |
2.5 故障隔离的架构原则
- etcd多数原则：etcd集群需要多数节点（quorum）才能对外服务。3节点集群容忍1个节点故障，5节点集群容忍2个节点故障。故障节点数超过容忍阈值时，整个集群不可写。
- API Server无状态：API Server本身无状态，故障后重启即可恢复。但若etcd不可用，API Server也无法启动。
- Scheduler/Controller Manager Leader选举：多副本部署时，只有Leader执行实际工作。Leader故障后，其他副本在lease超时后接管，通常有15-30秒的切换窗口。
- kubelet自愈：kubelet故障时，节点上的Pod由kubelet进程管理。kubelet重启后，会重新接管已有Pod，不会自动删除。
实战建议：在生产环境中，控制平面组件应部署为static Pod或systemd服务，并配置健康检查探针。数据平面节点应设置PodDisruptionBudget，确保故障时不会同时驱逐过多Pod。
2.6 故障边界快速判断流程
当收到告警时，按以下步骤快速定位故障域：
- 检查API Server可达性：
kubectl cluster-info或curl -k https://<apiserver>/healthz。如果失败，进入控制平面排错。 - 检查节点状态：
kubectl get nodes。如果节点NotReady，进入数据平面排错。 - 检查Pod状态：
kubectl get pods --all-namespaces。如果Pod Pending，检查Scheduler；如果Pod CrashLoopBackOff，检查容器运行时和镜像。 - 检查Service/网络：
kubectl get svc和kubectl get endpoints。如果endpoints为空，检查kube-proxy和CNI。