GitLab Runner临时存储不足：PVC挂载路径与资源配置咨询

问题背景 #

GitLab CI流水线Pod因临时存储（Ephemeral Storage）不足失败，流水线日志显示Pod状态为Failed，Pod事件提示节点临时存储资源不足，build容器使用的存储超出请求值。通过kubectl exec查看GitLab Runner Pod的磁盘使用情况，发现包括/configmaps在内的三个目录使用率接近满值，但/configmaps已挂载为ConfigMap类型卷。

已知修复方案包括添加LimitRanges、在Helm Chart中配置临时存储的requests和limits、使用PVC扩容，当前受限于约束仅能采用PVC方案。

疑问 #

1. 给GitLab Runner Helm Chart添加PVC时，应挂载到哪个路径？df -h显示三个高使用率路径，但不确定哪个对应临时存储，且/configmaps已挂载为ConfigMap类型卷。
2. 若调整临时存储的requests和limits，Helm Chart中需覆盖哪些参数？

解决方案 #

问题1：PVC挂载路径选择 #

首先排除/configmaps——它是ConfigMap卷，本身不占用节点临时存储，使用率高大概率是因为该挂载点所在的根磁盘空间不足，而非ConfigMap自身占用。

需要定位真正的临时存储占用路径：

• GitLab Runner的build容器默认会把项目代码、构建临时产物等存放在/builds目录，这是临时存储的核心路径，也是最容易被占满的位置
• 若启用了本地缓存，Runner的/cache目录也会占用临时存储空间
• 可以通过du -sh /builds /cache命令对比两个目录的大小，确认主要占用者

挂载PVC时的路径选择：

• 如果是构建过程中的项目代码、临时构建产物占满空间，将PVC挂载到/builds
• 如果是依赖包等缓存占满空间，将PVC挂载到/cache
• 若两者都有明显占用，可分别创建PVC挂载到两个路径

问题2：调整临时存储requests/limits的Helm参数 #

在GitLab Runner的Helm Chart中，需要覆盖以下两类参数：

• Runner主容器：runner.resources.requests.ephemeral-storage 和 runner.resources.limits.ephemeral-storage
• Build容器（Kubernetes executor场景）：runners.kubernetes.podResources.requests.ephemeral-storage 和 runners.kubernetes.podResources.limits.ephemeral-storage

示例覆盖配置（values.yaml片段）：

runner:
  resources:
    requests:
      ephemeral-storage: "10Gi"
    limits:
      ephemeral-storage: "20Gi"
runners:
  kubernetes:
    podResources:
      requests:
        ephemeral-storage: "10Gi"
      limits:
        ephemeral-storage: "20Gi"

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