低内存节点机型下GKE拉取Docker镜像速度过慢问题咨询

• 镜像拉取的默认流程：容器运行时拉取镜像分层时，会先将下载的压缩包、解压后的临时文件全部存在内核页缓存中，完成校验、合并后才会写入持久化磁盘，整个过程占用的内存和拉取的镜像分层大小正相关。
• 小内存节点的瓶颈：当累计拉取的镜像大小超过节点可用内存阈值后，内核会主动触发页缓存回收，需要先将未处理完的镜像临时数据刷入磁盘才能腾出内存空间处理新的分层，额外增加了大量随机IO开销，表现为拉取速度随部署进度推进持续衰减，完全匹配你测试中不同规格节点到对应容量后速度下降的现象。
• Image Streaming未生效的原因：GKE的Image Streaming功能依赖节点内存缓存流式加载的镜像分片，小内存节点无法承载足够的分片缓存，因此首次拉取时感知不到提速效果。

• 降低kubelet镜像并行拉取数：GKE默认kubelet允许同时拉取3个镜像，多镜像并发拉取会快速占满小内存节点的页缓存。可以在节点池配置中添加kubelet参数 --max-parallel-image-pulls=1，改为串行拉取，避免内存资源争抢。
• 调整内核页缓存回写策略：通过DaemonSet修改节点sysctl参数，将 vm.dirty_background_ratio 调整为5、vm.dirty_ratio 调整为10，让内核更早将缓存中的脏数据异步刷入磁盘，避免内存占满时触发同步阻塞式刷盘。
• 修改容器运行时临时缓存路径：将containerd（或Docker）的镜像临时处理目录从默认的tmpfs内存路径改为磁盘路径，虽然单分层处理速度略有下降，但完全避免了内存不足导致的换页开销，拉取速度会更稳定。
• 拆分大体积自定义镜像：将3.5G的大镜像按依赖、业务代码拆分为多个分层，不常变更的基础依赖层提前固化，部署时仅拉取变更的小体积业务层，大幅减少单次拉取的数据量。
• 配置基础镜像预拉取：用DaemonSet在节点初始化阶段提前拉取nginx、redis等固定依赖的公共镜像，分散部署时的拉取压力。

内容的提问来源于stack exchange，提问作者Abulafia