在Actions Runner Controller中解决DinD模式Runner无法启动的问题
问题背景
在使用GitHub Actions Runner Controller(ARC)部署自托管Runner时,用户尝试配置Docker-in-Docker(DinD)模式运行器时遇到了问题。Runner虽然成功注册到GitHub,但在执行作业时会卡在等待状态,无法正常运行。
根本原因分析
通过日志检查发现,主要存在两个关键问题:
-
配置冲突:用户同时启用了
containerMode
和手动扩展的Pod规范,导致Kubernetes在创建Pod时检测到重复的卷名称和初始化容器名称。 -
网络配置问题:DinD容器需要特定的iptables配置才能正常工作,在某些平台上需要显式启用传统iptables支持。
解决方案
配置修正
正确的做法是只使用扩展的Pod规范,而不启用containerMode
。以下是推荐的配置示例:
template:
spec:
initContainers:
- name: init-dind-externals
image: ghcr.io/actions/actions-runner:latest
command: ['cp', '-r', '-v', '/home/runner/externals/.', '/home/runner/tmpDir/']
volumeMounts:
- name: dind-externals
mountPath: /home/runner/tmpDir
containers:
- name: runner
image: ghcr.io/actions/actions-runner:latest
command: ['/home/runner/run.sh']
env:
- name: DOCKER_HOST
value: unix:///run/docker/docker.sock
volumeMounts:
- name: work
mountPath: /home/runner/_work
- name: dind-sock
mountPath: /run/docker
readOnly: true
- name: dind
image: docker:dind
args:
- dockerd
- --host=unix:///run/docker/docker.sock
- --group=$(DOCKER_GROUP_GID)
env:
- name: DOCKER_GROUP_GID
value: '123'
- name: DOCKER_IPTABLES_LEGACY
value: '1'
resources:
requests:
memory: "500Mi"
cpu: "300m"
limits:
memory: "500Mi"
cpu: "300m"
securityContext:
privileged: true
volumeMounts:
- name: work
mountPath: /home/runner/_work
- name: dind-sock
mountPath: /run/docker
- name: dind-externals
mountPath: /home/runner/externals
volumes:
- name: work
emptyDir: {}
- name: dind-sock
emptyDir: {}
- name: dind-externals
emptyDir: {}
关键配置说明
-
Docker套接字路径:使用
/run/docker/docker.sock
而非传统的/var/run/docker.sock
路径 -
iptables传统模式:必须设置环境变量
DOCKER_IPTABLES_LEGACY=1
,这是DinD在某些平台上正常工作的关键 -
资源限制:为DinD容器设置适当的内存和CPU限制,防止资源耗尽
-
特权模式:DinD容器需要特权模式才能正常工作
最佳实践建议
-
避免配置重复:不要同时使用
containerMode
和手动扩展的Pod规范 -
资源监控:密切监控DinD容器的资源使用情况,根据实际负载调整限制
-
安全考虑:特权容器存在安全风险,应确保Runner部署在适当隔离的环境中
-
版本兼容性:定期检查Runner和DinD镜像的版本兼容性
总结
通过正确配置DinD模式的Runner,可以实现在Kubernetes集群中安全高效地运行需要Docker支持的GitHub Actions工作流。关键在于避免配置冲突,并确保网络设置正确,特别是iptables的兼容性设置。遵循上述建议,可以显著提高Runner的稳定性和可靠性。
- GGLM-4.5-AirGLM-4.5 系列模型是专为智能体设计的基础模型。GLM-4.5拥有 3550 亿总参数量,其中 320 亿活跃参数;GLM-4.5-Air采用更紧凑的设计,拥有 1060 亿总参数量,其中 120 亿活跃参数。GLM-4.5模型统一了推理、编码和智能体能力,以满足智能体应用的复杂需求Jinja00
- QQwen3-Coder-480B-A35B-InstructQwen3-Coder-480B-A35B-Instruct是当前最强大的开源代码模型之一,专为智能编程与工具调用设计。它拥有4800亿参数,支持256K长上下文,并可扩展至1M,特别擅长处理复杂代码库任务。模型在智能编码、浏览器操作等任务上表现卓越,性能媲美Claude Sonnet。支持多种平台工具调用,内置优化的函数调用格式,能高效完成代码生成与逻辑推理。推荐搭配温度0.7、top_p 0.8等参数使用,单次输出最高支持65536个token。无论是快速排序算法实现,还是数学工具链集成,都能流畅执行,为开发者提供接近人类水平的编程辅助体验。【此简介由AI生成】Python00
cherry-studio
🍒 Cherry Studio 是一款支持多个 LLM 提供商的桌面客户端TypeScript045note-gen
一款跨平台的 Markdown AI 笔记软件,致力于使用 AI 建立记录和写作的桥梁。TSX02chatgpt-on-wechat
基于大模型搭建的聊天机器人,同时支持 微信公众号、企业微信应用、飞书、钉钉 等接入,可选择GPT3.5/GPT-4o/GPT-o1/ DeepSeek/Claude/文心一言/讯飞星火/通义千问/ Gemini/GLM-4/Claude/Kimi/LinkAI,能处理文本、语音和图片,访问操作系统和互联网,支持基于自有知识库进行定制企业智能客服。Python021
热门内容推荐
最新内容推荐
项目优选









