2. Kubernetes 核心组件回顾：kubelet、kube-controller-manager、kube-scheduler、etcd 在自愈中的角色
Kubernetes 的自愈能力并非由单一组件实现，而是由控制面与节点面的多个核心组件协同完成。理解每个组件在自愈闭环中的具体职责，是设计事件驱动自愈策略的基础。本章聚焦四个关键组件：kubelet、kube-controller-manager、kube-scheduler 和 etcd，分析它们在检测、决策、调度与持久化环节中的角色。
2.1 自愈闭环：从故障检测到恢复
Kubernetes 的自愈是一个持续循环的过程，通常包含以下四个阶段：
- 检测（Detect）：发现 Pod、节点或应用状态异常。
- 决策（Decide）：判断是否需要恢复，以及如何恢复。
- 调度（Schedule）：为新的或迁移的 Pod 选择合适的节点。
- 执行（Execute）：在目标节点上启动容器，完成恢复。
下表展示了四个核心组件在自愈闭环中的主要参与阶段：
| 组件 | 主要参与阶段 | 自愈中的核心职责 |
|---|---|---|
| kubelet | 检测、执行 | 健康检查（Liveness/Readiness）、上报节点状态、重启异常容器 |
| kube-controller-manager | 检测、决策 | 通过控制器循环（如 Deployment、StatefulSet）对比期望状态与当前状态，触发扩缩容或重建 |
| kube-scheduler | 调度 | 为待调度的 Pod 选择满足资源、亲和性、污点容忍等条件的节点 |
| etcd | 持久化 | 存储集群的期望状态（Spec）与当前状态（Status），为检测与决策提供一致性数据源 |
2.2 kubelet：节点自愈的执行者
kubelet 是运行在每个工作节点上的主要代理，直接负责 Pod 的生命周期管理。在自愈场景中，kubelet 承担以下关键任务：
- 健康检查执行：定期执行 Liveness Probe 和 Readiness Probe。Liveness 失败时，kubelet 直接重启容器；Readiness 失败时，将 Pod 从 Service 端点中移除。
- 节点状态上报：通过 Node Status 机制定期向 API Server 上报节点条件（如 Ready、DiskPressure、MemoryPressure）。如果节点失联，controller-manager 会基于 NoExecute 污点驱逐 Pod。
- 容器重启策略：根据 Pod 的
restartPolicy（Always/OnFailure/Never）决定是否自动重启退出的容器。
关键指标： kubelet 的 Liveness Probe 失败后，默认在
failureThreshold * periodSeconds 时间内触发重启。例如 failureThreshold=3、periodSeconds=10，则最快 30 秒后容器被重启。
2.3 kube-controller-manager：自愈的决策大脑
kube-controller-manager 运行一系列控制器，每个控制器负责一种资源的状态调和。自愈相关的核心控制器包括：
| 控制器 | 自愈职责 | 检测机制 |
|---|---|---|
| Deployment Controller | 确保期望的 Pod 副本数运行；当 Pod 因故障被删除或驱逐时，自动创建新 Pod | 监听 ReplicaSet 变化，对比 spec.replicas 与当前运行数 |
| StatefulSet Controller | 维护有状态 Pod 的序号与存储卷绑定；Pod 丢失后重建并保留身份 | 监听 Pod 状态，确保每个序号对应一个运行中的 Pod |
| Node Controller | 监控节点健康，对失联节点添加 node.kubernetes.io/unreachable 污点，并驱逐 Pod |
基于 Node Status 的时间戳，超过 node-monitor-grace-period（默认 40s）即标记为 Unknown |
| EndpointSlice Controller | 当 Pod 就绪状态变化时，更新 EndpointSlice，确保流量只导向健康 Pod | 监听 Pod 的 Ready 条件变化 |
自愈触发链示例： 节点宕机 → Node Controller 检测到心跳超时 → 节点标记为 Unknown → 超过
pod-eviction-timeout（默认 5 分钟）后，控制器驱逐该节点上的 Pod → Deployment Controller 发现副本数不足 → 创建新 Pod → Scheduler 调度到健康节点 → kubelet 启动容器。
2.4 kube-scheduler：自愈恢复的调度引擎
当控制器决策需要创建新 Pod 来替换故障实例时，kube-scheduler 负责为这个待调度 Pod 选择最优节点。调度过程分为两个阶段：
- 过滤（Filtering）：排除不满足 Pod 资源请求、污点容忍、节点选择器等硬性条件的节点。
- 打分（Scoring）：对剩余节点进行优先级排序，考虑资源利用率、Pod 亲和性、拓扑分布约束等软性条件。
在自愈场景中，调度器需要特别关注以下因素：
- 资源碎片：避免将恢复的 Pod 调度到资源即将耗尽的节点，防止二次故障。
- Pod 反亲和性：如果故障 Pod 因节点故障而丢失，调度器应尽量将新 Pod 调度到不同节点，提高容错能力。
- 拓扑分布约束：对于跨可用区部署的应用，调度器会尽量将 Pod 分散到不同故障域。
2.5 etcd：自愈状态的一致性存储
etcd 是 Kubernetes 的分布式键值存储，保存集群的所有配置数据和状态信息。在自愈闭环中，etcd 提供以下关键能力：
- 期望状态持久化：用户通过 API Server 写入的
spec（如 Deployment 的 replicas、Pod 模板）存储在 etcd 中，作为自愈的基准。 - 当前状态记录：kubelet 上报的 Pod 状态、节点状态等
status信息也写入 etcd，供控制器读取对比。 - Watch 机制：控制器通过 etcd 的 Watch API 实时监听资源变化，无需轮询，实现秒级自愈响应。
etcd 高可用注意事项： etcd 集群通常部署 3 或 5 个节点，使用 Raft 协议保证强一致性。如果 etcd 集群不可用，整个 Kubernetes 控制面将无法进行任何自愈决策。建议对 etcd 进行定期备份，并监控其磁盘 I/O 与网络延迟。
2.6 组件协作：一个完整的自愈事件流
以下是一个典型的自愈事件序列，展示四个组件如何协同工作：
- 故障发生：工作节点上的容器进程崩溃，kubelet 的 Liveness Probe 连续失败。
- kubelet 执行重启：kubelet 根据
restartPolicy: Always尝试重启容器。如果重启成功，自愈结束；如果持续失败，kubelet 将 Pod 状态更新为CrashLoopBackOff。 - 控制器介入：Deployment Controller 通过 Watch 发现 Pod 处于 CrashLoopBackOff，但副本数未变。如果用户配置了
maxUnavailable或minReadySeconds，控制器可能决定重建 Pod。 - 调度新 Pod：控制器创建新的 Pod 对象，kube-scheduler 为其选择健康节点。
- 执行恢复：目标节点的 kubelet 拉取镜像并启动容器，通过 Readiness Probe 后，Pod 重新接入 Service。
2.7 组件自愈能力对比总结
| 组件 | 自愈范围 | 响应速度 | 依赖条件 |
|---|---|---|---|
| kubelet | 单节点、单容器 | 秒级（Liveness 周期内） | 节点本身健康、容器运行时正常 |
| kube-controller-manager | 集群级别、工作负载 | 秒级到分钟级（取决于 Watch 与调谐周期） | API Server 与 etcd 可用 |
| kube-scheduler | 跨节点调度 | 毫秒级（调度周期） | 存在可用节点满足资源需求 |
| etcd | 数据持久化与一致性 | 不直接参与自愈，但影响所有组件 | 集群多数节点在线、磁盘与网络正常 |
自愈设计原则： 优先依赖 kubelet 的本地重启（快速、低成本），失败后再由控制器层进行全局重建（慢速、高可靠性）。事件驱动自愈的核心在于：通过监听 etcd 中的状态变化事件，在控制器决策之前或之外，插入自定义的修复逻辑。