3. 冷启动问题分析：镜像拉取时的网络延迟、签名验证的计算开销、大规模集群部署时的资源争抢

在云原生环境中，工作负载的“冷启动”是指从 Pod 创建到容器完全就绪的过程。当引入 Sigstore 签名验证后，冷启动阶段会叠加三层新的性能瓶颈：镜像层数据的网络传输、签名工件的拉取与验证计算、以及大规模并发下的调度与 I/O 争抢。本章从这三个维度拆解冷启动的根因，为后续削峰策略提供量化依据。

3.1 镜像拉取时的网络延迟

镜像拉取是冷启动中最耗时的环节，其延迟主要由镜像大小、层数、注册表距离和并发连接数决定。Sigstore 验证并未减少镜像层数，反而额外增加了签名和 attestation 工件的拉取开销。

3.2 签名验证的计算开销

Sigstore 验证并非简单的哈希比对，而是涉及公钥获取、证书链校验、TUF 元数据验证和 Fulcio/OIDC 令牌验证。这些步骤在 CPU 和内存上都有显著消耗。

• Cosign 验证流程： 拉取签名 → 从 Rekor 获取透明日志条目 → 验证证书链（Fulcio 根证书） → 检查 OIDC 身份 → 比对镜像摘要。
• 计算密集型操作： ECDSA P-256 签名验证（约 0.5–1 ms/次）、TUF 根元数据签名验证（约 2–5 ms）、Rekor 条目 Merkle 证明验证（约 1–3 ms）。
• 内存开销： 每个验证实例需加载 Fulcio 根证书（~2 KB）、Rekor 公钥（~1 KB）、TUF 元数据（~50 KB），以及临时存储签名和 attestation 内容。

3.3 大规模集群部署时的资源争抢

当集群同时启动数百甚至数千个 Pod 时，冷启动的资源争抢从单节点扩展到集群层面，形成多级瓶颈。

• 网络带宽争抢： 所有节点同时从注册表拉取镜像，导致集群出口带宽饱和。Sigstore 签名拉取虽数据量小，但大量并发 HTTP 请求会耗尽注册表的连接池。
• CPU 争抢： 签名验证是 CPU 密集型操作。在 8 vCPU 节点上，同时验证 30 个 Pod 的签名会使 CPU 使用率飙升到 90% 以上，影响 kubelet 和容器运行时。
• 磁盘 I/O 争抢： 镜像层解压和签名工件写入临时目录会竞争磁盘 I/O。使用 SSD 时延迟较低，但 HDD 或共享存储（如 NFS）会成为显著瓶颈。
• kubelet 与容器运行时争抢： kubelet 的 Pod 创建循环、CRI-O/containerd 的镜像拉取和挂载操作、以及 Sigstore 验证进程共享同一组 CPU 和内存资源。

3.4 冷启动时间模型与量化

综合上述三个因素，冷启动时间可近似表示为：

T_coldstart = T_network + T_verify + T_contention

其中：
  T_network = Σ(layer_size / bandwidth) + N_layers × RTT_registry + N_layers × RTT_sig
  T_verify  = N_pods × (T_rekor + T_cert + T_digest)
  T_contention = f(CPU_util, disk_iops, conn_pool_depth)

3.5 削峰切入点总结

基于上述分析，削峰策略应聚焦于以下三个方向：