在Actions Runner Controller中配置节点亲和性的实践指南

Actions Runner Controller是GitHub Actions自托管运行器的管理工具，它允许用户在Kubernetes集群中动态创建和管理运行器。本文将详细介绍如何为控制器Pod、监听器Pod和运行器Pod配置节点亲和性，实现工作负载的精细调度。

节点亲和性配置概述

节点亲和性是Kubernetes中控制Pod调度的重要机制，它允许用户指定Pod应该运行在哪些节点上。在Actions Runner Controller中，我们可以为三种不同类型的Pod分别配置节点亲和性：

1. 控制器Pod：负责管理整个运行器生命周期
2. 监听器Pod：监听GitHub Actions的工作流任务
3. 运行器Pod：实际执行工作流任务的临时Pod

具体配置方法

控制器Pod的亲和性配置

通过Helm values文件为控制器部署配置节点亲和性：

controller:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/arch
            operator: In
            values:
            - amd64

监听器Pod的亲和性配置

监听器Pod的配置需要修改RunnerScaleSet自定义资源：

template:
  spec:
    affinity:
      nodeAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:
          - matchExpressions:
            - key: node-group
              operator: In
              values:
              - actions-runners

运行器Pod的亲和性配置

运行器Pod的配置同样通过RunnerScaleSet资源实现：

template:
  spec:
    affinity:
      nodeAffinity:
        preferredDuringSchedulingIgnoredDuringExecution:
        - weight: 100
          preference:
            matchExpressions:
            - key: workload-type
              operator: In
              values:
              - ephemeral-runners

高级调度策略

除了基本的节点亲和性外，Actions Runner Controller还支持更高级的调度策略：

1. 污点和容忍：可以配合节点亲和性使用，实现更复杂的调度逻辑
2. 拓扑分布约束：控制Pod在集群中的分布方式
3. 资源请求和限制：确保Pod有足够的资源运行

容器化工作流任务

对于使用Kubernetes作为作业执行环境的场景，可以通过Hook扩展机制进一步定制运行环境。这种方式允许在作业容器启动前后执行自定义逻辑，实现更精细的资源控制和环境配置。

最佳实践建议

1. 为不同类型的Pod使用不同的节点组，实现资源隔离
2. 生产环境建议使用requiredDuringSchedulingIgnoredDuringExecution确保关键Pod的调度
3. 测试环境可以使用preferredDuringSchedulingIgnoredDuringExecution提高灵活性
4. 定期监控节点资源使用情况，及时调整亲和性规则

通过合理配置节点亲和性，可以显著提高Actions Runner Controller的稳定性和性能，确保自托管运行器高效可靠地执行GitHub Actions工作流。