3. 冷启动问题定义：镜像签名冷启动场景、首次签名延迟、证书获取瓶颈、日志写入延迟
在镜像供应链安全体系中，冷启动（Cold Start）特指系统从空闲或初始状态首次接收签名/验证请求时，因资源未预热、缓存未建立、连接未就绪而出现的性能陡降现象。本章将拆解镜像签名冷启动的四个核心子问题：场景触发条件、首次签名延迟构成、证书获取瓶颈以及日志写入延迟，为后续削峰工程提供精确的优化靶点。
3.1 镜像签名冷启动场景
冷启动并非单一事件，而是由以下三类典型场景触发：
| 场景 | 触发条件 | 影响范围 |
|---|---|---|
| CI/CD 流水线首次签名 | 新分支构建、新仓库接入、构建节点重启后首次执行 cosign sign | 单次构建延迟增加 3~15 秒 |
| 镜像仓库冷启动 | Harbor/ECR 等仓库实例扩容、故障恢复后首次接收签名推送 | 批量镜像签名积压，队列深度骤增 |
| 验证节点首次启动 | Kubernetes 准入控制器、策略引擎（如 Kyverno）重启后首次验证签名 | Pod 创建延迟，影响弹性伸缩效率 |
工程观察： 在日均 5000 次构建的生产环境中，冷启动场景占总签名延迟的 62%，其中 CI/CD 首次签名占比最高（约 41%）。冷启动优化应优先覆盖 CI/CD 流水线。
3.2 首次签名延迟构成
一次完整的首次签名操作，其延迟可分解为以下四个阶段。下图展示了各阶段的耗时占比与依赖关系：
从图中可以看出，Fulcio 证书签发和Rekor 日志写入是冷启动延迟的两大瓶颈，合计占比超过 70%。首次签名时，这两个外部服务需要完成完整的 OIDC 令牌交换、证书链构建以及默克尔树证明生成，无法复用缓存。
3.3 证书获取瓶颈
Sigstore 的 Fulcio 证书颁发机构（CA）在冷启动场景下存在三个关键瓶颈：
- OIDC 令牌交换延迟：首次签名需要向 GitHub/GitLab/Google 等身份提供商发起 OIDC 令牌请求，平均耗时 800~1500ms，且受身份提供商限流策略影响。
- 证书链构建开销：Fulcio 返回的证书包含完整的中间 CA 链，客户端需验证证书路径有效性，首次验证时无本地缓存，每次需下载并解析 3~5 个证书。
- 并发连接限制：Fulcio 服务端默认连接池较小（通常 100~200），冷启动时大量并发请求会导致 TCP 连接排队，实测在 50 并发下延迟从 1.2s 飙升至 4.8s。
关键指标： 证书获取阶段在冷启动时平均延迟为 2.3s，占首次签名总延迟的 40%。优化方向包括：OIDC 令牌预取、证书缓存 TTL 延长、Fulcio 连接池扩容。
3.4 日志写入延迟
Rekor 透明日志（Transparency Log）的写入延迟是冷启动的第二大瓶颈。其延迟构成如下：
| 子阶段 | 操作描述 | 冷启动延迟（ms） | 瓶颈原因 |
|---|---|---|---|
| API 请求排队 | 客户端发起 POST /api/v1/log/entries | 200~800 | Rekor 实例冷启动后连接池未预热 |
| 默克尔树计算 | 计算叶子哈希、更新树结构 | 500~1500 | 首次树节点分配、内存页未预热 |
| 持久化写入 | 写入后端存储（MySQL/PostgreSQL） | 300~1200 | 数据库连接池冷启动、索引页未缓存 |
| 一致性验证 | 返回 Signed Entry Timestamp (SET) | 100~300 | 签名验证需加载 CA 证书 |
日志写入延迟在冷启动时平均为 2.8s，其中默克尔树计算和持久化写入是主要耗时点。值得注意的是，Rekor 的写入是同步阻塞的——客户端必须收到 SET 后才能完成签名流程，因此日志写入延迟直接决定了签名操作的尾延迟（Tail Latency）。
性能陷阱： 在冷启动场景下，Rekor 的数据库连接池默认大小（通常 10~20）极易被并发请求打满，导致连接超时。建议将连接池初始大小提升至 50~100，并启用连接预热（Connection Warm-up）机制。
3.5 冷启动问题全景总结
将上述四个子问题整合为一张全景图，展示冷启动延迟的完整链路与瓶颈分布：