2. 云原生平台架构与故障域

要谈云原生平台的可靠性，第一步不是看监控大盘，而是把平台的“骨架”和“故障边界”画清楚。Kubernetes 集群在物理上由若干节点组成，在逻辑上被划分为控制面（Control Plane）与数据面（Data Plane）；节点又分布在不同的可用区（Availability Zone，AZ）。故障域正是沿着这些边界形成的：一个容器崩溃、一个节点宕机、一个可用区断网，影响范围完全不同。理解组件依赖关系与典型故障传播路径，是后续做容量规划、升级演练和故障注入的前提。

控制面与数据面：职责分离

控制面是集群的“决策中枢”，核心组件包括 kube-apiserver、etcd、kube-scheduler 和 kube-controller-manager。kube-apiserver 是所有请求的唯一入口，负责认证、鉴权、准入控制，并把对象状态写入 etcd；etcd 是唯一持久化存储，保存整个集群的期望状态，它的可用性直接决定集群能否被修改；kube-scheduler 负责把未绑定的 Pod 分配到合适节点；kube-controller-manager 通过控制循环不断把实际状态拉向期望状态。

数据面是“干活的地方”，由工作节点上的 kubelet、容器运行时（containerd 或 CRI-O）、kube-proxy 以及 CNI 网络插件组成。kubelet 接收 apiserver 下发的 PodSpec，调用运行时创建容器，并持续上报节点与 Pod 状态；kube-proxy 或 eBPF 数据路径负责 Service 的负载均衡；CNI 负责 Pod 网络连通。数据面承载真实业务流量，控制面本身不转发业务请求。

节点、可用区与故障域层级

故障域可以按影响范围从小到大排列：容器/进程 → Pod → 节点 → 可用区 → 区域（Region）。容器崩溃只影响单个 Pod；节点宕机影响该节点上所有 Pod；可用区故障则可能同时带走大量节点，若控制面或 etcd 成员集中部署在同一 AZ，甚至会导致集群失去管理能力。因此生产环境的基本要求是：控制面节点跨至少 3 个 AZ 部署，etcd 成员数为奇数（3 或 5），并保证 etcd 的跨 AZ 网络时延足够低。

下面这张图展示了控制面、数据面、节点与可用区之间的依赖关系，以及典型故障从底层向上传播的路径。

核心组件依赖关系

依赖关系决定了故障传播方向。apiserver 依赖 etcd 提供读写能力，etcd 一旦不可用，所有写操作（创建、更新、删除）都会失败，但读操作可能因缓存而短暂可用；scheduler 和 controller-manager 都通过 watch apiserver 工作，apiserver 不可用时它们无法做出新决策；kubelet 依赖 apiserver 获取 PodSpec，但已缓存的 Pod 会继续运行，这就是“控制面挂了业务还在跑”的原因。数据面内部，kubelet 依赖容器运行时创建容器，依赖 CNI 分配网络，依赖 kube-proxy 暴露服务，任一环节异常都会导致 Pod 无法正常提供服务。

典型故障传播路径

生产中最常见的传播路径有三类。第一类是 etcd 故障：etcd 成员磁盘 I/O 延迟升高或 leader 频繁切换，导致 apiserver 请求超时，进而 scheduler 无法调度、controller-manager 无法收敛副本，最终表现为新 Pod 一直 Pending、扩缩容失效。第二类是节点故障：节点宕机或 kubelet 停止上报，节点被标记 NotReady，默认 5 分钟后触发 Pod 驱逐，若副本数不足且没有 PDB 保护，业务容量会骤降。第三类是可用区故障：一个 AZ 网络中断，该 AZ 内所有节点同时 NotReady，若控制面或 etcd 多数派恰好落在该 AZ，集群可能彻底失去管理能力。

面向故障域的部署原则

基于以上分析，生产集群应遵循几条硬性原则：控制面节点跨 3 个 AZ 均匀分布，etcd 成员与 apiserver 同 AZ 配对部署以降低时延；工作节点至少跨 2 个 AZ，关键业务通过 topologySpreadConstraints 或 podAntiAffinity 打散；为关键服务配置 PodDisruptionBudget，避免驱逐时容量归零；对 etcd 单独使用低延迟 SSD，并监控 etcd_disk_wal_fsync_duration_seconds 的 P99。这些措施的本质，都是把故障限制在尽可能小的故障域内，防止单点故障沿依赖链向上传播。