使用kaniko构建多阶段镜像时的缓存问题如何解决？

问题根因 #

该问题是kaniko v1.6.0及更早版本的已知跨阶段COPY缓存校验缺陷：kaniko处理跨阶段COPY操作时，仅校验上游阶段名称和目标路径，不会关联上游阶段的层内容哈希做匹配，因此源文件变更后仍会命中旧缓存，导致最终镜像包含旧文件。

解决方案 #

1. 升级kaniko版本（最优解）

kaniko从v1.7.0版本开始已修复该缓存逻辑缺陷，新版本会自动关联上游阶段的层哈希做缓存校验，无需调整现有构建参数和Dockerfile即可解决问题。你可以将使用的kaniko镜像直接替换为更高的稳定版，例如v1.9.2-debug。

2. 动态生成缓存路径（适合无法升级版本的场景）

通过CI脚本计算项目关键依赖文件的哈希值，动态生成缓存仓库的子路径，依赖变更时自动切换到新的缓存命名空间，依赖未变更时仍可复用原有缓存，调整后的执行命令如下：

# 按需替换为你项目中会触发问题的依赖文件，示例为PHP项目的package.json、package.lock
DEP_HASH=$(sha256sum package.json package.lock | sha256sum | head -c 12)
/kaniko/executor --cache --cache-repo $CI_REGISTRY_IMAGE/cache/$DEP_HASH

该方案无需修改Dockerfile，仅调整CI执行逻辑即可，对缓存命中率的影响极小。

3. 修改Dockerfile主动触发缓存校验

在不调整构建参数的前提下，可在Dockerfile中新增依赖哈希校验逻辑，让kaniko能感知到上游文件变更：

FROM busybox:1.33.1 AS builder
WORKDIR /root
COPY testfile testfile
# 新增步骤：计算源文件哈希存为单独文件
RUN sha256sum testfile > testfile.sha256

FROM busybox:1.33.1 AS release
WORKDIR /root
# 同时拷贝源文件和哈希文件，源文件变更时哈希文件同步变化，缓存自动失效
COPY --from=builder /root/testfile* ./
RUN cat /root/testfile

该方案适合CI流程不可修改、仅能调整Dockerfile的场景。

4. 缓存TTL兜底

可给kaniko添加--cache-ttl 24h参数（时长可根据项目发版频率调整），限制缓存的最长有效期，超过时间的旧缓存会自动被忽略，避免旧缓存被无限期复用，可作为以上方案的兜底补充。

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