在actions-runner-controller中配置Runner Pod资源请求的最佳实践

actions-runner-controller作为GitHub Actions自托管运行器的管理工具，其Helm chart提供了灵活的方式来配置Runner Pod的资源请求和限制。本文将详细介绍如何正确配置这些参数，确保Runner和dind容器都能获得足够的资源运行。

资源请求配置的重要性

在Kubernetes环境中，Pod中的每个容器都需要明确定义资源请求(request)和限制(limit)。资源请求告诉调度器容器运行所需的最小资源量，而限制则防止容器使用过多资源。如果没有正确配置，可能会导致以下问题：

1. Runner容器运行但dind(Docker in Docker)容器无法启动
2. 节点资源不足导致Pod被驱逐
3. 资源竞争导致构建过程变慢或失败

配置Runner Pod资源

actions-runner-controller的Helm chart提供了两种方式来配置Runner Pod：

1. 使用模板模式(Template Mode)

这是最灵活的配置方式，允许用户完全自定义PodSpec。在values.yaml中，可以通过template字段定义完整的Pod规范：

template:
  spec:
    containers:
    - name: runner
      resources:
        requests:
          cpu: "500m"
          memory: "1Gi"
        limits:
          cpu: "1"
          memory: "2Gi"

2. 使用容器模式(Container Mode)

容器模式提供了开箱即用的简化配置，适合基本使用场景。但对于需要精细控制资源的情况，建议切换到模板模式。

典型资源配置建议

对于同时运行Runner和dind容器的场景，建议配置如下资源：

1. Runner容器：

   • 请求：至少500m CPU和1Gi内存
   • 限制：1 CPU和2Gi内存

2. dind容器：

   • 请求：至少1 CPU和2Gi内存
   • 限制：2 CPU和4Gi内存

配置示例

完整的values.yaml配置示例：

template:
  spec:
    containers:
    - name: runner
      resources:
        requests:
          cpu: "500m"
          memory: "1Gi"
        limits:
          cpu: "1"
          memory: "2Gi"
    - name: dind
      resources:
        requests:
          cpu: "1"
          memory: "2Gi"
        limits:
          cpu: "2"
          memory: "4Gi"

监控与调整

配置资源后，应持续监控Pod的资源使用情况：

1. 使用kubectl top pods查看实际资源使用
2. 根据监控数据调整请求和限制
3. 特别注意构建高峰期的资源使用情况

总结

正确配置actions-runner-controller的资源请求和限制是确保GitHub Actions工作流稳定运行的关键。通过灵活使用模板模式，可以精细控制每个容器的资源分配，避免因资源不足导致的构建失败问题。建议根据实际工作负载特点调整资源配置，并建立持续监控机制。