1. 控制面与容器运行时概述
1.1 Kubernetes 控制面组件全景
Kubernetes 控制面（Control Plane）是集群的“大脑”，负责全局决策、状态存储与调度编排。控制面由四个核心组件构成，它们通过 API 与容器运行时（Container Runtime）协同工作，完成 Pod 的创建、调度与生命周期管理。
| 组件 | 核心职责 | 与容器运行时的交互方式 |
|---|---|---|
| API Server | 集群统一入口，认证授权、RESTful API 网关 | 间接：通过 kubelet 将 Pod 规范下发至运行时 |
| etcd | 分布式键值存储，保存集群全部状态数据 | 无直接交互：存储 Pod/容器元数据 |
| Scheduler | 将未调度的 Pod 绑定到最优 Node | 无直接交互：调度决策依赖 Node 状态与资源视图 |
| Controller Manager | 运行各类控制器，确保实际状态趋近期望状态 | 间接：通过 API Server 驱动 kubelet 调用运行时 |
关键认知：控制面组件不直接调用容器运行时的 CRI 接口。所有容器操作均由每个 Node 上的 kubelet 代理执行，kubelet 是控制面与容器运行时之间的唯一桥梁。
1.2 容器运行时：containerd 与 CRI-O
容器运行时负责拉取镜像、创建/启动/停止容器、管理容器文件系统与网络命名空间。Kubernetes 通过 CRI（Container Runtime Interface） 统一抽象层与运行时通信。当前主流运行时为 containerd 和 CRI-O。
| 特性 | containerd | CRI-O |
|---|---|---|
| 出身 | Docker 公司剥离，CNCF 毕业项目 | Red Hat / SUSE 主导，OCI 原生 |
| CRI 集成 | 内置 CRI 插件（cri-containerd） | 原生实现 CRI，无额外 shim |
| 镜像管理 | 自有镜像存储层，支持 snapshotter | 直接使用 containers/storage |
| 进程模型 | containerd → containerd-shim → runc | crio → conmon → runc |
| 监控指标 | 内置 Prometheus metrics | 通过 conmon 暴露容器进程指标 |
1.3 控制面 ↔ 容器运行时交互流程
从用户提交 Pod 到容器实际运行，控制面与容器运行时之间经历了一条完整的调用链。下图展示了核心交互路径：
1.4 关键交互路径详解
- Pod 创建请求：用户通过 kubectl 或客户端向 API Server 提交 Pod 资源定义。API Server 完成认证、鉴权与准入控制后，将 Pod 对象持久化到 etcd。
- 调度决策：Scheduler 通过 Watch 机制监听未调度的 Pod，结合 Node 资源可用性、亲和性约束等策略，将 Pod 绑定到目标 Node，并将绑定结果写回 API Server。
- kubelet 同步：目标 Node 上的 kubelet 通过 List-Watch 从 API Server 获取分配给自己的 Pod 列表。当发现新的 Pod 时，kubelet 调用 CRI 接口向容器运行时发送
RunPodSandbox和CreateContainer请求。 - 运行时执行：容器运行时（containerd 或 CRI-O）接收 CRI 请求后，通过 OCI 运行时（runc/crun）创建容器进程，配置 cgroups、命名空间、挂载点等隔离环境。
- 状态回写：kubelet 定期通过 CRI 的
PodSandboxStatus和ContainerStatus接口查询容器状态，并将 Pod 状态同步回 API Server，最终写入 etcd。
故障排查启示：控制面与容器运行时之间的交互链路上存在多个故障点——API Server 过载、etcd 读写延迟、Scheduler 调度失败、kubelet 与运行时之间的 CRI 超时、运行时 OCI 调用异常等。后续章节将逐一深入这些场景的根因分析与治理方法。
1.5 控制面与运行时的治理边界
在故障治理中，明确控制面与容器运行时的责任边界至关重要：
| 故障现象 | 可能根因（控制面侧） | 可能根因（运行时侧） |
|---|---|---|
| Pod 一直 Pending | Scheduler 未调度、API Server 限流、etcd 写入慢 | Node 资源不足（kubelet 上报） |
| Pod 创建超时 | kubelet 与 API Server 网络中断、Watch 超时 | 镜像拉取慢、containerd/CRI-O 进程 hang |
| Pod 频繁重启 | Controller Manager 误判、资源版本冲突 | OCI 运行时 OOM、cgroup 配置错误 |
| 节点 NotReady | kubelet 心跳上报失败、API Server 负载高 | 容器运行时 socket 不可达、runc 死锁 |
治理原则：排查时优先确认控制面组件是否健康（API Server 响应、etcd 集群状态、Scheduler 队列深度），再深入 Node 侧检查 kubelet 日志与容器运行时指标。切忌跳过控制面直接重启运行时，否则可能掩盖上游问题。