4. 冷启动问题定义：首次部署时签名验证延迟、证书获取瓶颈、日志写入积压
在 Sigstore 签名验证体系首次部署或从零开始扩容时，系统会经历一段资源饥渴与延迟飙升的“冷启动”窗口。本章从三个核心维度定义冷启动问题：签名验证延迟、证书获取瓶颈以及日志写入积压。理解这些问题的根因与量化特征，是后续削峰调优的前提。
4.1 冷启动的三类核心问题
冷启动并非单一故障，而是多个子系统在无预热状态下同时进入高负载的连锁反应。下表对比了三类问题的触发条件、影响范围与典型表现。
| 问题维度 | 触发条件 | 影响范围 | 典型表现 |
|---|---|---|---|
| 签名验证延迟 | 首次加载 TUF 根元数据、Fulcio 证书链、Rekor 日志索引 | 所有依赖 Sigstore 验证的准入控制器（如 Kyverno、Connaisseur） | Pod 创建阻塞 5~30 秒；验证超时导致准入 Webhook 失败 |
| 证书获取瓶颈 | 大量并发工作负载同时请求 Fulcio 签发短期证书 | Fulcio 实例、OIDC 身份提供商、网络出口带宽 | 429 Too Many Requests；OIDC 验证排队；TLS 握手失败 |
| 日志写入积压 | Rekor 日志树初始为空，大量写入请求同时涌入 | Rekor 数据库、存储后端（如 MySQL/PostgreSQL）、日志一致性检查 | 写入延迟 > 5 秒；检查点（Checkpoint）更新滞后；日志树分叉风险 |
关键指标： 冷启动窗口通常持续 3~15 分钟，期间 P99 验证延迟可达正常值的 10~50 倍。若未做削峰，准入 Webhook 超时率可能超过 5%，触发集群级拒绝。
4.2 签名验证延迟的根因分析
签名验证延迟的根因在于 Sigstore 的信任模型依赖多层元数据的首次获取与缓存填充。下图展示了首次验证时的完整调用链与瓶颈点。
优化方向： 预热缓存（TUF 元数据、Fulcio 证书链）、启用连接池复用、使用本地代理缓存 Rekor 日志索引。具体方案将在第 6~8 章展开。
4.3 证书获取瓶颈的量化特征
Fulcio 作为短期证书签发中心，在冷启动时面临双重压力：OIDC 身份验证排队与证书签名请求（CSR）并发。以下数据来自生产环境压测（100 个并发工作负载同时部署）。
- OIDC 验证延迟： 从 50ms（预热）飙升至 2.8s（冷启动），主要因 IdP 连接池未建立。
- CSR 处理排队深度： 峰值达 1200 个请求，Fulcio 工作线程数不足导致请求超时。
- 证书签发吞吐量： 冷启动初期仅 15 certs/s，预热后可达 200 certs/s。
- 网络出口带宽： 首次下载 Fulcio 中间 CA 证书链（~1.2 MB）时，并发请求导致带宽打满。
避坑提示： 不要在生产环境直接依赖公共 Fulcio 实例进行冷启动。公共实例有速率限制（通常 100 req/min），超限后返回 429 状态码，导致准入控制器永久阻塞。建议部署私有 Fulcio 实例或使用本地缓存代理。
4.4 日志写入积压的连锁效应
Rekor 日志的写入积压不仅影响当前部署，还会引发后续验证的级联延迟。下图展示了写入积压的传播路径。
4.5 冷启动问题的综合评估矩阵
为便于后续削峰策略的优先级排序，以下矩阵从影响严重性、发生频率和修复复杂度三个维度对三类问题进行了评估。
| 问题 | 影响严重性（1-5） | 发生频率（1-5） | 修复复杂度（1-5） | 优先级 |
|---|---|---|---|---|
| 签名验证延迟 | 5（直接阻塞部署） | 5（每次冷启动必现） | 3（缓存预热 + 连接池） | P0 |
| 证书获取瓶颈 | 4（导致准入失败） | 4（大规模并发时触发） | 4（需私有 Fulcio 或代理） | P1 |
| 日志写入积压 | 3（级联延迟，非直接失败） | 3（高写入量场景） | 5（需调整 Rekor 架构） | P2 |