3. 镜像缓存机制：本地缓存、远程缓存、分布式缓存架构设计

在 GitOps 工作流中，镜像拉取延迟是导致同步窗口超时的首要原因。当集群需要同时回滚数百个工作负载时，若每个节点都从远端仓库拉取同一镜像，不仅会耗尽 registry 出口带宽，还会因网络抖动导致 Pod 启动失败。本章深入剖析三种缓存架构的设计原理、适用场景及在 GitOps 同步窗口中的优化价值。

3.1 缓存架构分层模型

镜像缓存并非单一组件，而是一个从节点本地到全局共享的多级体系。下表对比了三种缓存层的关键差异：

3.2 本地缓存：节点级零拷贝加速

本地缓存是镜像拉取的第一道防线。当 kubelet 调度 Pod 到节点时，容器运行时首先检查本地存储中是否已存在目标镜像的 manifest 和 layer blob。

3.2.1 核心机制

• Snapshotter 快照层： containerd 使用 overlayfs snapshotter，将镜像 layer 挂载为只读层，容器写入层为可读写层。已缓存的 layer 直接复用 inode，无需解压。
• GC 保留策略： 默认保留最近 2 个未使用的镜像版本，可通过 image_pull_progress_deadline 和 image_gc_high_threshold 调整。
• 预拉取 DaemonSet： 在 GitOps 同步窗口开启前，通过 DaemonSet 将目标镜像版本提前分发到所有节点。

# containerd 配置示例：调整本地 GC 阈值
[plugins."io.containerd.grpc.v1.cri".containerd]
  discard_unpacked_layers = false
[plugins."io.containerd.grpc.v1.cri".containerd.default_runtime]
  runtime_type = "io.containerd.runc.v2"
[plugins."io.containerd.gc.v1.scheduler"]
  pause_threshold = 0.02   # 磁盘使用率超过 2% 时触发 GC
  deletion_threshold = 0.05 # GC 删除至使用率低于 5%
  mutation_threshold = 100  # 每 100 次变更触发一次 GC 扫描

3.3 远程缓存：集群级 Registry Mirror

当本地缓存未命中时，请求进入远程缓存层。远程缓存通常部署为与集群同区域的 Harbor 或 Docker Registry 的 Pull-through Proxy，或独立的 distribution/distribution 实例。

3.3.1 架构设计要点

• 上游绑定： 配置 proxy.remoteurl 指向源 registry（如 Docker Hub、ACR、ECR）。
• 缓存策略： 使用 LRU 淘汰 + TTL 过期（建议 manifest TTL=24h，layer TTL=72h）。
• 高可用： 至少 2 个副本 + 共享存储（NFS/S3），避免单点故障导致全集群拉取失败。

# Harbor 作为远程缓存：docker-compose 关键配置
proxy:
  http_proxy: ""
  https_proxy: ""
  no_proxy: "127.0.0.1,localhost,.local"
  components:
    - core
    - jobservice
    - registry

registry:
  storage:
    cache:
      layerinfo: redis
    filesystem:
      rootdirectory: /storage
    maintenance:
      uploadpurging:
        enabled: false
      readonly:
        enabled: false

3.4 分布式缓存：多集群全局共享层

对于跨多个 Kubernetes 集群的 GitOps 部署（如 Staging + Production 集群），本地和远程缓存无法解决“集群 A 已拉取，集群 B 仍需回源”的问题。分布式缓存通过全局元数据索引 + 对象存储实现一次拉取、全局复用。

3.4.1 核心组件

3.5 三级缓存协同架构图

下图展示了从 Pod 发起拉取请求到三级缓存逐级回退的完整流程：

3.6 缓存预热与 GitOps 同步窗口集成

缓存架构的最终价值体现在与 GitOps 同步窗口的联动。通过预热机制，在同步窗口开启前将目标镜像版本推送到各级缓存，可大幅降低窗口内的拉取延迟。

3.6.1 预热策略对比

# 使用 crane 工具进行差异预热：仅拉取新增 layer
#!/bin/bash
# 获取当前缓存中的 manifest
crane manifest <registry>/<repo>:current > /tmp/current.manifest
# 获取目标 manifest
crane manifest <registry>/<repo>:target > /tmp/target.manifest
# 对比 layer digest，只拉取差异部分
diff <(jq -r '.layers[].digest' /tmp/current.manifest | sort) \
     <(jq -r '.layers[].digest' /tmp/target.manifest | sort) \
     | grep '^>' | awk '{print $2}' | xargs -I {} crane blob <registry>/<repo>@{}

3.7 缓存一致性保障

分布式缓存面临的最大挑战是“缓存与源站不一致”。当源站镜像被覆盖（相同 tag 指向新 digest）时，缓存可能仍返回旧版本，导致 GitOps 回滚失败。

3.7.1 一致性策略

• Tag 不可变： 在 CI 阶段强制使用 digest 而非 tag 引用镜像，从源头消除覆盖问题。
• 缓存失效广播： 当源站镜像更新时，通过 Webhook 通知缓存代理清除对应 tag 的缓存条目。
• TTL 兜底： 设置合理的缓存 TTL（建议 manifest 不超过 1 小时），过期后强制回源校验。

# 缓存失效 Webhook 示例 (Go)
func handleImageUpdate(w http.ResponseWriter, r *http.Request) {
    var event RegistryEvent
    json.NewDecoder(r.Body).Decode(&event)
    
    for _, tag := range event.Tags {
        cache.Delete("manifest:" + event.Repo + ":" + tag)
        cache.Delete("layers:" + event.Repo + ":" + tag)
    }
    log.Printf("Cache invalidated for %s:%s", event.Repo, event.Tags)
    w.WriteHeader(http.StatusOK)
}