1. 运行时流水线概述
1.1 定义运行时流水线
运行时流水线（Runtime Pipeline）是指从容器运行时接收底层事件、经过采样与过滤、触发策略判定、最终执行自动化运维动作的完整数据链路。在云原生场景下，这条流水线将原本离散的容器生命周期事件（创建、启动、退出、GC 触发等）串联为可观测、可控制、可审计的闭环流程。
核心特征：事件驱动、非阻塞、可扩展、低延迟。运行时流水线不直接参与业务流量，而是作为“带外”控制通道，保障容器运行时的健康与资源回收。
| 层次 | 组件 | 职责 |
|---|---|---|
| 事件源 | Containerd / CRI-O | 产生容器生命周期事件（TaskCreate、TaskExit、TaskOOM 等） |
| 采样层 | Event Collector | 订阅事件流，按策略采样（全量/降频/过滤） |
| 策略引擎 | Policy Evaluator | 匹配规则，决定是否触发 GC 或告警 |
| 执行层 | GC Executor / Reporter | 执行镜像清理、磁盘回收、事件归档 |
1.2 事件驱动架构在容器编排中的角色
容器编排系统（Kubernetes、Nomad 等）本质上是状态机驱动的控制循环，而事件驱动架构为其提供了低延迟、高响应的“感知-决策-执行”能力。在运行时流水线中，事件驱动架构承担以下关键角色：
- 解耦事件生产与消费：Containerd 只负责产生事件，不关心谁消费；采样器、GC 模块独立部署，互不阻塞。
- 按需采样降低开销：全量事件流可能达到每秒数千条，通过采样策略（如降频采样、标签过滤）减少无效处理。
- 异步复核保障正确性：GC 操作前先复核事件上下文（如镜像引用计数、容器状态），避免误删正在使用的镜像。
- 可观测性注入点：每个事件经过采样、过滤、决策、执行阶段均可埋点，形成端到端追踪链路。
实践建议：在 Containerd 事件流中，
TaskExit 和 TaskOOM 是触发镜像 GC 复核的高频事件，建议优先配置采样规则。
1.3 Containerd 作为核心组件的定位
Containerd 是云原生计算基金会（CNCF）毕业项目，作为 Kubernetes 默认的容器运行时，其定位不仅是“拉镜像、跑容器”的执行器，更是运行时流水线的核心事件源与状态中枢。
| 维度 | Containerd 角色 | 对流水线的意义 |
|---|---|---|
| 事件生产者 | 通过 events API 发布容器生命周期事件 |
提供原始事件流，是采样与 GC 触发的第一入口 |
| 镜像仓库客户端 | 管理镜像拉取、挂载、解压、引用计数 | GC 复核时查询镜像引用状态，避免误删 |
| 快照管理器 | 管理容器层（snapshotter）的创建与删除 | GC 执行时清理未使用的快照层，回收磁盘空间 |
| 命名空间隔离 | 支持多租户命名空间（k8s.io、default 等） | 事件采样与 GC 策略可按命名空间差异化配置 |
1.4 事件采样与镜像 GC 复核的关联
镜像 GC（Garbage Collection）是运行时流水线的典型执行动作，而事件采样决定了 GC 触发的时机与精度。两者通过以下机制协同：
- 事件触发：Containerd 发布
TaskExit事件，采样器捕获后判断是否需要启动 GC 复核。 - 引用复核：GC 执行前查询 Containerd 的镜像引用计数，确认镜像未被其他容器使用。
- 分层清理：先清理未被引用的镜像层（snapshotter 层），再清理镜像元数据。
- 事件归档：GC 完成后生成
ImageGCCompleted事件，供下游审计或监控消费。
注意：直接基于全量事件触发 GC 可能导致频繁的磁盘 I/O 和锁竞争。建议在生产环境中配置采样率（如每 10 次 TaskExit 采样 1 次），并配合磁盘使用率阈值做二次确认。