4. 动态注入概念：静态配置 vs 动态注入、注入时机

在 Containerd 运行时参数管理体系中，静态配置与动态注入是两种截然不同的参数交付模式。理解二者的差异，以及参数注入的时机选择，是构建可靠流水线集成测试的基础。

4.1 静态配置 vs 动态注入

静态配置指在容器启动前，通过配置文件或命令行参数一次性设定所有运行时参数；动态注入则允许在容器生命周期的特定阶段，通过外部机制修改或追加参数，而无需重建容器或重启整个工作负载。

4.2 注入时机：创建前 vs 运行中

动态注入的时机决定了参数生效的范围与风险。根据 Containerd 的容器生命周期，注入时机可划分为两个关键阶段：

• 创建前注入（Pre-Create Injection）：在 CRI RunPodSandbox 或 CreateContainer 请求发出之前，通过 Mutating Webhook、Initializer 或 CRI 代理修改请求体中的参数。此阶段注入的参数与静态配置等效，但由外部控制器动态生成。
• 运行中注入（Runtime Injection）：在容器进程启动后，通过 ctr 命令、CRI UpdateContainerResources 接口或 Sidecar 进程修改运行时参数。此阶段仅支持部分参数（如 cgroup 限制、OOM 分数、Capabilities 追加）。

4.3 注入时机选择矩阵

在实际的流水线集成测试中，需要根据参数类型与测试目标选择合适的注入时机：

4.4 动态注入的典型工作流

以下是一个基于 Mutating Webhook 的创建前注入工作流，展示了从 Pod 创建请求到 Containerd 最终执行的全过程：

1. 请求拦截：Kube-APIServer 收到 Pod 创建请求，触发 Mutating Webhook。
2. 参数注入：Webhook 根据标签或注解，向 Pod 的 annotations 或 containers[].resources 中追加运行时参数。
3. CRI 转换：Kubelet 将 Pod 转换为 CRI RunPodSandbox 和 CreateContainer 请求，携带注入后的参数。
4. Containerd 执行：Containerd 解析请求，将参数写入 OCI 规范配置，最终由 runc 创建容器。
5. 生效验证：测试工具通过 ctr 或直接读取容器状态，确认参数已生效。

4.5 流水线测试中的注入策略

在集成测试流水线中，建议采用以下策略覆盖两种注入时机：

• 基线测试：使用静态配置创建容器，验证默认参数行为，作为后续动态注入的对照基准。
• 创建前注入测试：通过模拟 Mutating Webhook 或直接修改 CRI 请求，注入安全上下文、资源限制等参数，验证容器启动后参数生效。
• 运行中注入测试：在容器运行后，通过 ctr tasks update 或 CRI UpdateContainerResources 修改 CPU/Memory 限制，验证 cgroup 文件实时更新。
• 边界测试：注入非法参数（如超出范围的 CPU 配额、不存在的 Capability），验证 Containerd 的拒绝或降级行为。