GitLab CI中Kaniko传镜像至ECR成功但层缓存上传失败

问题核心 #

镜像能正常推送至ECR，但缓存层上传时触发Post .../blobs/uploads/: EOF错误，根源集中在版本兼容、认证配置或仓库创建逻辑上。

可能原因 #

• Kaniko版本过旧：v1.9.1存在ECR缓存交互的兼容性bug，处理缓存层推送时易出现连接中断。
• 缓存仓库创建异常：Kaniko默认自动创建<目标仓库>/cache作为缓存仓库，但ECR仓库创建可能存在延迟，或权限生效不及时导致创建失败。
• 凭据存储配置无效：配置了credsStore: ecr-login但Kaniko镜像未携带docker-credential-ecr-login工具，缓存推送时无法完成认证。

解决方案 #

1. 升级Kaniko至最新稳定版 #

旧版本对ECR缓存支持不完善，升级后可修复多数兼容性问题：
修改.gitlab-ci.yml中的镜像版本：

image:
  name: gcr.io/kaniko-project/executor:v1.22.0-debug
  entrypoint: [""]

2. 手动创建ECR缓存仓库 #

提前在ECR控制台创建<你的主仓库名>/cache仓库（比如主仓库是acme-saleor-api，就创建acme-saleor-api/cache），规避自动创建的延迟或失败问题。

3. 替换认证方式，用AWS CLI生成令牌 #

放弃ecr-login凭据存储，直接用AWS CLI生成ECR认证信息写入Docker配置，确保缓存推送时认证有效：
更新script段：

script:
  - mkdir -p /kaniko/.docker
  - aws ecr get-login-password --region $AWS_DEFAULT_REGION | docker login --username AWS --password-stdin $ECR_REGISTRY
  - >-
    /kaniko/executor
    --cache=true
    --context $CI_PROJECT_DIR
    --dockerfile $CI_PROJECT_DIR/Dockerfile
    --destination $RUNNER_IMAGE
    --destination $RUNNER_IMAGE_COMMIT

Kaniko debug镜像自带AWS CLI，可直接执行上述命令。

4. 增加缓存重试与超时配置（针对网络问题） #

若EOF由网络不稳定导致，可添加缓存重试和超时参数：

/kaniko/executor
--cache=true
--cache-retry=3
--cache-timeout=300s
--context $CI_PROJECT_DIR
--dockerfile $CI_PROJECT_DIR/Dockerfile
--destination $RUNNER_IMAGE
--destination $RUNNER_IMAGE_COMMIT

验证顺序 #

优先尝试升级Kaniko版本，这是最直接的修复方式；若问题依旧，手动创建缓存仓库；最后替换认证配置。

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