GitLab托管Kubernetes集群中Runner缓存配置方法咨询

我来帮你搞定这个缓存配置的问题！因为你是通过GitLab面板安装的Kubernetes Runner，本质上它是用Helm Chart部署的（从Pod描述里的chart=gitlab-runner-0.21.0和heritage=Tiller能看出来），直接修改Pod或ConfigMap的话会被Helm覆盖，所以咱们得通过Helm配置来添加外部Blob存储的缓存支持，具体步骤如下：

1. 导出当前Runner的Helm配置 #

首先把当前Runner的Helm配置导出到本地文件，方便我们修改：

helm get values runner -n gitlab-managed-apps > runner-values.yaml

2. 编辑配置文件，添加缓存参数 #

打开runner-values.yaml，在文件中添加对应Blob存储的缓存配置。下面是几个主流存储的示例：

示例1：AWS S3（兼容S3的存储如MinIO也适用） #

runners:
  cache:
    Type: "s3"
    Path: "gitlab-runner-cache"  # 缓存在桶里的存放路径
    Shared: true  # 开启多Runner共享缓存，非常重要
    S3:
      Server: "s3.amazonaws.com"  # 如果是MinIO，填你的MinIO地址
      Bucket: "your-cache-bucket-name"  # 替换成你创建好的桶名
      AccessKey: "your-access-key"  # 替换成你的访问密钥
      SecretKey: "your-secret-key"  # 替换成你的秘密密钥
      Insecure: false  # 如果是HTTP的MinIO，设为true
      BucketLocation: "eu-west-1"  # 替换成你的桶所在区域

示例2：Google Cloud Storage（GCS） #

首先需要把GCS的服务账号JSON文件创建成Kubernetes Secret：

kubectl create secret generic gcs-service-account-secret \
  --from-file=gcs-service-account.json=./your-service-account-file.json \
  -n gitlab-managed-apps

然后在runner-values.yaml里添加：

runners:
  cache:
    Type: "gcs"
    Path: "gitlab-runner-cache"
    Shared: true
    GCS:
      BucketName: "your-gcs-bucket-name"  # 替换成你的GCS桶名
      CredentialsFile: "/secrets/gcs-service-account.json"
  # 挂载刚才创建的Secret到Runner Pod里
  secrets:
    - name: "gcs-service-account-secret"
      mountPath: "/secrets"

示例3：Azure Blob Storage #

runners:
  cache:
    Type: "azure"
    Path: "gitlab-runner-cache"
    Shared: true
    Azure:
      AccountName: "your-azure-storage-account"
      AccountKey: "your-azure-storage-key"
      ContainerName: "your-cache-container"

3. 应用更新后的配置 #

把修改好的配置应用到Helm Release，Runner会自动重启并加载新的缓存配置：

helm upgrade runner gitlab/gitlab-runner -n gitlab-managed-apps -f runner-values.yaml

最后一步：在CI配置里启用缓存 #

修改你的.gitlab-ci.yml，添加缓存规则，比如：

cache:
  key: "$CI_PROJECT_ID"  # 用项目ID作为缓存键，确保每个项目独立缓存
  paths:
    - node_modules/  # 替换成你需要缓存的目录

几个关键注意点： #

• 确保你创建的Blob存储桶/容器已经存在，并且Runner的权限足够读写（比如S3的IAM权限、GCS的服务账号权限）
• Shared: true 一定要开启，否则每个Runner Pod会有自己的缓存，达不到共享的效果
• 如果是GitLab.com托管的Runner，也可以考虑使用GitLab自带的对象存储，但外部存储的配置逻辑是一样的

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