使用 Kubernetes 执行器时，将 Gitlab Runner 守护进程的 pod 和作业的 pod 分配到 Kubernetes 中的两个单独的节点组

Question

我们正在使用 Gitlab Runner 和 Kubernetes 执行器，我们正在思考我认为目前不可能的事情。我们希望将 Gitlab Runner 守护进程的 pod 分配给实例类型为 X 的特定节点组的工作线程，并将作业的 pod 分配给不同节点组 Y 工作节点，因为这些节点通常比 Gitlab Runner 的 pod 需要更多的计算资源。

这样做是为了节省成本，因为 Gitlab 运行程序主守护进程将始终运行在节点上，然后我们希望它在便宜的实例上运行，然后需要更多计算能力的作业可以在不同的实例上运行具有不同的类型，将由 Cluster Autoscaler 启动，并在不存在作业时销毁。

我对此功能进行了调查，将 pod 分配到特定节点的可用方法是使用节点选择器或节点亲和性，但这两个配置部分中包含的规则适用于 Gitlab Runner 的所有 pod，主 Pod 和工作 Pod。该提案旨在使应用两种单独的配置成为可能，一种用于 Gitlab Runner 的 Pod，另一种用于作业的 Pod。

当前的现有配置由节点选择器和节点/pod 亲和力组成，但正如我提到的，这些配置全局适用于所有 pod，而不是我们在本例中想要的指定的 pod。

Gitlab Runner Kubernetes 执行器配置：https://docs.gitlab.com/runner/executors/kubernetes.html

Answer 1

这个问题解决了！经过进一步调查，我发现 Gitlab Runner 的 Helm 图表提供了 2 个nodeSelector功能，可以完全满足我的需求，其中一个用于代表 Gitlab Runner pod 的主 pod，另一个用于 Gitlab Runner 的 jobs pod。下面我展示了 Helm 图表的示例，其中我在每个nodeSelector域及其影响的 pod 旁边设置了该示例。

请注意，第一级nodeSelector是影响主 Gitlab Runner pod 的级别，第二级runners.kubernetes.node_selector是影响 Gitlab Runner 作业 pod 的级别。

gitlabUrl: https://gitlab.com/
...
nodeSelector:
  gitlab-runner-label-example: label-values-example-0
...

runnerRegistrationToken: ****
...
runners:
  config: 
    [[runners]]
        name = "gitlabRunnerExample"
        executor = "kubernetes"
        environment = ["FF_USE_LEGACY_KUBERNETES_EXECUTION_STRATEGY=true"]
        
        [runners.kubernetes]
            ...
        [runners.kubernetes.node_selector]
            "gitlab-runner-label-example" = "label-values-example-1"

        [runners.cache]
            ...
            [runners.cache.s3]
                ...
...