Actions Runner Controller中Helm卸载Runner Set时的资源删除问题分析

在Kubernetes环境中使用Actions Runner Controller管理GitHub Actions自托管运行器时，用户可能会遇到一个典型问题：通过Helm卸载runner scale set时，控制器无法完全删除所有相关资源，导致卸载过程卡在"等待依赖资源被删除"的状态。本文将深入分析这一问题的成因和解决方案。

问题现象

当用户尝试通过Helm卸载已部署的runner scale set时，控制器会持续报告正在等待依赖资源被删除。检查集群状态可以发现，部分Kubernetes资源仍然存在，特别是那些带有finalizer的资源对象。这些资源通常包括：

• RBAC相关对象（Roles、RoleBindings、ServiceAccounts）
• 密钥（Secrets）
• AutoscalingRunnerSet自定义资源本身

根本原因分析

这种现象的核心原因在于Kubernetes的finalizer机制与控制器删除逻辑的交互问题。在Actions Runner Controller的设计中：

1. 控制器会为关键资源添加finalizer，确保这些资源被删除前能执行必要的清理工作
2. Helm卸载过程会触发删除操作，但删除顺序可能不符合控制器的预期
3. 当AutoscalingRunnerSet资源被删除时，控制器需要先清理其管理的其他资源
4. 如果这些资源之间存在依赖关系且删除顺序不当，就会导致死锁状态

解决方案

对于遇到此问题的用户，可以采取以下解决方案：

1. 手动移除finalizer： 对于卡住的资源，可以通过kubectl patch命令手动移除finalizer：

   kubectl patch <resource-type> <resource-name> -p '{"metadata":{"finalizers":null}}' --type=merge
   

2. 调整资源删除顺序： 在使用GitOps工具（如ArgoCD或Flux）部署时，可以配置资源删除顺序：

   • 确保AutoscalingRunnerSet最先被删除
   • 其他依赖资源随后删除

3. 分步卸载流程：

   • 先手动删除AutoscalingRunnerSet资源
   • 等待控制器完成相关资源清理
   • 最后执行Helm卸载操作

最佳实践建议

为避免此类问题，建议采取以下预防措施：

1. 在测试环境验证卸载流程
2. 监控资源删除过程，及时发现卡住的资源
3. 考虑编写自定义清理脚本处理复杂场景
4. 保持Actions Runner Controller组件为最新版本，以获取最新的问题修复

技术原理深入

理解这一问题的关键在于Kubernetes的垃圾回收机制。当资源设置了finalizer时，API服务器会阻止该资源被立即删除，直到所有finalizer都被移除。在Actions Runner Controller的场景中：

• 控制器为资源添加finalizer以确保正确的清理顺序
• Helm的卸载操作可能触发并行删除请求
• 如果控制器尚未处理完所有依赖资源的清理，就会导致资源卡在terminating状态

这种设计虽然增加了系统的可靠性，但也带来了更复杂的删除流程，需要管理员理解并妥善处理。

通过理解这些底层机制，用户可以更好地诊断和解决类似问题，确保Actions Runner Controller的平稳运行和卸载。