在actions-runner-controller中自定义Docker-in-Docker容器配置

actions-runner-controller项目中的gha-runner-scale-set组件提供了Docker-in-Docker(dind)运行模式，允许在Kubernetes Pod中运行Docker守护进程。然而，默认配置中dockerd的参数是硬编码的，这给需要自定义Docker配置的用户带来了不便。

背景与需求

在实际生产环境中，用户经常需要调整Docker守护进程的配置，例如：

• 设置网络中转服务以访问外部容器镜像
• 配置受信任的私有镜像仓库
• 调整网络MTU值
• 添加镜像仓库镜像

默认情况下，gha-runner-scale-set的dind容器配置是硬编码在模板中的，用户无法通过简单的values.yaml修改来调整这些参数。

解决方案

目前有两种主要方法可以自定义dind容器的配置：

方法一：完全覆盖Pod模板

通过完全覆盖template配置，用户可以完全控制dind容器的所有参数。这种方法提供了最大的灵活性，但需要用户维护完整的PodSpec配置。

示例配置展示了如何：

1. 定义init容器来准备运行环境
2. 配置主runner容器
3. 自定义dind容器，包括安全上下文、资源限制等
4. 挂载ConfigMap作为daemon.json配置文件

方法二：使用daemon.json配置文件

更推荐的做法是通过挂载ConfigMap来提供/etc/docker/daemon.json文件，而不是直接修改dockerd参数。这种方式更符合Docker的标准配置实践，且更容易维护。

daemon.json配置示例展示了如何：

• 设置网络MTU值
• 配置默认网络选项
• 添加镜像仓库镜像

实施建议

1. 评估需求：确定是需要完全控制dind容器，还是仅需调整Docker配置
2. 创建ConfigMap：将Docker配置以daemon.json形式存储在ConfigMap中
3. 挂载配置：通过volumeMounts将ConfigMap挂载到dind容器的/etc/docker目录
4. 资源规划：根据工作负载需求合理设置dind容器的资源限制
5. 安全考虑：注意privileged模式的安全影响，在生产环境中应谨慎使用

最佳实践

• 优先使用daemon.json进行配置，而非命令行参数
• 为不同的环境（开发、测试、生产）维护不同的ConfigMap
• 考虑使用Kubernetes的NetworkPolicy限制dind容器的网络访问
• 监控dind容器的资源使用情况，及时调整资源限制

通过这种方式，用户可以在actions-runner-controller中灵活地配置dind容器，满足各种复杂环境下的Docker使用需求，同时保持配置的可维护性和安全性。