GitLab CI构建失败：设备无剩余空间（GKE集群场景）

嘿，从你提供的流水线控制台输出里，核心错误一眼就能看出来：

time="2018-01-11T23:10:38.379477370Z" level=error msg="Not continuing with pull after error: failed to register layer: Error processing tar file(exit status 1): write /usr/share/terminfo/n/ncr7900iv: no space left on device"

这说明执行构建任务的GitLab Runner节点磁盘已经满了，拉取gliderlabs/herokuish镜像的时候写不进去文件，导致任务失败。和谷歌云Kubernetes集群的核心配置没关系，问题出在Runner的存储资源上。

1. 紧急清理（快速恢复） #

如果想先让流水线跑起来，直接清理Runner节点的Docker垃圾就行：

• 登录到那个docker-auto-scale的Runner节点，执行以下命令：

  # 一键清理停止的容器、无用镜像和缓存（强制删除，无需确认）
  docker system prune -af
  # 清理未使用的Docker卷
  docker volume prune -f
  

• 要是用的是谷歌云自动缩放的Runner，也可以直接删掉当前的Runner实例，自动缩放组会生成一个全新的实例，自带干净的磁盘空间。

2. 长期扩容（彻底解决） #

要避免以后再出现这个问题，得给Runner节点分配更大的磁盘：

• 去谷歌云Compute Engine里找到Runner用的实例模板，编辑模板把磁盘调大（比如从默认的10G改成30G以上）。
• 更新自动缩放组，让它使用修改后的模板，之后新生成的Runner节点就有足够的存储空间了。

3. 优化镜像拉取（可选） #

还可以优化镜像拉取流程，减少磁盘占用：

• 提前把gliderlabs/herokuish这类大镜像预加载到Runner节点里，或者用GitLab的镜像仓库缓存常用镜像，避免每次构建都重新拉取。
• 也可以在.gitlab-ci.yml的before_script阶段提前拉取需要的镜像，节省构建时间同时避免临时磁盘占满。

放心，你的谷歌云Kubernetes集群配置没遗漏什么，这次的问题完全是Runner节点的存储不够导致的，不用调整Kubernetes集群的核心设置~

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