我最近帮一个团队优化大规模任务调度遇见一个特别扎眼的现象上百个节点同时扩容业务 Pod 全卡在ContainerCreating排到 kubelet 一看日志清一色在拉镜像。Kubernetes 节点提前拉取 / 预热镜像这个话题就是在这种场景下被逼着啃透的。所谓预热本质是让目标节点在真正需要某个镜像之前先把镜像层从远端仓库落到本地磁盘把 Pod 启动从“分钟级拉镜像”变成“秒级本地加载”。这篇文章我会把常见的预热方案全部拆一遍从节点初始化脚本到 DaemonSet 常驻预热再到离线导入、P2P 分发适合正在做集群扩容、批量任务调度、离线交付或者被镜像拉取超时折磨过的 SRE / 平台工程师。1. 预热镜像之前先看清“镜像拉取”这个瓶颈1.1 Kubelet 拉镜像到底慢在哪Kubernetes 原生的调度流程是“先调度后拉取”。Pod 被调度到某个节点后kubelet 才根据容器的imagePullPolicy决定是否拉取镜像。如果节点本地没有这个镜像就会立刻从镜像仓库开始拉取一层层下载、解压、写入磁盘。这个流程在单节点、单镜像的场景下感觉不出问题一旦遇到批量扩容或者大镜像痛点非常明显。我曾经处理过一个真实案例数据团队要跑一轮仿真任务一下子扩容 80 个节点每个节点都需要拉一个接近 12GB 的模型镜像。80 个节点同时回源到同一个镜像仓库仓库出口带宽马上被打满很多节点拉取几十分钟后直接超时失败失败后 kubelet 重试仓库又开始限流整个集群像是一堆车堵在同一个收费站谁也别想过去。除了网络带宽镜像拉取还受几个隐性因素影响。容器运行时本身有并发下载限制比如 containerd 默认max_concurrent_downloads并不高多个镜像同时下载时会被排队。镜像层解压也会大量消耗节点磁盘 IO尤其是大模型镜像、oracle 类基础镜像解压十几层的时候 CPU 和 IO 都可能冲高。如果你的业务对 Pod 启动时间有要求那么“运行时才拉镜像”这个设计就是最大的不可控因素。1.2 哪些场景最值得做预热不是所有集群都需要做镜像预热。一个测试环境只有 2 个节点每次发版手动拉一下镜像也够用。但下面这些场景不做预热基本会出事。场景典型痛点预热的价值集群突发扩容 / Cluster Autoscaler 弹节点新节点调度业务 Pod 前镜像全在远端仓库节点加入前或加入后立即预热业务 Pod 来了镜像已就绪批量计算任务AI 训练、Spark、仿真成百上千个 Pod 同时调度每个 Pod 都可能拉同一批镜像把仓库压力分摊到节点初始化阶段避免启动尖峰节点池频繁替换 / 使用抢占式实例节点随时可能被销毁重建镜像缓存也随之消失用初始化脚本做到“新节点天生带镜像”离线内网 / 边缘机房拉取外网镜像困难仓库访问不稳定提前导入镜像 tar 包到节点业务完全不依赖外网私有镜像更新发版新版镜像生成后需要全集群尽快生效CI/CD 联动触发预热避免新版本首次访问全部回源一句话总结当“镜像就绪状态”成为业务调度的前置依赖时不做预热就是拿 Pod 启动时间赌节点网络和仓库稳定性。2. 方案总览按什么维度选技术路线2.1 三条路线节点初始化、集群内预热、镜像分发加速我看了很多团队的做法表面上一堆脚本和工具底层其实只有三条路线。第一条是节点初始化阶段预热。在节点创建、加入集群之前或者刚刚加入时通过 cloud-init、userdata、Terraform、Ansible 之类的工具先把镜像列表拉一遍。优点是镜像准备最早业务 Pod 调度上来的时候基本无需等待缺点是镜像列表写死在模板里镜像更新时需要滚动节点池或者额外机制补拉。第二条是集群内运行期预热。主要实现方式是 DaemonSet、Job、CronJob部署一个预热容器到指定节点容器里执行crictl pull或ctr images pull。优点是覆盖面广能覆盖已经运行中的节点镜像列表变更后可以在线触发重启缺点是它本身是个容器调度时机受 Kubernetes 自身状态影响节点如果还没 ReadyDaemonSet 不会调度上去。第三条是镜像分发架构层面的加速。包括镜像 tar 包离线导入、P2P 分发节点、stargz 懒加载等。严格来说有些不算“提前拉取”但可以起到“省掉回源拉取时间”的效果适合作为前两条路线的补充。这三种路线不是互斥的我最后落到生产环境的方案也是组合形态后面会详细说。2.2 先搞清楚运行时再动手在写任何预热脚本前第一件事是确认节点的容器运行时。现在大多数集群已经是 containerd但依然有 Docker、CRI-O 混存的可能。命令不对预热方案全是白做。如果你用的是 containerd 且 kubelet 通过 CRI 调用它那么节点上的命令行工具大概率是crictl或ctr。crictl是统一的 CRI 客户端适配 containerd、CRI-O 等运行时推荐优先使用。ctr是 containerd 的原生客户端使用它时必须指定 namespace否则会把镜像拉进默认 namespacekubelet 根本看不到这是最经典的一个坑。# 使用 crictl指定 containerd socket crictl --runtime-endpointunix:///var/run/containerd/containerd.sock pull docker.io/library/nginx:1.25 # 使用 ctr必须注意 namespace ctr -n k8s.io images pull docker.io/library/nginx:1.25如果你还在用 Docker 运行时那预热脚本就是docker pull。但建议最少在抽象层兼容一下因为现在很多发行版默认切到 containerd 了以前写死 docker 命令的脚本会直接报废。另外镜像地址建议写完整比如docker.io/library/nginx:1.25少用latest因为latest的 digest 会漂移预热拉到的版本和业务期望版本可能不一致。3. 节点初始化阶段预热让镜像跟着节点一起“就绪”3.1 cloud-init / userdata 中预拉镜像云厂商的节点组、自建裸机的 PXE 脚本基本都能在节点首次启动时执行一段自定义脚本。最简单粗暴的方式就是在这个启动脚本里把预热命令写进去。下面是一个适用于 containerd 的 userdata 片段核心逻辑是循环遍历镜像列表并用timeout限制单个镜像的拉取时长避免某个镜像卡死拖慢节点初始化。#!/bin/bash IMAGES( docker.io/library/nginx:1.25 docker.io/library/mysql:8.0 your-registry.example.com/model/train-base:2024.06 ) CRICTL$(command -v crictl) RUNTIME_ENDPOINTunix:///var/run/containerd/containerd.sock for img in ${IMAGES[]}; do timeout 300 $CRICTL --runtime-endpoint$RUNTIME_ENDPOINT pull $img \ echo [prewarm] ok $img \ || echo [prewarm] fail $img done这里有几个关键细节。timeout不是可选项大镜像仓库抖动时一个镜像能卡好几个小时没有超时会拖住后面的所有操作。如果 node userdata 是在容器运行时启动前执行的脚本里command -v crictl可能找不到命令所以顺序必须保证 containerd 和 crictl 已经安装完成。云厂商的 userdata 一般可以设置执行时机但为了更稳我习惯把它封装成 systemd oneshot service显式声明Aftercontainerd.service。[Unit] DescriptionPrewarm images on node boot Aftercontainerd.service Wantscontainerd.service [Service] Typeoneshot ExecStart/usr/local/bin/prewarm.sh TimeoutStartSec0 [Install] WantedBymulti-user.target节点初始化预热最大的优势是“冷启动即热镜像”特别是配合弹性伸缩新节点一上线镜像是现成的。但它也有明显局限镜像列表是固化在模板里的每次镜像更新要不就滚动节点池要不就得靠其他机制在后面补拉。3.2 用 Terraform / Ansible 编排节点池预热如果你不是直接用云厂商 userdata而是用 Terraform 管理基础设施、Ansible 做配置管理预热脚本也可以平滑嵌到编排流程里。Terraform 的典型操作是在remote-execprovisioner 里执行预热命令或者把预热脚本塞到节点的 cloud-init 模板变量中。Ansible 更灵活可以先拿到节点列表再用shell模块循环执行crictl pull并且用serial控制同时预热的节点数。这样做的好处是镜像列表可以放在 Git 仓库里通过配置管理工具分发到所有节点而不是散落在各家镜像模板里。需要特别提醒的是并发控制。用 Ansible 默认策略跑所有节点会同时开始拉镜像几十个节点同时打满带宽比业务高峰还恐怖。我一般会设置serial: 5让一批只跑五台每台内部再用xargs -P 3控制并发保证预热过程是稳定可控的而不是制造一场新的流量风暴。4. 集群内 DaemonSet 预热覆盖面最宽的运行期方案4.1 一个最朴素的 DaemonSet 实现节点初始化脚本解决的是“新节点”但线上集群的节点可能已经运行了好几个月当时模板里的镜像列表早就旧了。这时就需要一个能覆盖全集群所有节点的运行期预热方案最普适的就是 DaemonSet。核心思路很简单用一个高优先级 DaemonSet 在每个节点上跑一个循环容器容器里挂着 containerd 的 socket定时执行crictl pull。镜像列表放在 ConfigMap 里方便后续更新。apiVersion: v1 kind: ConfigMap metadata: name: prewarm-images namespace: kube-system data: images.txt: | docker.io/library/nginx:1.25 docker.io/library/mysql:8.0 your-registry.example.com/model/train-base:2024.06 --- apiVersion: apps/v1 kind: DaemonSet metadata: name: image-prewarmer namespace: kube-system spec: updateStrategy: type: RollingUpdate rollingUpdate: maxUnavailable: 50% selector: matchLabels: app: image-prewarmer template: metadata: labels: app: image-prewarmer spec: priorityClassName: system-node-critical hostNetwork: true tolerations: - operator: Exists containers: - name: prewarmer image: your-registry.example.com/prewarm-tool:1.0 imagePullPolicy: IfNotPresent env: - name: CRI_SOCKET value: /var/run/containerd/containerd.sock - name: IMAGE_LIST_FILE value: /etc/prewarm/images.txt volumeMounts: - name: cri-socket mountPath: /var/run/containerd - name: prewarm-images mountPath: /etc/prewarm command: - /bin/sh - -c - | set e while true; do grep -v ^# $IMAGE_LIST_FILE | \ xargs -P 3 -I {} timeout 600 crictl --runtime-endpoint$CRI_SOCKET pull {} || true sleep 3600 done volumes: - name: cri-socket hostPath: path: /var/run/containerd type: Directory - name: prewarm-images configMap: name: prewarm-images这里用的prewarm-tool镜像需要自带crictl和timeout、xargs等基础命令实际生产中我会在 Dockerfile 里从 cri-tools release 解压 crictl 进去不依赖宿主机的二进制。挂载方式上我选择挂载整个/var/run/containerd目录而不是单独挂 socket 文件因为 socket 在容器运行时重启时可能重建挂载目录更稳。如果安全合规要求高不需要给容器privileged: true普通 root 用户挂载 socket 就够了。这个 DaemonSet 的循环逻辑里我故意用了while true加sleep 3600而不是一次性脚本退出。好处是镜像列表更新后最晚一小时内新镜像就会被重新拉一遍。如果想立即生效直接执行 kubectl -n kube-system rollout restart daemonset image-prewarmerDaemonSet Pod 重建预热脚本重新执行全集群镜像刷新。这比手动逐个节点 SSH 不知道省多少事。4.2 控制节奏别把节点拉挂预热脚本里的并发控制非常关键。有些团队用简单的 for 循环串行拉取一个大镜像 10GB后面排队的镜像可能要等十几分钟效率太低。但直接全部并发containerd 的解压和写盘压力瞬间拉满节点 IO 延迟升高甚至影响节点上已经运行的业务 Pod。xargs -P 3是我实测下来比较折中的参数三路并发同时拉取既能利用带宽又不会把磁盘打满。如果你的环境网络带宽充裕、节点磁盘 IO 能力强可以适当调大到 4 或 5。如果节点是低配机型比如 2 核 4G 的轻量节点建议老老实实串行别为了省时间搞得节点不响应。另外还要注意 containerd 自身的max_concurrent_downloads配置脚本并发和运行时并发叠加可能导致实际下载请求超过预期最好在预热工具镜像里只控制自己的并发并且不要和业务高峰同时执行。4.3 一次性 Job 和 nodeSelector 变体DaemonSet 适合作为常驻方案但有些场景只需要“此刻给某些节点预热”比如某几个节点接到了重量级任务要临时拉一个大镜像。这时候用一次性 Job 更合适。思路是根据节点名生成带有nodeName的 JobPod 只调度到目标节点拉完镜像确认成功Job 退出。写法大致是这样apiVersion: batch/v1 kind: Job metadata: name: prewarm-node-01 namespace: kube-system spec: template: spec: nodeName: node-01 restartPolicy: Never containers: - name: prewarm image: your-registry.example.com/prewarm-tool:1.0 command: [/bin/sh, -c] args: - | crictl --runtime-endpoint$CRI_SOCKET pull your-registry.example.com/model/large:v2需要临时手动排查节点时也可以直接kubectl debug node/节点名进入节点主机命名空间在宿主机上执行 crictl pull效果等同于无侵入式的手工预热。这个方法适合应急不适合自动化。5. 把镜像“搬到”节点离线导入与 P2P 下载加速5.1 镜像导出导入离线环境的救命方案内网、隔离网、边缘机房这类环境节点没有稳定的外部镜像仓库连接再花哨的在线预热脚本也白搭。这种场景必须走镜像 tar 包离线导入思路就是把镜像从一台能接触仓库的机器上导出然后复制到目标节点上导入。Docker 和 containerd 的命令不完全一样。Docker 下是docker save和docker loadcontainerd 下是ctr images export和ctr images import。最关键的是 containerd 导入时 namespace 不能错。kubelet 用的是k8s.ionamespace你导入到默认 namespacekubelet 依然认为镜像不存在。这个坑我踩过一次当时排查了很久最后是ctr -n k8s.io images list才看到问题。建议的离线流程分四步。第一步在源机器上从仓库拉取或导出镜像用ctr -n k8s.io images export images.tar docker.io/library/nginx:1.25。第二步用 zstd 或者 gzip 压缩 tar 包减少传输体积几百个镜像不打散压缩会传死人。第三步用 scp、rsync 或者一些集群批量分发工具把 tar 包分发到各节点分发时同样要错峰否则内网交换机会先报警。第四步在每个节点执行ctr -n k8s.io images import images.tar导入完成后最好用crictl images验证一遍。镜像导入不是“复制文件”这么简单containerd 导入时会解包所有镜像层并重新建立 manifest节点 CPU 和磁盘 IO 都会明显升高。大批量导入一定要避开业务高峰期分批次、分节点组执行否则你会发现 Pod 启动是快了节点 IO 又成了新瓶颈。5.2 P2P 分发与懒加载缓解大集群同时回源问题如果节点很多、镜像很大即使你做了预拉取同一时刻几十个节点回源仓库依然很痛苦。这时候可以考虑在镜像分发层做文章。业界比较常见的思路是引入 P2P 分发节点比如 Dragonfly 这类方案。每个节点上部署一个 daemon第一个节点从镜像仓库拉取镜像分片其他节点不再直接回源仓库而是从相邻节点获取分片。这样无论你有 100 个节点还是 500 个节点仓库收到的原始流量只放大一倍左右不会随节点数线性增长。严格来说这是“同时拉取时互相协助”不是提前缓存但效果很接近“网络预热”——节点本地没有镜像却能从内网快速拉到不需要全部挤仓库。另一个方向是远程快照懒加载类似 stargz 格式。它不是在调度前把所有镜像层拉完而是让容器运行时按需拉取需要访问的数据块。第一次启动可能只拉几十兆业务跑起来后再慢慢补齐后续层。这其实是“不预热也能快速启动”的思路比预热更省节点磁盘但对于强 IO 型应用运行时按需拉取也有额外开销。P2P 和懒加载都不是万能的但它们可以和预热组合新节点继续用初始化脚本预热核心镜像突发的大镜像则靠 P2P 兜底避免个别节点预拉大镜像时卡住其他节点的初始化流程。6. 与集群扩缩容流程联动把预热做成自动化闭环6.1 Cluster Autoscaler 扩容时自动预热云环境的弹性节点池一般会在启动模板里指定 userdata我们可以利用这个机制让 Cluster Autoscaler 新弹出来的节点一开机就执行预热。原理和第三部分章节里的 cloud-init 一模一样但要注意和 Autoscaler 的配合姿势。比较推荐的做法是把预热命令写进节点组的启动模板节点一创建、容器运行时一就绪脚本就开始拉镜像整个拉取过程和 Kubernetes 控制面的调度过程并行。新节点加入集群调度器把业务 Pod 放上来时预热可能已经完成或接近完成。这里有一个细节不要让预热脚本阻塞 kubelet 启动和节点注册否则节点一直处于 NotReady 状态调度器也不会调度 Pod。预热目标是“尽量让业务少等”而不是“严格保证镜像先于业务拉完”。所以脚本里每个镜像都要设置超时并且允许失败继续。如果镜像列表在 Git 里管理建议在节点组模板里别再硬编码一串镜像名而是引用配置管理生成的文件或脚本。镜像列表更新时只需重新渲染节点组模板就能保证新节点使用新列表不用手工维护多处。6.2 触发全集群重新预热避免镜像过期预热不是一次性的镜像版本总在变。如果业务用latest或者经常发布新 tag节点本地的“热镜像”很快就会变成旧版本业务 Pod 调度上去还是要回源拉新镜像。所以必须有一个全集群重新预热的触发机制。我目前的标准操作是打完新镜像并推送到仓库后CI 流水线执行一条kubectl rollout restart daemonset image-prewarmer。daemonset 的 pod 被重建新的预热循环开始逐个节点把新版本镜像拉下来。配合maxUnavailable: 50%同一时间最多一半节点在重新预热既不会长时间没有预热覆盖也不会把网络直接打爆。执行完再等一个循环周期或者用一个脚本轮询每个节点的crictl images确认镜像已存在。这套流程把“预热”和“发版”绑定起来镜像推送后自动触发预热预热完成后再放业务流量滚动发布。整个集群的镜像更新效率比之前靠业务拉取推动高了不止一个量级。7. 常见问题、排查思路与避坑7.1 问题速查表现象原因处理思路crictl images能看到镜像但业务 Pod 仍然 ImagePullBackOff镜像 tag 或 digest 不一致预热拉错版本用完整镜像地址统一使用sha256digest 或明确 tagctr images pull成功但 kubelet 拉镜像失败镜像导入了错误 namespacekubelet 只认k8s.io使用ctr -n k8s.io images import预热拉私有仓库镜像全部失败没有为 CRI 配置私有仓库认证命令行 pull 不带 imagePullSecret在节点上配置/etc/containerd/config.toml或 registry authDaemonSet 不调度到新节点节点未 ReadyDaemonSet 调度依赖节点状态结合节点初始化预热不要单独依赖 DaemonSet 兜底新节点预热期间节点负载飙升业务抖动预热并发过高磁盘 IO 饱和降低xargs -P并发错峰执行预热完成后镜像又被删掉kubelet 镜像 GC 触发磁盘空间紧张提高imageGCHighThresholdPercent或定期补拉7.2 亲手踩过的一些坑第一个坑是 Docker socket 方案在 containerd 迁移后直接报废。早期很多节点用 Docker预热脚本就是docker pull挂载/var/run/docker.sock到容器里一切运行正常。后来集群迁移到 containerd这套 DaemonSet 还能跑但拉进来的镜像全部进了 Docker 自己的目录kubelet 从 containerd 侧根本看不到。从这里我总结出一个教训预热脚本要直接对 CRI 层编写使用crictl而不是任何特定运行时的 client这样将来运行时更换脚本不用大改。第二个坑是私有仓库认证。第一次给私有仓库预热发现 crictl pull 一直报认证失败而同样的镜像用 kubelet 调度业务 Pod 却能拉成功。原因是 kubelet 会读取 Pod 的imagePullSecrets但crictl命令行不会自动拿到这份凭据。解决方案是在节点上为 containerd 配置 registry 认证或者在预热脚本里显式登录仓库。如果你用 DaemonSet就需要挂载节点上的 containerd 配置目录确保命令行 pull 也走同样的认证。第三个坑是在ctr -n k8s.io images import时没注意平台架构。开发机导出的镜像通常是linux/amd64如果节点是 arm64 架构导入虽然不会报错但业务 Pod 创建时 kubelet 会发现平台不匹配依然会回源拉真正的 arm 镜像。导出前一定确认镜像 manifest 里包含当前节点所在的架构或者直接使用docker buildx构建多架构镜像。7.3 验证预热效果别靠“感觉”预热做完怎么判断到底有没有用最直接的是看业务 Pod 的启动耗时。记录同一份镜像在“未预热节点”和“已预热节点”上从 Pod 创建到容器 Ready 的时间差差异越大说明预热价值越大。操作上可以观察kubectl describe pod里的Events预热成功后Pod 通常不会出现大规模Pulling image的事件而是直接进入ContainerCreating并很快 Ready。更精细的验证是定期巡检节点镜像缓存。脚本可以写一个prewarm-check把节点上缺失的镜像列表集中输出缺失率超过阈值就触发告警。毕竟预热不是一劳永逸镜像 GC、容器运行时重启、节点磁盘清理都可能把缓存清掉只有持续校验才能保证“关键时刻镜像是热的”。8. 选型建议到底该用哪几个方案组合8.1 按环境快速选型不同团队的集群规模、基础设施、安全要求差异很大没必要一上来就把所有方案都堆上去。按我自己的经验可以按下面几个方向选。环境推荐组合理由云环境 ElasticNodeGroupuserdata 初始化预热 DaemonSet 定期刷新新节点天生带镜像老节点靠 DaemonSet 持续覆盖自建机房 内网仓库tar 包离线导入 DaemonSet 定时校验不依赖外网导入后可长期保持大量 GPU/大模型镜像节点节点初始化只拉基础镜像 P2P 分发大镜像大镜像 P2P 抢带宽不如用内网相互分片私有镜像发版频繁CI/CD 触发 DaemonSet restart镜像推送后自动全集群预热业务发布几乎无感8.2 四个设计原则第一预热必须幂等。同一个镜像拉一遍和拉十遍最终状态都一样。脚本不要因为镜像重复拉取而报错也不要因为镜像已存在就跳过后续逻辑。最好只是“确保目标镜像在本地存在”。第二预热必须限流。不管是并发数、带宽还是执行时间都要有上限。预热是后台动作不能影响业务。宁可预热慢一点也不要为了省五分钟把节点 IO 打到红线。第三预热必须可观测。每条预热记录都应该有日志失败的要能看到原因。镜像列表更新后要能在某个地方看到哪些节点已成功、哪些节点还在拉。没有可观测性的预热脚本出了问题就是黑盒比不预热还难受。第四预热必须考虑镜像回收。节点磁盘不是无限的镜像 GC 可能在磁盘水位高时清理掉预热的镜像。如果核心镜像很重要就要提高 GC 阈值或者用额外机制避开清理窗口。就我个人而言最终跑通的组合并不复杂云节点用 userdata 预热一个体积较大的模型基础镜像同时集群里挂着一个 DaemonSet 做全量镜像的周期校验和补拉每次发版时CI 触发一次 DaemonSet 滚动重启把新版本镜像推到所有节点。这套组合兼顾了新节点的冷启动、老节点的持续覆盖、以及发版时的高频更新运维成本也不高。如果你也在被镜像拉取拖慢业务我建议先从节点初始化 简单 DaemonSet 开始跑通后再逐步引入 P2P 和离线导入不要一上来就上重型方案否则你会在预热工具本身的问题上消耗大量精力。
