GitLab Runner Kubernetes执行器缓存失效问题求助

Hey，我来帮你捋捋这个问题——GitLab Runner的Kubernetes执行器缓存逻辑确实和Docker执行器不一样，尤其是你用的10.3.0这个相对老旧的版本，咱们一步步拆解排查：

一、先明确Kubernetes执行器的缓存核心逻辑 #

Kubernetes执行器完全不依赖cache_dir配置，它的缓存是通过分布式缓存后端（比如S3、GCS、GitLab内置对象存储等）实现的，而非本地磁盘卷。你看到日志里的“缓存拉取/创建”提示，可能只是流程走了空架子，实际缓存并没有真正被持久化或挂载到任务容器中。

二、具体排查与修复步骤 #

1. 检查Runner配置文件的缓存后端设置 #

打开你的config.toml，确认是否配置了完整的缓存后端块——这是Kubernetes执行器缓存生效的前提，没有的话日志里的缓存操作都是无效的。示例配置如下：

[[runners]]
  name = "K8s Runner"
  url = "https://你的GitLab实例地址/"
  token = "你的Runner令牌"
  executor = "kubernetes"
  [runners.kubernetes]
    # 你的K8s相关配置...
  [runners.cache]
    Type = "s3" # 可选gcs/azure，若用GitLab内置存储可对应配置
    Path = "cache"
    Shared = true # 允许分支间共享缓存，按需设置
    [runners.cache.s3]
      ServerAddress = "s3.amazonaws.com"
      AccessKey = "你的S3访问密钥"
      SecretKey = "你的S3密钥"
      BucketName = "缓存存储桶名称"
      Insecure = false

2. 验证.gitlab-ci.yml的缓存配置准确性 #

确保缓存路径与任务容器内的路径完全匹配，比如：

cache:
  key: ${CI_COMMIT_REF_SLUG} # 用分支名作为缓存key，确保同分支复用
  paths:
    - node_modules/ # 路径要和项目根目录下的node_modules位置一致

• 确认paths是相对于项目克隆根目录的路径，因为GitLab CI会把代码克隆到容器的项目根目录下；
• 检查key是否稳定——如果新提交还在同一个分支，缓存key不应变化，否则会触发新的缓存创建。

3. 检查任务容器的缓存挂载细节 #

在CI任务日志里仔细找以下信息：

• 是否有类似Mounting cache volume的日志条目？
• 挂载的路径是否和你指定的node_modules/完全对应？
  Kubernetes执行器会把缓存作为PVC或临时卷挂载到容器中，如果挂载路径错位，即使缓存存在，任务也无法读取到。

4. 针对10.3.0版本的特殊排查 #

这个2018年发布的老版本存在不少已知bug，重点检查：

• 权限问题：缓存卷的权限与任务容器运行用户不匹配，导致无法读取缓存。可以在before_script里加权限检查：

before_script:
  - ls -ld node_modules/ || echo "缓存目录不存在"
  - id # 查看当前运行用户

• 缓存后端兼容性：比如S3签名版本，10.3.0仅支持v2签名，如果你的存储用的是v4签名，会导致缓存无法写入/读取。

三、快速修复建议 #

1. 优先配置缓存后端：如果没有现成的S3/GCS，可以用GitLab内置的对象存储（若你的GitLab实例支持）；
2. 开启缓存共享：在.gitlab-ci.yml里添加cache:shared: true（需与Runner配置的Shared = true对应）；
3. 升级Runner版本：10.3.0的缓存bug在后续11.x及以上版本中大量修复，升级到稳定版能解决大部分兼容性问题。

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