GitLab Runner 在 Kubernetes Executor 的情况下

12 月 ago
清, 宇
3 minutes

首先

GitLab で CICD をする際に、実際にジョブを実行してくれる GitLab Runner 君ですが、Kubernetes 上に Pod として実行可能な、 Kubernetes Executor という仕組みが提供されています。

Kubernetes Executor の Job 実行の流れ

在公式文档中也有提到，大致上会按照下图的流程创建一个用于执行CICD的pod。

k8s-exec.drawio.png
    1. 首先，部署在Kubernetes上的GitLab Runner Pod会向GitLab实例查询是否存在可执行的Job。

 

    1. 然后，接收到任务的Runner Pod会向Kubernetes API请求创建一个Pod，

 

    1. 生成的Job执行Pod会实际完成任务。

 

    完成任务的Job Pod会悄悄地消失。

さて、この Job Pod には、最大3種類のコンテナが含まれているのですが、なんと2年前のアドベントカレンダーで詳しく説明してくださっているので、割愛させていただきます

Kubernetes Executor 部署

Kubernetes 上への、 GitLab Runner のデプロイは、GitLab Kubernetes Agent と呼ばれる、Agent を Kubernetes Cluster に導入して Agent 経由でデプロイする方法と、Helm chart を用いて、Runner のみを Kubernetes Cluster にデプロイする方法の2つがあります。

这里是Helm Chart仓库。
让我们看一下Chart.yaml。

apiVersion: v1
name: gitlab-runner
version: 0.35.0
appVersion: 14.5.0
description: GitLab Runner
keywords:
- git
- ci
- deploy
sources:
- https://hub.docker.com/r/gitlab/gitlab-runner/
- https://docs.gitlab.com/runner/
icon: https://gitlab.com/uploads/-/system/project/avatar/250833/runner_logo.png
maintainers:
- name: GitLab Inc.
  email: support@gitlab.com

12/11現在の、安定板 Chart バージョンは 0.35.0 で、だいたい毎月20日前後にマイナーバージョンが更新されています。
なお、Chart.yaml に併記されている appVersion は values.yaml で image 名を上書かないかぎり、デプロイされるgitlab/gitlab-runner image の tag バージョンに使用されます。

gitlab/gitlab-runner:alpine-v14.5.0

Kubernetes执行器的配置项

我们将以Helm Chart的values.yaml文件为中心来查看Kubernetes Executor的配置项。
GitLab Runner的Helm Chart的values.yaml文件中包含了GitLab Runner Pod的配置和每个作业生成的Job Pod的配置。

GitLab Runner Pod 的自身配置选项

gitlabUrl

GitLab Runner が問い合わせる GitLab インスタンスの URL を指定します

## The GitLab Server URL (with protocol) that want to register the runner against
## ref: https://docs.gitlab.com/runner/commands/README.html#gitlab-runner-register
##
# gitlabUrl: http://gitlab.your-domain.com/

runnerRegistrationToken

GitLab Runner を GitLab インスタンスに登録するためのトークンです
サブグループやリポジトリ単位で異なり、CI/CD Settings 画面の Runners セクションから取得できます
サブグループやリポジトリのトークンを使用することで、Runner の使用をそのサブグループ下、リポジトリなど任意のスコープに限定することができます

## The Registration Token for adding new Runners to the GitLab Server. This must
## be retrieved from your GitLab Instance.
## ref: https://docs.gitlab.com/ce/ci/runners/README.html
##
# runnerRegistrationToken: ""

concurrent

この GitLab Runner が生成し、同時に実行できるジョブの数を制限します
値10は、同時に実行できるジョブが10個以下であることを意味しています

## Configure the maximum number of concurrent jobs
## ref: https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-global-section
##
concurrent: 10

rbac.rules

この GitLab Runner で実行されるジョブにどれだけの権限を与えるか細かく設定可能です

  ## Define list of rules to be added to the rbac role permissions.
  ## Each rule supports the keys:
  ## - apiGroups: default "" (indicates the core API group) if missing or empty.
  ## - resources: default "*" if missing or empty.
  ## - verbs: default "*" if missing or empty.
  rules: []

rbac.clusterWideAccess

この GitLab Runner で実行されるジョブのアクセス範囲を、Cluster 全体とするか、GitLab Runner がデプロイされている namespace に閉じるか、選択します

  ## Run the gitlab-bastion container with the ability to deploy/manage containers of jobs
  ## cluster-wide or only within namespace
  clusterWideAccess: false

runners.config

この GitLab Runner が生成する Job Pod の設定をここで実施します
詳しくは次のセクションで説明します

## Configuration for the Pods that the runner launches for each new job
##
runners:
  # runner configuration, where the multi line strings is evaluated as
  # template so you can specify helm values inside of it.
  #
  # tpl: https://helm.sh/docs/howto/charts_tips_and_tricks/#using-the-tpl-function
  # runner configuration: https://docs.gitlab.com/runner/configuration/advanced-configuration.html
  config: |
    [[runners]]
      [runners.kubernetes]
        namespace = "{{.Release.Namespace}}"
        image = "ubuntu:16.04"

在values.yaml中有许多地方写着DEPRECATED: 请参见https://docs.gitlab.com/runner/install/kubernetes.html#additional-configuration。

过去，我们通过直接在yaml中编写配置来实现各个功能，但最近的趋势是根据config.toml在runners.config中进行配置。我认为这是为了避免随着功能增加而需要进行模板维护，以及实现更加灵活的配置的目的。

Job Pod 的配置项

Job Pod 的配置是通过 values.yaml 文件中的 runners.config 来描述的，使用 toml 文件格式。在这里，我们还会看到一些特定于 Kubernetes Executor 的配置。

首先是各种资源配额。
可以像下面这样，为工作 Pod 设置 cpu / memory 的请求 / 限制。

[[runners]]
  executor = "kubernetes"
  [runners.kubernetes]
    cpu_limit = "1000m"
    cpu_limit_overwrite_max_allowed = "2000m"
    cpu_request = "100m"
    cpu_request_overwrite_max_allowed = "1000m"
    service_cpu_request = "100m"
    service_cpu_request_overwrite_max_allowed = "1000m"
    memory_limit = "2Gi"
    memory_request = "128Mi"
    memory_request_overwrite_max_allowed = "2Gi"
    service_memory_request = "256Mi"
    service_memory_request_overwrite_max_allowed = "2Gi"

ここで面白いのが、*_overwrite_max_allowed という名前の設定群です。
特定のリポジトリで実行されるパイプラインのみ、必要とするリソース量が多い場合などに対応するため、overwrite する仕組みが設けられています。
例えば何も設定しない場合のリソースリクエストは *_request ですが、 *_request_overwrite_max_allowed の設定は、リポジトリごとで overwrite できるリクエストの最大値を規定しています。

在存储库中，您可以通过使用变量来设置 .gitlab-ci.yml 中以下所示的要覆盖的值，从而覆盖该容器的资源配额。

 variables:
   KUBERNETES_CPU_REQUEST: 1               # build container
   KUBERNETES_CPU_LIMIT: 2                 # build container
   KUBERNETES_MEMORY_REQUEST: 1Gi          # build container
   KUBERNETES_SERVICE_CPU_REQUEST: 1       # service container
   KUBERNETES_SERVICE_MEMORY_REQUEST: 2Gi  # service container

此外，在.gitlab-ci.yml中可以覆盖的设置不仅限于资源配额，还可以覆盖使用的service account、部署的命名空间以及pod的注释。

[[runners]]
  executor = "kubernetes"
  [runners.kubernetes]
    service_account_overwrite_allowed = ".*"
    namespace_overwrite_allowed = "ci-.*"
    pod_annotations_overwrite_allowed = ".*"

それぞれリポジトリ側で .gitlab-ci.yml を下記のように記述し、overwrite できます。

variables:
  KUBERNETES_SERVICE_ACCOUNT_OVERWRITE: ci-service-account
  KUBERNETES_NAMESPACE_OVERWRITE: ci-${CI_COMMIT_REF_SLUG}
  KUBERNETES_POD_ANNOTATIONS_1: "Key1=Val1"

また、toleration や、node selector も記述することとができるため、Job Pod の生成される Node Pool を制限することも可能です。

[[runners]]
  executor = "kubernetes"
  [runners.kubernetes]
    [runners.kubernetes.node_selector]
      dedicated = "ops"
    [runners.kubernetes.node_tolerations]
      "app=ops" = "NoSchedule"

除此之外，还可以在CICD中使用诸如host path、PVC、config map、secret、empty dir等卷挂载，设置Job Pod的安全上下文，设置Pod亲和性，设置生命周期钩子等等。不过，本次我想到这里就结束。

总结

谈到GitLab Runner的Kubernetes Executor，我们已经介绍了一个配置和设置的示例。除了我们介绍的这个例子，还有很多有趣的配置我们还没有尝试过，所以我们想要尝试更多不同的设置。非常感谢您读到这里。

✖
广告
将在 10 秒后关闭
bannerAds