Kubernetes 架构：组件、控制流程与故障边界
梳理 API Server、etcd、Scheduler、Controller 和 kubelet 的职责，解释 Pod 的启动流程、调度与准入边界，以及不同故障应查看的证据。
Kubernetes 架构由管理集群状态的控制平面，以及运行容器化工作负载的工作节点组成。用户通过 API 提交期望状态，API Server 处理请求，controller、scheduler 和 kubelet 根据 API 中的状态履行各自职责；容器运行时则执行 kubelet 发来的 CRI 请求。它并不是一台“主服务器”按固定顺序指挥所有组件的流水线。
本文解释组件分工、从 API 到 Pod 的控制过程，以及怎样区分不同故障边界。依据是 Kubernetes 官方文档，不是对特定云服务内部网络的实测。文章由观测云编辑部编写；观测云的产品文档仅用于说明采集路径，不能代替 Kubernetes 机制证据。文中的三个实验方案均未执行，没有实测输出或恢复时间。
若还不熟悉 Pod、声明式管理以及 Kubernetes 的适用条件，可以先看 Kubernetes 是什么。
逻辑架构不等于物理拓扑
官方组件文档将集群描述为控制平面与一个或多个工作节点。自建集群可能由团队管理各组件的部署、升级及恢复；托管服务则由供应商承担其中一部分。组件可以共用机器，也可以跨机器或可用区分布。
网络、存储和云资源的连接方式取决于插件及部署形式。因此，本文讨论的是逻辑职责，不把一个概念图当作所有 EKS、GKE、AKS 或私有集群的唯一物理路径。责任分界仍应以实际服务文档和合同为准。
控制平面：保存意图并持续协调
| 组件 | 职责 | 首先检查的证据 | 单凭这些证据不能确定什么 |
|---|---|---|---|
| kube-apiserver | 提供 Kubernetes HTTP API | API 响应、认证授权错误、日志及指标 | 延迟究竟来自 etcd、网络、准入还是客户端 |
| etcd | 一致性键值存储，保存 API Server 使用的数据 | 健康状态、日志、指标及 API 症状 | 业务代码或用户请求的错误原因 |
| kube-controller-manager | 运行多个控制器，使实际状态接近期望状态 | 对象 spec/status、事件及控制器信号 |
协调失败的最终原因或业务结果 |
| kube-scheduler | 为尚未绑定节点的 Pod 选择节点 | PodScheduled 条件、事件及调度器日志 |
选中节点后镜像能否拉取、应用能否正常运行 |
| cloud-controller-manager | 将云特定控制逻辑与 Kubernetes 核心组件分离 | 云资源状态及相应控制器信号 | 所有集群都存在此组件或使用同一实现 |
API Server 是共享状态的入口，不是完成所有任务的中央执行器。控制器反复观察状态并请求变更，调度器和 kubelet 也通过 API 独立工作。不能将这一过程理解成一个长同步函数。
etcd 也不是任何应用或组件都可以直接读写的通用业务数据库。访问权限、备份和恢复，应围绕其保存集群 API 状态的职责单独设计。
工作节点：把 Pod 声明变成容器执行
| 组件或边界 | 作用 | 条件与例外 | 首批证据 |
|---|---|---|---|
| kubelet | 管理分配到本节点的 PodSpec，并执行配置的探针 | 不负责节点上任意非 Kubernetes 容器 | Pod 条件、事件、kubelet 日志及指标 |
| 容器运行时 | 处理镜像和容器执行生命周期 | 需要 CRI 兼容；Docker Engine 需要 cri-dockerd 等适配器 |
运行时日志、镜像拉取结果、kubelet 症状 |
| kube-proxy 或替代网络实现 | 实现 Service 规则与流量路径 | 部分网络插件可替代 kube-proxy | Service、EndpointSlice、数据路径及网络检查 |
| Pod | 一个或多个共享上下文的容器组成的最小可部署单元 | 临时实体，通常由工作负载控制器管理 | Pod 配置、状态、容器状态及探针 |
容器运行时文档说明了 CRI 边界。Docker Engine 本身不实现 CRI，内置 dockershim 已于 Kubernetes v1.24 移除。不要把某一种运行时或 socket 路径当作所有版本的永久默认值。
kubelet 只执行已经配置的探针。readiness 成功不代表数据一致性、外部依赖和整条用户旅程都正确；没有配置应用探针时，Ready 更不能证明已经执行过业务检查。
从 API 请求到运行中的 Pod
下面是提交 Deployment 后的概念过程，各组件的重试与协调可以异步发生，不是网络包的精确顺序。
- 客户端通过
kubectl或 API 提交工作负载声明，API Server 处理请求。 - 被接受的 API 状态保存在 etcd；不是客户端绕过 API 直接写 etcd。
- 工作负载控制器观察期望和实际状态，按需调整 ReplicaSet 与 Pod 对象。
- 调度器发现尚未分配节点的 Pod，根据资源请求、约束、策略和可用节点选择放置位置。
- 目标节点的 kubelet 观察分配给自己的 Pod，通过 CRI 请求运行时准备并运行容器。
- kubelet 更新容器状态及 Pod 条件，执行探针；其他组件和用户继续通过 API 观察状态。
客户端 → kube-apiserver ↔ etcd（API 状态）
↑
┌─────────┼──────────┐
│ │ │
controller scheduler kubelet
观察/写入 观察/绑定 观察分配的 Pod/更新状态
│
▼
CRI 兼容运行时 → 容器
这是一幅根据官方机制整理的逻辑图，不是实验抓包结果。排障时应把对象变化、事件、组件日志、指标及执行层证据放到同一时间轴，不能只凭一次 status 截图就认定某个组件有问题。
工作负载与访问路径要分层看
Deployment通过 ReplicaSet 管理 Pod 的声明式更新；三个名字不是同一个对象的不同叫法。Service提供访问抽象，EndpointSlice则表示后端端点及其条件。
| 层次 | 检查对象或信号 | 能回答的问题 | 还需要其他证据的问题 |
|---|---|---|---|
| Deployment | 更新状态、条件、ReplicaSet | 目标版本和副本替换是否推进 | 每次业务请求是否成功 |
| Pod | phase、条件、容器状态、探针 | 执行或准备是否出错 | Service 和外部依赖是否正常 |
| Service / EndpointSlice | selector、端口、地址和端点条件 | 是否存在候选后端、是否可参与路由 | 后端业务响应是否正确 |
| 网络 / DNS | 名称解析、连通性和数据路径 | 请求能否到达后端 | 应用计算是否正确 |
| 应用 / 用户 | 日志、链路、请求结果、SLO、RUM | 实际服务和用户旅程受到什么影响 | 控制平面哪个组件是最终原因 |
有 endpoint 不等于请求成功，应用出现 5xx 也不等于控制平面故障。对象身份与时间必须对应，才能逐层验证假设。
通信与安全边界
控制平面与节点通信文档区分了节点访问 API，以及 API Server 访问 kubelet、Pod 或 Service 的路径。
- kubelet 和使用 Kubernetes API 的节点组件与 API Server 通信，需要认证、授权及传输保护。
- 容器运行时通常通过本地 CRI 接收 kubelet 请求，不能据此认为运行时直接 watch Kubernetes API。
- 登录成功不等于拥有所有对象权限；认证和授权需要分别检查。
- kubelet API、API Server 到节点的路径、隧道及云供应商连接方式，随部署而变。
- 端口、证书、ServiceAccount、网络策略及加固步骤，应使用目标版本的官方配置文档。
任何实验记录都应控制原始凭证的访问，并在公开前去除 kubeconfig、token、证书私钥、客户数据及内部地址。本篇不要求把这些资料复制到文章或截图中。
高可用和故障域不是一回事
多个控制平面实例，不会自动让业务具备高可用。kubeadm 高可用拓扑讨论堆叠与外置 etcd；多可用区文档讨论副本如何跨故障域分布。需要分别检查：
| 故障边界 | 可能症状 | 首批证据 | 需要单独设计的内容 |
|---|---|---|---|
| API Server / 控制平面 | API 不可用、延迟、认证错误或协调停滞 | API 响应及组件信号 | 拓扑、负载均衡、etcd 保护与恢复 |
| etcd | API 状态读写异常 | etcd 与 API Server 的关联症状 | 仲裁、备份、恢复、访问控制 |
| 节点 / 运行时 | 镜像拉取或容器执行失败 | Node/Pod 条件、事件和节点日志 | 容量、镜像仓库、运行时和宿主机 |
| 调度约束 | 已创建 Pod 尚未绑定节点 | spec.nodeName、PodScheduled 和调度事件 |
requests、affinity、taint/toleration、节点容量 |
| ResourceQuota / 准入 | 创建或更新被拒绝，新 Pod 可能不存在 | API 错误、ReplicaSet FailedCreate、namespace 配额 |
配额、资源请求及准入政策 |
| 可用区 / 网络 / 存储 | 一组节点、卷或访问路径受影响 | 按拓扑关联的对象与网络、存储证据 | 副本分布、存储恢复及依赖布局 |
| 应用 | 5xx、延迟、错误结果 | 应用日志、链路、SLO、用户检查 | 冗余、数据一致性、依赖及回滚 |
Pending 不只意味着等待调度，也包括节点已经分配后的镜像下载及容器准备。ResourceQuota超额则可能让 API 以 403 Forbidden 拒绝创建，连待调度 Pod 都没有。两种情况的检查入口不同。
这张表是调查起点，不是自动根因树。同一症状可以跨多个边界出现；恢复时间和可用性承诺还需要合同或固定环境的测试支持。
用可观测性连接这些层次
官方可观测性文档说明了指标、日志及链路的作用；集中日志也需要在容器生命周期之外设计收集与保留。
调查时先固定时间、集群、namespace、工作负载、Pod UID 与节点，然后读取对象状态和 owner 关系，寻找协调差异。事件可以提示调度、拉镜像或探针变化，但不是单独的根因证明。再用相应组件的日志与指标缩小范围，最后检查应用请求和用户结果是否随修复恢复。
观测云的 Kubernetes 集成、Prometheus 自动发现及 ServiceMonitor / PodMonitor 支持字段可作为采集配置入口。它们说明产品公开支持的路径，具体权限、版本、字段映射及限制仍须在目标环境验证，不能视作任意集群都已实测通过。
三个尚未执行的故障实验
实验旨在区分故障边界，不用于比较供应商性能，也不能证明观测云自动定位了原因。三个方案都没有执行结果、截图或耗时记录。
执行前的共同条件
使用一次性的非生产 kind 或同类集群，固定 Kubernetes 补丁版本、kind、运行时、CNI、宿主机系统与架构。对工作负载镜像的来源和 digest、清单、资源限制与探针做版本管理。保存命令、原始输出、退出码、时间、对象 YAML、事件、组件证据及清理结果；公开副本应脱敏，再由另一位工程师复现。
实验一：调度边界
计划提交要求不存在节点标签或无法满足约束的 Pod，收集 phase、条件、调度事件和可选节点信息。修正后再次观察绑定。要区分“还未选中节点”和“已选中节点但执行失败”。本文没有实际观察 Pending 状态、具体事件或绑定耗时。
实验二：节点与运行时边界
计划使用不存在的镜像 digest 或 tag，收集容器状态、事件、kubelet、运行时及仓库请求证据，再恢复已知可用镜像。已完成调度不意味着已经拉取并运行镜像。本文没有实测 ErrImagePull、ImagePullBackOff 或其他具体状态。
实验三：readiness 与 EndpointSlice 边界
计划部署固定失败的 readiness probe 与 Service，随后修正探针。记录 Pod Ready 条件、探针结果、selector、EndpointSlice 地址及 ready、serving、terminating，同时记录 Service 的 publishNotReadyAddresses 与实际请求。
容器运行、Pod 就绪、地址存在、流量资格及业务响应是五种不同事实。未就绪 Pod 可以留在 EndpointSlice，开启 publishNotReadyAddresses 时端点还可能被标记为 ready。本文没有测得端点变化顺序或恢复时间。
在原始输出与第二次复现记录齐备前，这些实验只能作为待执行方法，不能改写为“已测”“已验证”或某产品的优势证明。官方文档支持机制解释，实验只能支持特定环境中实际观察到的结果。
继续学习与实施
定义和适用边界见 Kubernetes 是什么。深入配置应使用当前官方的架构、组件及目标版本的安装、安全文档。
若要评估观测云在生产环境中的监控路径，可以参考Kubernetes 监控方案，再以一个测试集群验证对象、指标、日志、权限与缺失数据。产品说明和概念解释都不能替代这一步。
一次资料
2026 年 10 月 27 日按官方文档复核技术机制，未执行上述实验。
