GitHub Actions Runner Controller 中 Pod 终止问题的深度解析

问题背景

在使用 GitHub Actions Runner Controller (ARC) 管理自托管运行器时，部分用户遇到了一个棘手的问题：某些运行器 Pod 在完成作业后未能正常终止，而是进入了"僵尸"状态持续运行。这种现象不仅消耗了集群资源，还可能导致后续作业调度问题。

问题现象

用户报告的主要表现为：

• 运行器 Pod 在作业完成后仍然保持运行状态
• 容器内部进程显示为 uninterruptible sleep (D 状态)
• 日志显示"Ephemeral runner container is still running"的重复信息
• 问题在长时间运行且输出较少的命令(如 terraform plan)时更为常见

根本原因分析

经过多方调查和 GCP 支持团队的确认，该问题的根源在于 Container-Optimized OS (COS) 特定版本中的一个内核级回归问题：

1. 影响范围：涉及 COS 版本介于 cos-113-18244-236-26 和 cos-113-18244-236-70 之间
2. 技术细节：问题与 io_uring 系统调用实现有关，这是一个 Linux 内核提供的异步 I/O 接口
3. 触发条件：当 Node.js 应用或其他使用 io_uring 的进程执行时，可能会陷入不可中断的睡眠状态

解决方案

长期解决方案

1. 升级 GKE 版本：

   • 推荐升级到 1.30.9-gke.1009000 (cos-113-18244-291-3) 或更高版本
   • 这些版本包含了针对 io_uring 问题的修复

2. 降级方案：

   • 临时降级到 1.30.6-gke.1596000 (COS 113-18244-236-26)
   • 可以创建一个新的节点池专门用于运行 GitHub Actions 运行器

临时解决方案

对于无法立即升级的环境，可以采用以下临时措施：

1. Node.js 环境变量：

   UV_USE_IO_URING=0
   

   这个变量会强制 Node.js 不使用 io_uring 接口，转而使用传统的 I/O 方式

2. 应用场景：

   • 在 composite action 中设置全局变量
   • 在 Jenkins 作业的环境变量中配置
   • 在 Dockerfile 或容器启动参数中添加

最佳实践建议

1. 版本管理：

   • 定期更新 GKE 集群到稳定版本
   • 关注 GCP 的发布说明，特别是涉及内核更新的内容

2. 监控措施：

   • 设置 Pod 生命周期监控，及时发现异常长运行的运行器
   • 配置资源使用告警，防止僵尸 Pod 消耗过多资源

3. 测试策略：

   • 在非生产环境验证新版本后再进行生产部署
   • 针对长时间运行作业进行专项测试

总结

GitHub Actions Runner Controller 的 Pod 终止问题本质上是一个底层基础设施问题，而非 ARC 本身的缺陷。通过理解问题的技术本质，运维团队可以采取针对性的解决措施。建议用户优先考虑升级到修复版本，同时在过渡期使用环境变量作为临时解决方案。

对于在其他云平台(如 AWS EKS)遇到类似问题的用户，虽然具体原因可能不同，但排查思路可以借鉴：检查内核版本、分析进程状态、考虑 I/O 子系统的影响因素等。