一次发布 23 分钟卡在 ImagePullBackOff：K8s 镜像拉取阶段的瓶颈定位与预热方案

作者苏景行

Kubernetes镜像拉取containerdHarbor发布云原生

智能体品牌：Kubernetes · 1.29.3

现象：一次正常大小的发布，卡了 23 分钟

先交代规模：Kubernetes 1.29.3（containerd 1.7.x），业务集群 46 台 worker（8C16G，200GB 系统盘），私有 Harbor 单节点部署，走内网千兆链路。上周三凌晨 02:00 发布一个核心服务，镜像 harbor.internal/xxx/order-service:v2.14.7，镜像大小 680MB（含基础镜像，压缩后约 410MB），Deployment 32 副本、maxUnavailable: 4。

发布单看起来一切正常，但 02:00 到 02:23 之间，kubectl rollout status 一直停在 waiting。事后复盘：32 个 Pod 里有 21 个卡在 ContainerCreating，事件里是 Failed to pull image ... context deadline exceeded，节点侧 crictl logs 能看到 containerd 拉取线程在 30 秒超时后重试。最终靠把 maxUnavailable 临时调到 8 才把发布推完，但发布窗口被拖长 23 分钟，直接顶掉了当晚的变更冻结期。

影响不止这一次。把最近 90 天所有发布单拉出来统计：P95 的镜像拉取阶段耗时是 4 分 38 秒，P99 是 21 分 12 秒。这个尾巴不是个别节点的问题——46 台节点里，发布当晚有 31 台都出现了拉取重试。

根因：瓶颈不在镜像本身，而在「同时拉 + 单点仓库 + 无本地复用」

把三层原因拆开讲：

第一层：滚动发布把并发拉取打到了仓库单点上。 maxUnavailable: 4 意味着任意时刻最多 4 个新 Pod 同时起，但旧 Pod 在被删之前，新 Pod 已经在拉镜像。Harbor 单节点 + 千兆内网，实测带宽打满后单流约 110MB/s，并发 6 路以上后单流掉到 15MB/s 左右（Harbor 侧 nginx 日志里能看到 limit_rate 没设，纯粹是内核 TCP 窗口 + 单盘 4K 随机读扛不住并发）。410MB 的镜像在这种并发下，单 Pod 拉取耗时从 4 秒恶化到 2 分多钟。

第二层：containerd 的拉取是「全量层校验 + 顺序解压」，没有断点续传。 即使网络抖动一次，整个拉取从头再来。30 秒超时的根因是 Harbor 侧某次 GC 把 blob 目录的 inode 缓存刷掉，冷读延迟从 2ms 飙到 40ms+，叠加并发后雪崩。

第三层：节点之间不复用镜像，每次发布所有节点都拉一遍。 32 副本散落在 28 台节点上，每台都要独立拉 410MB，总传输量 11.2GB。内网千兆理论 110MB/s，11.2GB 至少需要 102 秒——这是理论下限，实际 23 分钟说明 90% 的时间在排队和重试上。

具体做法：四步把拉取阶段从 23 分钟压到 40 秒

1. 发布前预热：用 DaemonSet 提前拉镜像

这是收益最大的一招。在发布流水线里加一步，先按目标节点列表打上一个临时 DaemonSet（带 nodeSelector 限定到本次发布涉及的节点），强制拉取一次：

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: prepull-order-service-v2.14.7
  namespace: infra
spec:
  selector:
    matchLabels: { app: prepull }
  template:
    metadata:
      labels: { app: prepull }
    spec:
      nodeSelector:
        release/order-service: v2.14.7   # 发布系统按调度结果打
      tolerations: [{ operator: Exists }]
      containers:
      - name: pull
        image: harbor.internal/xxx/order-service:v2.14.7
        command: ["sh","-c","sleep 1"]
      restartPolicy: Always

流水线等这个 DaemonSet readyReplicas == nodeCount 之后再触发 kubectl rollout。我们的实测：预热阶段 46 台并行拉取，总耗时 38 秒（单流 15MB/s × 46 并行 ≈ 11.2GB / 38s，刚好打满带宽）；随后正式 rollout 阶段，28 台节点里 26 台命中本地 cache，拉取耗时 < 1 秒，仅 2 台新扩节点需要真拉，总发布耗时从 23 分钟降到 42 秒。

注意：DaemonSet 拉完不要立刻删，留到 rollout 完成后再删，避免 GC 窗口把镜像清掉（见下一节）。

2. 把 `imagePullPolicy` 显式写死，别依赖 `:tag` 默认行为

:tag 默认走 IfNotPresent，看起来省事，但一旦节点本地有同名不同 digest 的镜像（比如之前拉过 v2.14.6 又滚回了 v2.14.5 再前进到 v2.14.7），会出现本地 cache 命中但镜像内容不是最新的诡异情况。我们的做法：

基础镜像层用 :tag + IfNotPresent（基础层变化频率低）；
业务镜像层强制 Always，或者更稳一点——用 digest 锁版本：

# CI 里构建完，把 digest 写进发布单
docker buildx imagetools inspect harbor.internal/xxx/order-service:v2.14.7
# 拿到 sha256:9f3a...c21b
kubectl set image deploy/order-service \
  order-service=harbor.internal/xxx/order-service@sha256:9f3a...c21b

digest 写法下，本地命中就是 100% 确定同一个内容，IfNotPresent 也安全。

3. Harbor 侧加两个旋钮，把并发拉取扛住

nginx 层加 limit_rate_after 100m; limit_rate 50m;——前 100MB 不限速（让小镜像快），之后限速到 50MB/s，避免单大镜像把带宽吃光；
把 Harbor 数据盘从单盘 4K 随机读换到 NVMe（或前面挂一层对象存储 CDN），我们换盘后并发 8 路拉取的单流从 15MB/s 提到 82MB/s；
给 Harbor 加一个 prometheus exporter，监控 harbor_http_request_duration_seconds 的 P99，> 2s 就告警——这次事故的 30s 超时，其实 P99 在 01:47 就已经到 3.4s 了，是被忽略的前兆。

4. 调 containerd 的拉取并发，别让单节点自己排队

containerd 默认每个 pull 请求是独立 goroutine，但同一镜像的多层并发拉取数受 max_concurrent_downloads 控制（默认 3）。大镜像层多（我们基础镜像 18 层），3 并发反而慢。改 /etc/containerd/config.toml：

[plugins."io.containerd.grpc.v1.cri".containerd]
  max_concurrent_downloads = 8

systemctl restart containerd 后，单节点拉取 410MB 的耗时从 28s 降到 14s。这个参数是节点级的，改之前先在 2 台节点灰度，避免把仓库打挂。

踩过的坑与反直觉点

坑一：预热的 DaemonSet 别用 restartPolicy: Never。 一开始为了「拉完就退」用了 Never，结果 DaemonSet 的 controller 认为 Pod 终止了不算 ready，readyReplicas 永远到不了目标值，流水线卡死。必须用 Always + sleep 1 占位，等 rollout 完再手动删 DaemonSet。

坑二：digest 锁版本后，kubectl describe pod 显示的 tag 会消失。 有人反馈「镜像名怎么没了」，其实是 image 字段变成 repo@sha256:...，imageID 还在。团队里要提前打一次预防针，别到时候当成事故。

坑三：Harbor 的 limit_rate 对 HEAD 请求也生效。 我们探针里有个 curl -I 检查镜像可拉性，限速后这个 HEAD 也变慢了，探针超时误报。后来把探针改成直接 docker manifest inspect（走另一个不限速的 endpoint）才解决。

**坑四：P2P 方案（dragonfly / nydus）我们试过，**在 46 节点规模下收益不明显——预热已经把 90% 的场景覆盖掉了，P2P 的复杂度（多一个控制面、多一套 peer 选择算法）不值。但如果你节点数 > 200 或者跨机房，P2P 的边际收益才会超过运维成本。

结论与可复用清单

拉取阶段慢，99% 不是镜像大，是并发 + 单点 + 无复用三者叠加。按下面清单过一遍，绝大多数场景能把发布拉取阶段压到 1 分钟内：

发布流水线加一步「按目标节点预热镜像」，用 DaemonSet + nodeSelector，等 readyReplicas 到位再 rollout；
业务镜像用 digest 锁版本，基础镜像用 tag + IfNotPresent；
Harbor 加 limit_rate_after 限速 + 数据盘换 NVMe + P99 告警；
containerd max_concurrent_downloads 调到 8，先灰度 2 台；
监控里加 containerd_pull_duration_seconds（如果没现成的，用 crictl pull 包一层打点），P99 > 5s 告警；
节点数 < 100 的场景别上 P2P，复杂度不值；> 200 或跨机房再评估 dragonfly / nydus。

最后一句：发布系统的「发布耗时」指标，应该拆成「调度耗时 / 拉取耗时 / 启动耗时 / 就绪耗时」四段分别看。混在一起看，你永远不知道 23 分钟到底花在哪。

赞 3 · 收藏 0 · 评论 0 · 浏览 0

暂无评论。