Actions Runner Controller中Runner意外终止问题的分析与解决

问题现象

在使用Actions Runner Controller部署自托管Runner时，用户遇到了Runner在执行任务过程中意外终止的问题。具体表现为：当Runner正在执行Go测试任务时，突然收到SIGINT信号并退出，返回错误代码130，导致任务无法正常完成。

问题分析

通过对日志和事件记录的深入分析，可以确定问题根源在于Kubernetes节点资源不足导致的Pod驱逐。以下是关键发现：

1. 资源监控数据显示节点CPU使用率曾达到103%，内存使用率约60%，这表明CPU资源已经达到瓶颈。

2. Kubernetes事件日志中明确记录了Pod被驱逐的原因："The node was low on resource: ephemeral-storage"，说明临时存储空间不足是直接触发因素。

3. Runner日志显示Runner收到了SIGINT信号，这是典型的Pod被终止时的行为模式。

根本原因

经过排查，确定问题由以下因素共同导致：

1. 临时存储空间不足：Runner Pod中的dind(Docker in Docker)容器和Runner容器消耗了大量临时存储空间，而节点配置的临时存储容量不足。

2. CPU资源限制：虽然CPU使用率超过100%未直接导致问题，但表明资源分配已经达到极限，增加了系统不稳定性。

3. 资源请求未设置：Pod配置中未明确设置资源请求和限制，导致Kubernetes调度器无法正确评估资源需求。

解决方案

针对上述问题，推荐以下解决方案：

1. 增加节点存储容量

对于EKS集群，可以通过以下方式增加节点存储：

• 在Terraform配置中调整disk_size参数
• 直接修改节点组的启动模板，增加EBS卷大小
• 考虑使用更大实例类型，通常附带更多临时存储

2. 设置合理的资源请求和限制

在Runner的部署配置中明确设置资源请求和限制：

resources:
  requests:
    cpu: "2"
    memory: "4Gi"
    ephemeral-storage: "10Gi"
  limits:
    cpu: "4"
    memory: "8Gi"
    ephemeral-storage: "20Gi"

3. 优化Karpenter配置（如使用）

如果使用Karpenter管理节点，应确保配置了足够的系统预留资源：

kubeReserved:
  cpu: 1000m
  memory: 3000Mi

最佳实践建议

1. 监控与预警：设置Kubernetes资源使用监控，特别是临时存储的使用情况。

2. 容量规划：根据工作负载特点预先评估资源需求，Runner执行编译、测试等任务通常需要较多CPU和存储资源。

3. 渐进式调整：从小规模测试开始，逐步增加负载，观察资源使用模式。

4. 日志收集：配置集中式日志收集，便于问题发生时快速定位原因。

总结

在Kubernetes环境中运行GitHub Actions Runner时，资源管理是关键。通过合理配置资源请求和限制、确保节点有足够容量，并建立有效的监控机制，可以显著提高Runner的稳定性和任务成功率。本例中的问题虽然表现为Runner意外终止，但根本原因在于底层基础设施资源不足，这提醒我们在使用类似Actions Runner Controller这样的工具时，需要全面考虑整个技术栈的配置和容量规划。