使用actions-runner-controller时GitHub Actions制品缓存实现咨询

不要尝试通过设置ephemeral: false关闭临时模式、用长生命周期持久化runner存缓存，官方不推荐该方案的核心原因是多任务复用同个runner极易出现工作区污染、依赖串扰等无明确排查路径的稳定性问题，生产环境踩坑概率极高。

1. 制品缓存能力的正确使用方式 #

结合临时runner的特性，可按实际场景选以下成熟方案，均符合官方推荐的实践标准：

• 最通用无侵入的方案是直接使用工作流自带的缓存逻辑。该逻辑和runner生命周期完全解耦：任务启动前会按配置的匹配规则拉取对应缓存到工作目录，任务执行完成后会将更新后的缓存回传，即使runner执行完任务立刻销毁也不影响缓存使用。使用时注意配置精准的缓存键，比如以对应语言依赖锁文件的哈希值作为缓存键核心标识，避免出现缓存不命中、拉取到错误版本缓存的问题。
• 大体积依赖、CI任务高频运行的场景，推荐在集群内部署独立的缓存服务：容器镜像类缓存可搭配本地镜像仓库，编程语言依赖（npm/pip/maven等）可搭配私有制品仓库，工作流中直接将依赖拉取地址指向集群内的缓存服务即可。该方案下缓存完全和runner生命周期解耦，走集群内网拉取速度远高于公网，缓存命中率也更高。
• 不想额外部署独立缓存服务的场景，可利用K8s节点本地存储实现缓存复用：给CI专用节点池挂载大容量本地磁盘，在RunnerSet/RunnerDeployment中配置hostPath类型卷，将各语言的默认缓存目录（比如~/.npm、~/.cache/pip、/root/.m2）映射到节点本地磁盘的指定路径，同时配置节点亲和性将同类型CI任务固定调度到该节点池即可。注意要配置定时清理策略删除过期缓存，避免节点磁盘被写满。

2. 架构下缓存内容的存储位置 #

缓存的实际存储位置完全取决于你选用的缓存方案，没有统一默认存储路径：

• 如果使用工作流自带的缓存能力：缓存不会存储在你的K8s集群内部，全部托管在GitHub侧的存储服务上。runner容器仅在任务运行期间临时拉取一份缓存到容器自身的可写层，任务结束pod删除后，这部分临时缓存会随容器一同被清理，集群内无残留。
• 如果使用集群内部署的独立缓存服务：缓存存储在缓存服务自身绑定的持久化存储卷上，底层对应集群提供的持久卷（云盘、NAS、本地磁盘均可），和runner的生命周期完全无关，无论runner创建销毁多少次，都不会影响这部分缓存数据。
• 如果使用节点hostPath挂载的本地缓存方案：缓存直接存储在对应K8s工作节点本地磁盘的指定挂载路径下，只要节点不被销毁、路径内容不被手动清理，缓存就会持续保留，可被调度到该节点的所有runner复用。
• 如果未配置任何上述缓存方案：任务执行过程中生成的所有缓存都仅存在于runner容器的临时可写层，ephemeral模式下任务完成后pod会被立刻删除，这部分缓存会随容器一同被彻底清除，不会在集群中留存。

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