使用 Actions Runner Controller 部署 Runner 规模集 - GitHub 文档

法律声明

关于运行器规模集

运行器规模集是一组同构运行器，可以从 GitHub Actions 分配作业。运行器规模集拥有的活动运行器数量可以通过自动扩展运行器解决方案（例如 Actions Runner Controller (ARC)）来控制。

您可以使用运行器组来管理运行器规模集。与自托管运行器类似，您可以将运行器规模集添加到现有的运行器组中。但是，运行器规模集一次只能属于一个运行器组，并且只能分配一个标签。有关运行器组的更多信息，请参阅“使用组管理对自托管运行器的访问”。

要将作业分配给运行器规模集，您必须将工作流配置为引用运行器规模集的名称。有关更多信息，请参阅“在工作流中使用 Actions Runner Controller 运行器”。

部署运行器规模集

要部署运行器规模集，您必须先启动并运行 ARC。有关更多信息，请参阅“Actions Runner Controller 快速入门”。

您可以使用 ARC 的 Helm 图表或部署必要的清单来部署运行器规模集。使用 ARC 的 Helm 图表是首选方法，尤其是在您之前没有使用 ARC 的经验时。

注意

作为安全最佳实践，请在与包含您的操作符 Pod 的命名空间不同的命名空间中创建您的运行器 Pod。
作为安全最佳实践，请创建 Kubernetes 密钥并传递密钥引用。通过 CLI 以纯文本形式传递密钥可能会带来安全风险。
我们建议在隔离环境中运行生产工作负载。GitHub Actions 工作流旨在运行任意代码，并且在生产工作负载中使用共享 Kubernetes 集群可能会带来安全风险。
确保您已实现一种方法来收集和保留来自控制器、侦听器和临时运行器的日志。

要配置您的运行器规模集，请在您的终端中运行以下命令，使用来自您的 ARC 配置的值。

运行命令时，请牢记以下事项。

仔细更新INSTALLATION_NAME值。您将在工作流中将安装名称用作runs-on的值。
将NAMESPACE值更新为您希望创建运行器 Pod 的位置。
将GITHUB_CONFIG_URL值设置为您的存储库、组织或企业的 URL。这是运行器将所属的实体。

此示例命令安装 Helm 图表的最新版本。要安装特定版本，您可以传递--version参数以及要安装的图表的版本。您可以在actions-runner-controller存储库中找到版本列表。

Bash

INSTALLATION_NAME="arc-runner-set"
NAMESPACE="arc-runners"
GITHUB_CONFIG_URL="https://github.com/<your_enterprise/org/repo>"
GITHUB_PAT="<PAT>"
helm install "${INSTALLATION_NAME}" \
    --namespace "${NAMESPACE}" \
    --create-namespace \
    --set githubConfigUrl="${GITHUB_CONFIG_URL}" \
    --set githubConfigSecret.github_token="${GITHUB_PAT}" \
    oci://ghcr.io/actions/actions-runner-controller-charts/gha-runner-scale-set

INSTALLATION_NAME="arc-runner-set"
NAMESPACE="arc-runners"
GITHUB_CONFIG_URL="https://github.com/<your_enterprise/org/repo>"
GITHUB_PAT="<PAT>"
helm install "${INSTALLATION_NAME}" \
    --namespace "${NAMESPACE}" \
    --create-namespace \
    --set githubConfigUrl="${GITHUB_CONFIG_URL}" \
    --set githubConfigSecret.github_token="${GITHUB_PAT}" \
    oci://ghcr.io/actions/actions-runner-controller-charts/gha-runner-scale-set

有关其他 Helm 配置选项，请参阅 ARC 存储库中的values.yaml。

要检查您的安装，请在您的终端中运行以下命令。

Bash

helm list -A

helm list -A

您应该会看到类似于以下内容的输出。

NAME            NAMESPACE       REVISION        UPDATED                                 STATUS          CHART                                       APP VERSION
arc             arc-systems     1               2023-04-12 11:45:59.152090536 +0000 UTC deployed        gha-runner-scale-set-controller-0.4.0       0.4.0
arc-runner-set  arc-systems     1               2023-04-12 11:46:13.451041354 +0000 UTC deployed        gha-runner-scale-set-0.4.0                  0.4.0

要检查管理器 Pod，请在您的终端中运行以下命令。

Bash

kubectl get pods -n arc-systems

kubectl get pods -n arc-systems

如果安装成功，Pod 将显示Running状态。

NAME                                                   READY   STATUS    RESTARTS   AGE
arc-gha-runner-scale-set-controller-594cdc976f-m7cjs   1/1     Running   0          64s
arc-runner-set-754b578d-listener                       1/1     Running   0          12s

如果您的安装未成功，请参阅“排查 Actions Runner Controller 错误”以获取故障排除信息。

使用高级配置选项

ARC 提供了一些高级配置选项。

配置运行器规模集名称

注意

运行器规模集名称在其所属的运行器组中是唯一的。如果要部署具有相同名称的多个运行器规模集，则它们必须属于不同的运行器组。

要配置运行器规模集名称，您可以定义INSTALLATION_NAME或在您复制的values.yaml文件中设置runnerScaleSetName的值。

## The name of the runner scale set to create, which defaults to the Helm release name
runnerScaleSetName: "my-runners"

确保在您的helm install命令中传递values.yaml文件。有关更多详细信息，请参阅Helm 安装文档。

选择运行器目标

运行器规模集可以在存储库、组织或企业级别部署。

要将运行器规模集部署到特定级别，请在您复制的values.yaml文件中将githubConfigUrl的值设置为您的存储库、组织或企业的 URL。

以下示例显示了如何配置 ARC 以将运行器添加到octo-org/octo-repo。

githubConfigUrl: "https://github.com/octo-ent/octo-org/octo-repo"

有关其他 Helm 配置选项，请参阅 ARC 存储库中的values.yaml。

使用 GitHub 应用进行身份验证

如果您未使用企业级运行器，则可以使用 GitHub 应用对 GitHub API 进行身份验证。有关更多信息，请参阅“对 GitHub API 进行身份验证”。

注意

鉴于在磁盘上的文件中以纯文本形式公开您的私钥存在安全风险，我们建议创建 Kubernetes 密钥并传递引用。

您可以创建 Kubernetes 密钥，或在您复制的values.yaml文件中指定值。

选项 1：创建 Kubernetes 密钥（推荐）

创建 GitHub 应用后，创建 Kubernetes 密钥并将引用传递到您复制的values.yaml文件中的该密钥。

注意

在安装gha-runner-scale-set图表的同一命名空间中创建密钥。在此示例中，命名空间为arc-runners，以匹配快速入门文档。有关更多信息，请参阅“Actions Runner Controller 快速入门”。

kubectl create secret generic pre-defined-secret \
  --namespace=arc-runners \
  --from-literal=github_app_id=123456 \
  --from-literal=github_app_installation_id=654321 \
  --from-literal=github_app_private_key='-----BEGIN RSA PRIVATE KEY-----********'

在您复制的values.yaml中，将密钥名称作为引用传递。

githubConfigSecret: pre-defined-secret

选项 2：在您的`values.yaml`文件中指定值

或者，您可以在您复制的values.yaml文件中指定app_id、installation_id和private_key的值。

## githubConfigSecret is the Kubernetes secret to use when authenticating with GitHub API.
## You can choose to use a GitHub App or a personal access token (classic)
githubConfigSecret:
  ## GitHub Apps Configuration
  ## IDs must be strings, use quotes
  github_app_id: "123456"
  github_app_installation_id: "654321"
  github_app_private_key: |
    -----BEGIN RSA PRIVATE KEY-----
    ...
    HkVN9...
    ...
    -----END RSA PRIVATE KEY-----

有关其他 Helm 配置选项，请参阅 ARC 存储库中的values.yaml。

使用运行器组管理访问权限

您可以使用运行器组来控制哪些组织或存储库可以访问您的运行器规模集。有关运行器组的更多信息，请参阅“使用组管理对自托管运行器的访问”。

要将运行器规模集添加到运行器组，您必须已创建运行器组。然后在您复制的values.yaml文件中设置runnerGroup属性。以下示例将运行器规模集添加到 Octo-Group 运行器组。

runnerGroup: "Octo-Group"

有关其他 Helm 配置选项，请参阅 ARC 存储库中的values.yaml。

配置出站代理

要强制控制器和运行器的 HTTP 流量通过您的出站代理，请在您的 Helm 图表中设置以下属性。

proxy:
  http:
    url: http://proxy.com:1234
    credentialSecretRef: proxy-auth # a Kubernetes secret with `username` and `password` keys
  https:
    url: http://proxy.com:1234
    credentialSecretRef: proxy-auth # a Kubernetes secret with `username` and `password` keys
  noProxy:
    - example.com
    - example.org

ARC 支持使用匿名或已认证的代理。如果您使用已认证的代理，则需要将credentialSecretRef值设置为引用 Kubernetes 密钥。您可以使用以下命令创建包含代理凭据的密钥。

注意

Bash

  kubectl create secret generic proxy-auth \
    --namespace=arc-runners \
    --from-literal=username=proxyUsername \
    --from-literal=password=proxyPassword \

  kubectl create secret generic proxy-auth \
    --namespace=arc-runners \
    --from-literal=username=proxyUsername \
    --from-literal=password=proxyPassword \

有关其他 Helm 配置选项，请参阅 ARC 存储库中的values.yaml。

设置运行器的最大和最小数量

maxRunners和minRunners属性为您提供了自定义 ARC 设置的一系列选项。

注意

ARC 不支持计划的最大和最小配置。您可以使用 cronjob 或任何其他计划解决方案来按计划更新配置。

示例：运行器数量不受限制

如果注释掉maxRunners和minRunners属性，ARC 将扩展到分配给运行器规模集的作业数量，如果没有任何活动作业，则将缩减到 0。

## maxRunners is the max number of runners the auto scaling runner set will scale up to.
# maxRunners: 0

## minRunners is the min number of idle runners. The target number of runners created will be
## calculated as a sum of minRunners and the number of jobs assigned to the scale set.
# minRunners: 0

示例：运行器的最小数量

您可以将minRunners属性设置为任意数字，ARC 将确保始终有指定的运行器数量处于活动状态并可随时处理分配给运行器规模集的作业。

## maxRunners is the max number of runners the auto scaling runner set will scale up to.
# maxRunners: 0

## minRunners is the min number of idle runners. The target number of runners created will be
## calculated as a sum of minRunners and the number of jobs assigned to the scale set.
minRunners: 20

示例：设置运行器的最大和最小数量

在此配置中，Actions Runner Controller 将扩展到最多30个运行器，并在作业完成后缩减到20个运行器。

注意

minRunners的值永远不能超过maxRunners的值，除非maxRunners被注释掉。

## maxRunners is the max number of runners the auto scaling runner set will scale up to.
maxRunners: 30

## minRunners is the min number of idle runners. The target number of runners created will be
## calculated as a sum of minRunners and the number of jobs assigned to the scale set.
minRunners: 20

示例：作业队列清空

在某些情况下，您可能希望清空作业队列以解决问题或对您的集群执行维护。如果您将这两个属性都设置为0，则当有新的作业可用并分配时，Actions Runner Controller 不会创建新的运行器 Pod。

## maxRunners is the max number of runners the auto scaling runner set will scale up to.
maxRunners: 0

## minRunners is the min number of idle runners. The target number of runners created will be
## calculated as a sum of minRunners and the number of jobs assigned to the scale set.
minRunners: 0

自定义 TLS 证书

注意

如果您使用的是不基于Debian发行版的自定义运行器映像，则以下说明将不起作用。

某些环境需要由自定义证书颁发机构 (CA) 签名的 TLS 证书。由于自定义证书颁发机构证书未与控制器或运行器容器捆绑在一起，因此您必须将它们注入到各自的信任存储中。

githubServerTLS:
  certificateFrom:
    configMapKeyRef:
      name: config-map-name
      key: ca.crt
  runnerMountPath: /usr/local/share/ca-certificates/

执行此操作时，请确保您使用的是隐私增强邮件 (PEM) 格式，并且证书的扩展名为.crt。其他任何内容都将被忽略。

控制器执行以下操作。

创建一个包含certificateFrom中指定的证书的github-server-tls-cert卷。
将该卷挂载到路径runnerMountPath/<certificate name>上。
将NODE_EXTRA_CA_CERTS环境变量设置为相同的路径。
将RUNNER_UPDATE_CA_CERTS环境变量设置为1（从2.303.0版本开始，这将指示运行器重新加载主机上的证书）。

ARC 观察在运行器 Pod 模板中设置的值，并且不会覆盖它们。

有关其他 Helm 配置选项，请参阅 ARC 存储库中的values.yaml。

使用私有容器注册表

警告

此 Actions Runner Controller 自定义选项可能超出 GitHub 支持能够协助的范围，并且如果配置不正确可能会导致意外行为。

有关 GitHub 支持可以协助哪些内容的更多信息，请参阅Actions Runner Controller 支持信息。

要使用私有容器注册表，您可以将控制器镜像和运行器镜像复制到您的私有容器注册表。然后配置指向这些镜像的链接，并设置imagePullPolicy和imagePullSecrets值。

配置运行器镜像

您可以更新您自己的values.yaml文件副本，并按如下所示设置template.spec属性。

template:
  spec:
    containers:
      - name: runner
        image: "custom-registry.io/actions-runner:latest"
        imagePullPolicy: Always
        command: ["/home/runner/run.sh"]
    imagePullSecrets:
      - name: <registry-secret-name>

有关其他 Helm 配置选项，请参阅 ARC 存储库中的values.yaml。

更新运行器 Pod 的 Pod 规范

警告

此 Actions Runner Controller 自定义选项可能超出 GitHub 支持能够协助的范围，并且如果配置不正确可能会导致意外行为。

有关 GitHub 支持可以协助哪些内容的更多信息，请参阅Actions Runner Controller 支持信息。

您可以完全自定义运行器 Pod 的 PodSpec，控制器将应用您指定的配置。以下是 Pod 规范示例。

template:
  spec:
    containers:
      - name: runner
        image: ghcr.io/actions/actions-runner:latest
        command: ["/home/runner/run.sh"]
        resources:
          limits:
            cpu: 500m
            memory: 512Mi
        securityContext:
          readOnlyRootFilesystem: true
          allowPrivilegeEscalation: false
          capabilities:
            add:
              - NET_ADMIN

有关其他 Helm 配置选项，请参阅 ARC 存储库中的values.yaml。

更新侦听器 Pod 的 Pod 规范

警告

此 Actions Runner Controller 自定义选项可能超出 GitHub 支持能够协助的范围，并且如果配置不正确可能会导致意外行为。

有关 GitHub 支持可以协助哪些内容的更多信息，请参阅Actions Runner Controller 支持信息。

您可以自定义侦听器 Pod 的 PodSpec，控制器将应用您指定的配置。以下是 Pod 规范示例。

重要的是不要更改侦听器容器的listenerTemplate.spec.containers.name值。否则，您指定的配置将应用于新的 side-car 容器。

listenerTemplate:
  spec:
    containers:
    # If you change the name of the container, the configuration will not be applied to the listener,
    # and it will be treated as a side-car container.
    - name: listener
      securityContext:
        runAsUser: 1000
      resources:
        limits:
          cpu: "1"
          memory: 1Gi
        requests:
          cpu: "1"
          memory: 1Gi

有关其他 Helm 配置选项，请参阅 ARC 存储库中的values.yaml。

为容器使用 Docker-in-Docker 或 Kubernetes 模式

警告

此 Actions Runner Controller 自定义选项可能超出 GitHub 支持能够协助的范围，并且如果配置不正确可能会导致意外行为。

有关 GitHub 支持可以协助哪些内容的更多信息，请参阅Actions Runner Controller 支持信息。

如果您使用容器作业和服务或容器操作，则必须将containerMode值设置为dind或kubernetes。

有关容器作业和服务的更多信息，请参阅“在容器中运行作业”。
有关容器操作的更多信息，请参阅“创建 Docker 容器操作”。

使用 Docker-in-Docker 模式

注意

Docker-in-Docker 容器需要特权模式。有关更多信息，请参阅 Kubernetes 文档中的配置 Pod 或容器的安全上下文。

默认情况下，dind容器使用docker:dind镜像，该镜像以 root 用户身份运行 Docker 守护程序。只要您了解已知限制并以--privileged模式运行 Pod，就可以将此镜像替换为docker:dind-rootless。要了解如何自定义 Docker-in-Docker 配置，请参阅“自定义容器模式”。

Docker-in-Docker 模式是一种允许您在 Docker 容器内运行 Docker 的配置。在此配置中，对于创建的每个运行器 Pod，ARC 创建以下容器。

一个init容器
一个runner容器
一个dind容器

要启用 Docker-in-Docker 模式，请将containerMode.type设置为dind，如下所示。

containerMode:
  type: "dind"

template.spec将更新为以下默认配置。

template:
  spec:
    initContainers:
      - name: init-dind-externals
        image: ghcr.io/actions/actions-runner:latest
        command:
          ["cp", "-r", "/home/runner/externals/.", "/home/runner/tmpDir/"]
        volumeMounts:
          - name: dind-externals
            mountPath: /home/runner/tmpDir
    containers:
      - name: runner
        image: ghcr.io/actions/actions-runner:latest
        command: ["/home/runner/run.sh"]
        env:
          - name: DOCKER_HOST
            value: unix:///var/run/docker.sock
        volumeMounts:
          - name: work
            mountPath: /home/runner/_work
          - name: dind-sock
            mountPath: /var/run
      - name: dind
        image: docker:dind
        args:
          - dockerd
          - --host=unix:///var/run/docker.sock
          - --group=$(DOCKER_GROUP_GID)
        env:
          - name: DOCKER_GROUP_GID
            value: "123"
        securityContext:
          privileged: true
        volumeMounts:
          - name: work
            mountPath: /home/runner/_work
          - name: dind-sock
            mountPath: /var/run
          - name: dind-externals
            mountPath: /home/runner/externals
    volumes:
      - name: work
        emptyDir: {}
      - name: dind-sock
        emptyDir: {}
      - name: dind-externals
        emptyDir: {}

template.spec中的值会自动注入，无法覆盖。如果要自定义此设置，则必须取消设置containerMode.type，然后复制此配置并将其直接应用于您自己的values.yaml文件副本。

有关其他 Helm 配置选项，请参阅 ARC 存储库中的values.yaml。

使用 Kubernetes 模式

在 Kubernetes 模式下，ARC 使用运行器容器钩子在同一命名空间中创建一个新的 Pod 来运行服务、容器作业或操作。

先决条件

Kubernetes 模式依赖于持久卷在运行器 Pod 和容器作业 Pod 之间共享作业详细信息。有关更多信息，请参阅 Kubernetes 文档中的持久卷部分。

要使用 Kubernetes 模式，您必须执行以下操作。

创建可供运行器 Pod 声明的持久卷。
使用一种解决方案按需自动预配持久卷。

为了测试，您可以使用OpenEBS之类的解决方案。

配置 Kubernetes 模式

要启用 Kubernetes 模式，请在您的values.yaml文件中将containerMode.type设置为kubernetes。

containerMode:
  type: "kubernetes"
  kubernetesModeWorkVolumeClaim:
    accessModes: ["ReadWriteOnce"]
    storageClassName: "dynamic-blob-storage"
    resources:
      requests:
        storage: 1Gi

有关其他 Helm 配置选项，请参阅 ARC 存储库中的values.yaml。

注意

启用 Kubernetes 模式后，未配置容器作业的工作流将失败并出现类似以下错误

Jobs without a job container are forbidden on this runner, please add a 'container:' to your job or contact your self-hosted runner administrator.

要允许没有作业容器的作业运行，请在运行器容器上将ACTIONS_RUNNER_REQUIRE_JOB_CONTAINER设置为false。这将指示运行器禁用此检查。

template:
  spec:
    containers:
      - name: runner
        image: ghcr.io/actions/actions-runner:latest
        command: ["/home/runner/run.sh"]
        env:
          - name: ACTIONS_RUNNER_REQUIRE_JOB_CONTAINER
            value: "false"

自定义容器模式

当您在gha-runner-scale-set Helm 图表的values.yaml文件中设置containerMode时，您可以使用以下任一值

dind 或
kubernetes

根据您为containerMode设置的值，配置将自动注入到gha-runner-scale-set Helm 图表的values.yaml文件的template部分中。

请参阅dind配置。
请参阅kubernetes配置。

要自定义规范，请注释掉或删除containerMode，并在template部分中追加所需的配置。

示例：运行`dind-rootless`

在决定运行dind-rootless之前，请确保您了解已知限制。

## githubConfigUrl is the GitHub url for where you want to configure runners
## ex: https://github.com/myorg/myrepo or https://github.com/myorg
githubConfigUrl: "https://github.com/actions/actions-runner-controller"

## githubConfigSecret is the k8s secrets to use when auth with GitHub API.
## You can choose to use GitHub App or a PAT token
githubConfigSecret: my-super-safe-secret

## maxRunners is the max number of runners the autoscaling runner set will scale up to.
maxRunners: 5

## minRunners is the min number of idle runners. The target number of runners created will be
## calculated as a sum of minRunners and the number of jobs assigned to the scale set.
minRunners: 0

runnerGroup: "my-custom-runner-group"

## name of the runner scale set to create.  Defaults to the helm release name
runnerScaleSetName: "my-awesome-scale-set"

## template is the PodSpec for each runner Pod
## For reference: https://kubernetes.ac.cn/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodSpec
template:
  spec:
    initContainers:
    - name: init-dind-externals
      image: ghcr.io/actions/actions-runner:latest
      command: ["cp", "-r", "/home/runner/externals/.", "/home/runner/tmpDir/"]
      volumeMounts:
        - name: dind-externals
          mountPath: /home/runner/tmpDir
    - name: init-dind-rootless
      image: docker:dind-rootless
      command:
        - sh
        - -c
        - |
          set -x
          cp -a /etc/. /dind-etc/
          echo 'runner:x:1001:1001:runner:/home/runner:/bin/ash' >> /dind-etc/passwd
          echo 'runner:x:1001:' >> /dind-etc/group
          echo 'runner:100000:65536' >> /dind-etc/subgid
          echo 'runner:100000:65536' >>  /dind-etc/subuid
          chmod 755 /dind-etc;
          chmod u=rwx,g=rx+s,o=rx /dind-home
          chown 1001:1001 /dind-home
      securityContext:
        runAsUser: 0
      volumeMounts:
        - mountPath: /dind-etc
          name: dind-etc
        - mountPath: /dind-home
          name: dind-home
    containers:
    - name: runner
      image: ghcr.io/actions/actions-runner:latest
      command: ["/home/runner/run.sh"]
      env:
        - name: DOCKER_HOST
          value: unix:///var/run/docker.sock
      volumeMounts:
        - name: work
          mountPath: /home/runner/_work
        - name: dind-sock
          mountPath: /var/run
    - name: dind
      image: docker:dind-rootless
      args:
        - dockerd
        - --host=unix:///var/run/docker.sock
      securityContext:
        privileged: true
        runAsUser: 1001
        runAsGroup: 1001
      volumeMounts:
        - name: work
          mountPath: /home/runner/_work
        - name: dind-sock
          mountPath: /var/run
        - name: dind-externals
          mountPath: /home/runner/externals
        - name: dind-etc
          mountPath: /etc
        - name: dind-home
          mountPath: /home/runner
    volumes:
    - name: work
      emptyDir: {}
    - name: dind-externals
      emptyDir: {}
    - name: dind-sock
      emptyDir: {}
    - name: dind-etc
      emptyDir: {}
    - name: dind-home
      emptyDir: {}

了解运行器容器钩子

当运行器检测到使用容器作业、服务容器或 Docker 操作的工作流运行时，它将调用运行器容器钩子以创建一个新的 Pod。运行器依赖于运行器容器钩子来调用 Kubernetes API并在与运行器 Pod 相同的命名空间中创建一个新的 Pod。此新创建的 Pod 将用于运行容器作业、服务容器或 Docker 操作。有关更多信息，请参阅runner-container-hooks存储库。

配置钩子扩展

从 ARC 0.4.0 版本开始，运行器容器钩子支持钩子扩展。您可以使用它们来配置由运行器容器钩子创建的 Pod。例如，您可以使用钩子扩展在 Pod 上设置安全上下文。钩子扩展允许您指定一个 YAML 文件，该文件用于更新由运行器容器钩子创建的 Pod 的PodSpec。

配置钩子扩展有两种选项。

存储在您的**自定义运行器镜像**中。您可以将 PodSpec 存储在自定义运行器镜像中的任何位置的 YAML 文件中。有关更多信息，请参阅“关于 Actions Runner Controller”。
存储在**ConfigMap**中。您可以使用 PodSpec 创建一个 ConfigMap，并将该 ConfigMap 挂载到运行器容器中。有关更多信息，请参阅 Kubernetes 文档中的ConfigMap。

注意

对于这两种选项，您都必须在运行器容器规范中设置ACTIONS_RUNNER_CONTAINER_HOOK_TEMPLATE环境变量，以指向挂载到运行器容器中的 YAML 文件的路径。

示例：使用 ConfigMap 设置 securityContext

在与运行器 Pod 相同的命名空间中创建一个 ConfigMap。例如

apiVersion: v1
kind: ConfigMap
metadata:
  name: hook-extension
  namespace: arc-runners
data:
  content: |
    metadata:
      annotations:
        example: "extension"
    spec:
      containers:
        - name: "$job" # Target the job container
          securityContext:
            runAsUser: 1000

.metadata.labels和metadata.annotations字段将按原样追加，除非它们的键是保留的。您无法覆盖.metadata.name和metadata.namespace字段。
大多数 PodSpec 字段是从指定的模板应用的，并将覆盖从您的 Helm chart 的 values.yaml 文件传递的值。
如果您指定了额外的卷，它们将被附加到运行程序指定的默认卷。
spec.containers 基于分配给它们的名称进行合并。
- 如果容器的名称为 $job
  - 则会忽略 spec.containers.name 和 spec.containers.image 字段。
  - spec.containers.env、spec.containers.volumeMounts 和 spec.containers.ports 字段将附加到挂钩创建的默认容器规范。
  - 其余字段按提供的方式应用。
- 如果容器的名称不是 $job，则这些字段将按原样添加到 pod 定义中。

所有者	指标	类型	描述
控制器管理器	gha_controller_pending_ephemeral_runners	gauge	处于挂起状态的临时运行程序数量
控制器管理器	gha_controller_running_ephemeral_runners	gauge	处于运行状态的临时运行程序数量
控制器管理器	gha_controller_failed_ephemeral_runners	gauge	处于失败状态的临时运行程序数量
控制器管理器	gha_controller_running_listeners	gauge	处于运行状态的侦听器数量
侦听器	gha_assigned_jobs	gauge	分配给运行程序规模集的作业数量
侦听器	gha_running_jobs	gauge	正在运行或排队等待运行的作业数量
侦听器	gha_registered_runners	gauge	运行程序规模集注册的运行程序数量
侦听器	gha_busy_runners	gauge	当前正在运行作业的已注册运行程序数量
侦听器	gha_min_runners	gauge	为运行程序规模集配置的最小运行程序数量
侦听器	gha_max_runners	gauge	为运行程序规模集配置的最大运行程序数量
侦听器	gha_desired_runners	gauge	运行程序规模集所需的运行程序数量（扩展向上/向下目标）
侦听器	gha_idle_runners	gauge	未运行作业的已注册运行程序数量
侦听器	gha_started_jobs_total	counter	自侦听器准备就绪以来启动的作业总数 [1]
侦听器	gha_completed_jobs_total	counter	自侦听器准备就绪以来完成的作业总数 [1]
侦听器	gha_job_startup_duration_seconds	histogram	等待工作流作业在运行程序规模集拥有的运行程序上启动所花费的秒数
侦听器	gha_job_execution_duration_seconds	histogram	运行程序规模集执行工作流作业所花费的秒数

升级 ARC

由于 Helm 不支持升级或删除 CRD，因此无法使用 Helm 升级 ARC。有关更多信息，请参阅 Helm 文档中的自定义资源定义。要将 ARC 升级到较新版本，您必须完成以下步骤。

卸载所有 gha-runner-scale-set 的安装。
等待资源清理。
卸载 ARC。
如果从您当前安装的版本到升级版本，CRD 发生了更改，请删除与 actions.github.com API 组关联的所有 CRD。
重新安装 ARC。

有关更多信息，请参阅“部署运行程序规模集”。

如果您想升级 ARC 但担心停机时间，则可以在高可用性配置中部署 ARC 以确保运行程序始终可用。有关更多信息，请参阅“高可用性和自动故障转移”。

注意

从 ARC 的社区支持版本过渡到 GitHub 支持版本是一项重大的架构更改。GitHub 支持版本涉及 ARC 许多组件的重新设计。它不是一个小的软件升级。由于这些原因，我们建议您首先在与生产环境匹配的暂存环境中测试新版本。这将确保在生产环境中部署之前设置的稳定性和可靠性。

部署金丝雀映像

您可以通过使用控制器管理器容器映像的金丝雀版本来测试功能，然后再发布这些功能。金丝雀映像以标记格式 canary-SHORT_SHA 发布。有关更多信息，请参阅容器注册表上的 gha-runner-scale-set-controller。

注意

您必须在本地文件系统上使用 Helm chart。
您不能使用已发布的 Helm chart。

将 gha-runner-scale-set-controller values.yaml 文件中的 tag 更新为：canary-SHORT_SHA
将 Chart.yaml 文件中 gha-runner-scale-set 的 appVersion 字段更新为：canary-SHORT_SHA
使用更新的 Helm chart 和 values.yaml 文件重新安装 ARC。

ARC 可以部署在高可用性（主动-主动）配置中。如果您在不同的区域部署了两个不同的 Kubernetes 集群，则可以在这两个集群中部署 ARC 并配置运行程序规模集以使用相同的 runnerScaleSetName。为此，每个运行程序规模集必须分配到一个不同的运行程序组。例如，您可以有两个分别命名为 arc-runner-set 的运行程序规模集，只要一个运行程序规模集属于 runner-group-A，另一个运行程序规模集属于 runner-group-B 即可。有关将运行程序规模集分配到运行程序组的信息，请参阅“使用组管理对自托管运行程序的访问权限”。

如果两个运行程序规模集都联机，则分配给它们的作业将被任意分配（分配竞争）。您无法配置作业分配算法。如果其中一个集群出现故障，则另一个集群中的运行程序规模集将继续正常获取作业，无需任何干预或配置更改。

跨组织使用 ARC

Actions Runner Controller 的单个安装允许您配置一个或多个运行程序规模集。这些运行程序规模集可以注册到存储库、组织或企业。您还可以使用运行程序组来控制这些运行程序规模集的权限边界。

最佳实践是为每个组织创建一个唯一的命名空间。您还可以为每个运行程序组或每个运行程序规模集创建一个命名空间。您可以在每个命名空间中安装任意数量的运行程序规模集。这将为您提供最高级别的隔离并提高您的安全性。您可以使用 GitHub 应用进行身份验证并为每个运行程序规模集定义细粒度的权限。

法律声明

部分内容已从 https://github.com/actions/actions-runner-controller/ 根据 Apache-2.0 许可证改编而来

Copyright 2019 Moto Ishizawa

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

    http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.

使用 Actions 运行器控制器部署运行器规模集

本文内容

关于运行器规模集

部署运行器规模集

使用高级配置选项

配置运行器规模集名称

选择运行器目标

使用 GitHub 应用进行身份验证

选项 1：创建 Kubernetes 密钥（推荐）

选项 2：在您的`values.yaml`文件中指定值

使用运行器组管理访问权限

配置出站代理

设置运行器的最大和最小数量

示例：运行器数量不受限制

示例：运行器的最小数量

示例：设置运行器的最大和最小数量

示例：作业队列清空

自定义 TLS 证书

使用私有容器注册表

配置控制器镜像

配置运行器镜像

更新运行器 Pod 的 Pod 规范

更新侦听器 Pod 的 Pod 规范

为容器使用 Docker-in-Docker 或 Kubernetes 模式

使用 Docker-in-Docker 模式

使用 Kubernetes 模式

先决条件

配置 Kubernetes 模式

自定义容器模式

示例：运行`dind-rootless`

了解运行器容器钩子

配置钩子扩展

示例：使用 ConfigMap 设置 securityContext

启用指标

ARC 可用指标

升级 ARC

部署金丝雀映像

高可用性和自动故障转移

跨组织使用 ARC

法律声明