Kubernetes 执行器

使用 Kubernetes 执行器来使用 Kubernetes 集群进行构建。执行器调用 Kubernetes 集群 API，并为每个极狐GitLab CI 作业创建一个 pod。

Kubernetes 执行器将构建分为多个步骤：

1. 准备：针对 Kubernetes 集群创建 Pod。这将创建构建和服务所需的容器。
2. 预构建：克隆、恢复缓存，并下载来自先前阶段的产物。此步骤在 Pod 的特殊容器上运行。
3. 构建：用户构建。
4. 后构建：创建缓存，将产物上传至极狐GitLab。此步骤也使用 Pod 的特殊容器。

Runner 如何创建 Kubernetes pods#

下图显示了极狐GitLab实例与托管在 Kubernetes 集群上的 runner 之间的交互。runner 调用 Kubernetes API 以在集群上创建 pods。

Pod 由以下容器组成，每个 service 在 .gitlab-ci.yml 或 config.toml 文件中定义：

• 定义为 build 的构建容器。
• 定义为 helper 的辅助容器。
• 定义为 svc-X 的服务容器，其中 X 是 [0-9]+。

服务和容器在同一个 Kubernetes pod 中运行，并共享相同的 localhost 地址。适用以下限制：

• 在 GitLab Runner 12.8 和 Kubernetes 1.7 及更高版本中，可以通过其 DNS 名称访问服务。如果您使用旧版本，必须使用 localhost。
• 不能使用同一端口的多个服务。例如，不能同时有两个 mysql 服务。

Rendering chart...

图中的交互适用于任何 Kubernetes 集群。例如，托管在主要公共云提供商上的交钥匙解决方案，或私有化部署的 Kubernetes 安装。

连接到 Kubernetes API#

使用以下选项连接到 Kubernetes API。提供的用户帐户必须有权在指定的命名空间中创建、列出和附加到 Pods。

如果您在 Kubernetes 集群中运行极狐GitLab Runner，可以省略这些字段，以便极狐GitLab Runner 自动发现 Kubernetes API。

如果您在集群外部运行极狐GitLab Runner，这些设置确保极狐GitLab Runner 可以访问集群上的 Kubernetes API。

为 Kubernetes API 调用设置承载令牌#

要设置用于创建 pods 的 API 调用的承载令牌，请使用 KUBERNETES_BEARER_TOKEN 变量。这允许项目所有者使用项目密钥变量指定承载令牌。

指定承载令牌时，必须设置 Host 配置设置。

yaml
variables:
  KUBERNETES_BEARER_TOKEN: thebearertokenfromanothernamespace

配置 runner API 权限#

要为核心 API 组配置权限，请更新极狐GitLab Runner Helm 图表的 values.yml 文件。

您可以选择：

• 将 rbac.create 设置为 true。
• 在 values.yml 文件中指定具有以下权限的服务帐户 serviceAccount.name: <service_account_name>。

您可以使用以下 YAML 角色定义来创建具有所需权限的角色。

yaml
1apiVersion: rbac.authorization.k8s.io/v1
2kind: Role
3metadata:
4  name: gitlab-runner
5  namespace: default
6rules:
7- apiGroups: [""]
8  resources: ["events"]
9  verbs:
10  - "list"
11  - "watch" # Required when `FF_PRINT_POD_EVENTS=true`
12- apiGroups: [""]
13  resources: ["namespaces"]
14  verbs:
15  - "create" # Required when `kubernetes.NamespacePerJob=true`
16  - "delete" # Required when `kubernetes.NamespacePerJob=true`
17- apiGroups: [""]
18  resources: ["pods"]
19  verbs:
20  - "create"
21  - "delete"
22  - "get"
23  - "list" # Required when using Informers (https://gitlab.cn/docs/runner/executors/kubernetes/#informers)
24  - "watch" # Required when `FF_KUBERNETES_HONOR_ENTRYPOINT=true`, `FF_USE_LEGACY_KUBERNETES_EXECUTION_STRATEGY=false`, using Informers (https://gitlab.cn/docs/runner/executors/kubernetes/#informers)
25- apiGroups: [""]
26  resources: ["pods/attach"]
27  verbs:
28  - "create" # Required when `FF_USE_LEGACY_KUBERNETES_EXECUTION_STRATEGY=false`
29  - "delete" # Required when `FF_USE_LEGACY_KUBERNETES_EXECUTION_STRATEGY=false`
30  - "get" # Required when `FF_USE_LEGACY_KUBERNETES_EXECUTION_STRATEGY=false`
31  - "patch" # Required when `FF_USE_LEGACY_KUBERNETES_EXECUTION_STRATEGY=false`
32- apiGroups: [""]
33  resources: ["pods/exec"]
34  verbs:
35  - "create"
36  - "delete"
37  - "get"
38  - "patch"
39- apiGroups: [""]
40  resources: ["pods/log"]
41  verbs:
42  - "get" # Required when `FF_KUBERNETES_HONOR_ENTRYPOINT=true`, `FF_USE_LEGACY_KUBERNETES_EXECUTION_STRATEGY=false`, `FF_WAIT_FOR_POD_TO_BE_REACHABLE=true`
43  - "list" # Required when `FF_KUBERNETES_HONOR_ENTRYPOINT=true`, `FF_USE_LEGACY_KUBERNETES_EXECUTION_STRATEGY=false`
44- apiGroups: [""]
45  resources: ["secrets"]
46  verbs:
47  - "create"
48  - "delete"
49  - "get"
50  - "update"
51- apiGroups: [""]
52  resources: ["serviceaccounts"]
53  verbs:
54  - "get"
55- apiGroups: [""]
56  resources: ["services"]
57  verbs:
58  - "create"
59  - "get"

• 适用于极狐GitLab 15.0 和 15.1。

• 适用于极狐GitLab 15.0.1、15.1.1 和 15.2，当 resource_availability_check_max_attempts 设置为高于 0 的值时。

• 从 GitLab Runner 15.8 开始，不再需要 configmaps 权限。

• 仅在以下情况下需要 event 权限：

  • 适用于极狐GitLab 16.2.1 及更高版本。

• 仅在以下情况下需要 namespace 权限：

  • 通过使用 namespace_per_job 启用命名空间隔离时。

• 仅在以下情况之一为真时需要 pods/log 权限：

  • 启用了 FF_KUBERNETES_HONOR_ENTRYPOINT 功能标志。

  • 禁用了 FF_USE_LEGACY_KUBERNETES_EXECUTION_STRATEGY 功能标志，当 CI_DEBUG_SERVICES 变量 设置为 true 时。

  • 启用了 FF_WAIT_FOR_POD_TO_BE_REACHABLE 功能标志。

Informers#

在 GitLab Runner 17.9.0 及更高版本中，Kubernetes informer 跟踪构建 pod 的更改。这有助于执行器更快地检测更改。

Informer 需要 pods 的 list 和 watch 权限。当执行器开始构建时，它会检查 Kubernetes API 的权限。 如果授予了所有权限，执行器将使用 informer。 如果缺少任何权限，极狐GitLab Runner 会记录警告。构建继续并使用以前的机制来跟踪构建 pod 的状态和更改。

配置设置#

在 config.toml 文件中使用以下设置来配置 Kubernetes 执行器。

CPU 请求和限制#

内存请求和限制#

存储请求和限制#

其他 config.toml 设置#

配置示例#

以下示例显示了 Kubernetes 执行器的 config.toml 文件的示例配置。

toml
1concurrent = 4
2
3[[runners]]
4  name = "myRunner"
5  url = "https://jihulab.com/ci"
6  token = "......"
7  executor = "kubernetes"
8  [runners.kubernetes]
9    host = "https://45.67.34.123:4892"
10    cert_file = "/etc/ssl/kubernetes/api.crt"
11    key_file = "/etc/ssl/kubernetes/api.key"
12    ca_file = "/etc/ssl/kubernetes/ca.crt"
13    namespace = "gitlab"
14    namespace_overwrite_allowed = "ci-.*"
15    bearer_token_overwrite_allowed = true
16    privileged = true
17    cpu_limit = "1"
18    memory_limit = "1Gi"
19    service_cpu_limit = "1"
20    service_memory_limit = "1Gi"
21    helper_cpu_limit = "500m"
22    helper_memory_limit = "100Mi"
23    poll_interval = 5
24    poll_timeout = 3600
25    dns_policy = "cluster-first"
26    priority_class_name = "priority-1"
27    logs_base_dir = "/tmp"
28    scripts_base_dir = "/tmp"
29    [runners.kubernetes.node_selector]
30      gitlab = "true"
31    [runners.kubernetes.node_tolerations]
32      "node-role.kubernetes.io/master" = "NoSchedule"
33      "custom.toleration=value" = "NoSchedule"
34      "empty.value=" = "PreferNoSchedule"
35      "onlyKey" = ""

配置执行器服务帐户#

要配置执行器服务帐户，可以设置 KUBERNETES_SERVICE_ACCOUNT 环境变量或使用 --kubernetes-service-account 标志。

Pods 和容器#

您可以配置 pods 和容器以控制作业的执行方式。

作业 pods 的默认标签#

作业 pods 的默认注释#

以下注释默认添加在运行作业的 Pod 上：

要覆盖默认注释，请在极狐GitLab Runner 配置中使用 pod_annotations。 您还可以在 .gitlab-ci.yml 文件 中为每个 CI/CD 作业覆盖注释。

Pod 生命周期#

Pod 的生命周期 可能会受到以下因素的影响：

• 在 TOML 配置文件中设置 pod_termination_grace_period_seconds 属性。 Pod 上运行的进程可以在发送 TERM 信号后运行指定的持续时间。 如果 Pod 在此期间未成功终止，则会发送 kill 信号。
• 启用 FF_USE_POD_ACTIVE_DEADLINE_SECONDS 功能标志。 启用后，如果作业超时，运行 CI/CD 作业的 Pod 将被标记为失败，所有相关的容器将被终止。要让极狐GitLab 首先超时作业， activeDeadlineSeconds 被设置为 配置的超时 + 1 秒。

覆盖 pod 容忍度#

要覆盖 Kubernetes pod 容忍度：

1. 在 config.toml 或 Helm values.yaml 文件中，要启用 CI 作业 pod 容忍度的覆盖，为 node_tolerations_overwrite_allowed 定义一个正则表达式。 此正则表达式用于验证以 KUBERNETES_NODE_TOLERATIONS_ 开头的 CI 变量名称的值。

   toml
   1runners:
   2 ...
   3 config: |
   4   [[runners]]
   5     [runners.kubernetes]
   6       node_tolerations_overwrite_allowed = ".*"

2. 在 .gitlab-ci.yml 文件中，定义一个或多个 CI 变量以覆盖 CI 作业 pod 容忍度。

   yaml
   1variables:
   2  KUBERNETES_NODE_TOLERATIONS_1: 'node-role.kubernetes.io/master:NoSchedule'
   3  KUBERNETES_NODE_TOLERATIONS_2: 'custom.toleration=value:NoSchedule'
   4  KUBERNETES_NODE_TOLERATIONS_3: 'empty.value=:PreferNoSchedule'
   5  KUBERNETES_NODE_TOLERATIONS_4: 'onlyKey'
   6  KUBERNETES_NODE_TOLERATIONS_5: '' # 容忍所有污点

覆盖 pod 标签#

要为每个 CI/CD 作业覆盖 Kubernetes pod 标签：

1. 在 .config.yaml 文件中，为 pod_labels_overwrite_allowed 定义一个正则表达式。

2. 在 .gitlab-ci.yml 文件中，设置 KUBERNETES_POD_LABELS_* 变量，其值为 key=value。Pod 标签将被覆盖为 key=value。您可以应用多个值：

   yaml
   variables:
     KUBERNETES_POD_LABELS_1: "Key1=Val1"
     KUBERNETES_POD_LABELS_2: "Key2=Val2"
     KUBERNETES_POD_LABELS_3: "Key3=Val3"

覆盖 pod 注释#

要为每个 CI/CD 作业覆盖 Kubernetes pod 注释：

1. 在 .config.yaml 文件中，为 pod_annotations_overwrite_allowed 定义一个正则表达式。

2. 在 .gitlab-ci.yml 文件中，设置 KUBERNETES_POD_ANNOTATIONS_* 变量，并使用 key=value 作为值。 Pod 注释将被覆盖为 key=value。您可以指定多个注释：

   yaml
   variables:
     KUBERNETES_POD_ANNOTATIONS_1: "Key1=Val1"
     KUBERNETES_POD_ANNOTATIONS_2: "Key2=Val2"
     KUBERNETES_POD_ANNOTATIONS_3: "Key3=Val3"

在以下示例中，设置了 pod_annotations 和 pod_annotations_overwrite_allowed。 此配置允许覆盖 config.toml 中配置的任何 pod_annotations。

toml
1[[runners]]
2  # 通常配置
3  executor = "kubernetes"
4  [runners.kubernetes]
5    image = "alpine"
6    pod_annotations_overwrite_allowed = ".*"
7    [runners.kubernetes.pod_annotations]
8      "Key1" = "Val1"
9      "Key2" = "Val2"
10      "Key3" = "Val3"
11      "Key4" = "Val4"

覆盖生成的 pod 规范#

此功能处于 beta 阶段。我们强烈建议您在将此功能用于生产集群之前，先在测试 Kubernetes 集群上使用它。要使用此功能，您必须启用 FF_USE_ADVANCED_POD_SPEC_CONFIGURATION 功能标志。

要修改 runner manager 生成的 PodSpec，请在 config.toml 文件中使用 pod_spec 设置。

pod_spec 设置：

• 覆盖并完成生成的 pod 规范的字段。
• 覆盖您在 [runners.kubernetes] 中设置的配置值。

您可以配置多个 pod_spec 设置。

在同一个 pod_spec 配置中，不能同时设置 patch_path 和 patch，否则会发生错误。

在 config.toml 中多个 pod_spec 配置的示例：

toml
1[[runners]]
2  [runners.kubernetes]
3    [[runners.kubernetes.pod_spec]]
4      name = "hostname"
5      patch = '''
6        hostname: "custom-pod-hostname"
7      '''
8      patch_type = "merge"
9    [[runners.kubernetes.pod_spec]]
10      name = "subdomain"
11      patch = '''
12        subdomain: "subdomain"
13      '''
14      patch_type = "strategic"
15    [[runners.kubernetes.pod_spec]]
16      name = "terminationGracePeriodSeconds"
17      patch = '''
18        [{"op": "replace", "path": "/terminationGracePeriodSeconds", "value": 60}]
19      '''
20      patch_type = "json"

合并补丁策略#

merge 补丁策略在现有 PodSpec 上应用键值替换。如果您使用此策略，config.toml 中的 pod_spec 配置将 覆盖 生成的最终 PodSpec 对象之前的值。由于值会被完全覆盖，您应该谨慎使用此补丁策略。

具有 merge 补丁策略的 pod_spec 配置示例：

toml
1concurrent = 1
2check_interval = 1
3log_level = "debug"
4shutdown_timeout = 0
5
6[session_server]
7  session_timeout = 1800
8
9[[runners]]
10  name = ""
11  url = "https://gitlab.example.com"
12  id = 0
13  token = "__REDACTED__"
14  token_obtained_at = 0001-01-01T00:00:00Z
15  token_expires_at = 0001-01-01T00:00:00Z
16  executor = "kubernetes"
17  shell = "bash"
18  environment = ["FF_USE_ADVANCED_POD_SPEC_CONFIGURATION=true", "CUSTOM_VAR=value"]
19  [runners.kubernetes]
20    image = "alpine"
21    ...
22    [[runners.kubernetes.pod_spec]]
23      name = "build envvars"
24      patch = '''
25        containers:
26        - env:
27          - name: env1
28            value: "value1"
29          - name: env2
30            value: "value2"
31          name: build
32      '''
33      patch_type = "merge"

使用此配置，最终 PodSpec 只有一个名为 build 的容器，其中包含两个环境变量 env1 和 env2。上面的示例会使相关的 CI 作业失败，因为：

• helper 容器规范被删除。
• build 容器规范丢失了极狐GitLab Runner 设置的所有必要配置。

为了防止作业失败，在本例中，pod_spec 必须包含由极狐GitLab Runner 生成的未修改的属性。

JSON patch 策略#

json patch 策略使用 JSON Patch 规范来控制 PodSpec 对象和数组的更新。您无法在 array 属性上使用此策略。

以下是使用 json patch 策略的 pod_spec 配置示例。在此配置中，向现有的 nodeSelector 添加了一个新的 key: value pair。现有的值不会被覆盖。

toml
1concurrent = 1
2check_interval = 1
3log_level = "debug"
4shutdown_timeout = 0
5
6[session_server]
7  session_timeout = 1800
8
9[[runners]]
10  name = ""
11  url = "https://gitlab.example.com"
12  id = 0
13  token = "__REDACTED__"
14  token_obtained_at = 0001-01-01T00:00:00Z
15  token_expires_at = 0001-01-01T00:00:00Z
16  executor = "kubernetes"
17  shell = "bash"
18  environment = ["FF_USE_ADVANCED_POD_SPEC_CONFIGURATION=true", "CUSTOM_VAR=value"]
19  [runners.kubernetes]
20    image = "alpine"
21    ...
22    [[runners.kubernetes.pod_spec]]
23      name = "val1 node"
24      patch = '''
25        { "op": "add", "path": "/nodeSelector", "value": { key1: "val1" } }
26      '''
27      patch_type = "json"

战略性 patch 策略#

strategic patch 策略使用应用于 PodSpec 对象每个字段的现有 patchStrategy。

以下是使用 strategic patch 策略的 pod_spec 配置示例。在此配置中，一个 resource request 被设置在构建容器上。

toml
1concurrent = 1
2check_interval = 1
3log_level = "debug"
4shutdown_timeout = 0
5
6[session_server]
7  session_timeout = 1800
8
9[[runners]]
10  name = ""
11  url = "https://gitlab.example.com"
12  id = 0
13  token = "__REDACTED__"
14  token_obtained_at = 0001-01-01T00:00:00Z
15  token_expires_at = 0001-01-01T00:00:00Z
16  executor = "kubernetes"
17  shell = "bash"
18  environment = ["FF_USE_ADVANCED_POD_SPEC_CONFIGURATION=true", "CUSTOM_VAR=value"]
19  [runners.kubernetes]
20    image = "alpine"
21    ...
22    [[runners.kubernetes.pod_spec]]
23      name = "cpu request 500m"
24      patch = '''
25        containers:
26        - name: build
27          resources:
28            requests:
29              cpu: "500m"
30      '''
31      patch_type = "strategic"

在此配置中，一个 resource request 被设置在构建容器上。

最佳实践#

1. 在生产环境部署前，在测试环境中测试添加的 pod_spec。
2. 确保 pod_spec 配置不会对极狐GitLab Runner 生成的规范产生负面影响。
3. 不要使用 merge patch 策略进行复杂的 pod 规范更新。
4. 在可用时，尽量使用 config.toml。例如，以下配置会用自定义 pod_spec 中设置的环境变量替换极狐GitLab Runner 首次设置的环境变量，而不是将环境变量添加到现有列表中。

toml
1concurrent = 1
2check_interval = 1
3log_level = "debug"
4shutdown_timeout = 0
5
6[session_server]
7  session_timeout = 1800
8
9[[runners]]
10  name = ""
11  url = "https://gitlab.example.com"
12  id = 0
13  token = "__REDACTED__"
14  token_obtained_at = 0001-01-01T00:00:00Z
15  token_expires_at = 0001-01-01T00:00:00Z
16  executor = "kubernetes"
17  shell = "bash"
18  environment = ["FF_USE_ADVANCED_POD_SPEC_CONFIGURATION=true", "CUSTOM_VAR=value"]
19  [runners.kubernetes]
20    image = "alpine"
21    ...
22    [[runners.kubernetes.pod_spec]]
23      name = "build envvars"
24      patch = '''
25        containers:
26        - env:
27          - name: env1
28            value: "value1"
29          name: build
30      '''
31      patch_type = "strategic"

通过修改 Pod Spec 为每个构建作业创建一个 PVC#

要为每个构建作业创建一个 PersistentVolumeClaim，请确保查看如何启用 Pod Spec 功能。

Kubernetes 允许您创建附加到 pod 生命周期的临时 PersistentVolumeClaim。如果在您的 Kubernetes 集群上启用了 动态供应，该方法有效。每个 PVC 都可以请求一个新的 Volume。该 volume 也与 pod 的生命周期绑定。

在启用 动态供应 后，可以如下修改 config.toml 来创建一个临时 PVC：

toml
1[[runners.kubernetes.pod_spec]]
2  name = "ephemeral-pvc"
3  patch = '''
4    containers:
5    - name: build
6      volumeMounts:
7      - name: builds
8        mountPath: /builds
9    - name: helper
10      volumeMounts:
11      - name: builds
12        mountPath: /builds
13    volumes:
14    - name: builds
15      ephemeral:
16        volumeClaimTemplate:
17          spec:
18            storageClassName: <The Storage Class that will dynamically provision a Volume>
19            accessModes: [ ReadWriteOnce ]
20            resources:
21              requests:
22                storage: 1Gi
23  '''

设置 pod 的安全策略#

在 config.toml 中配置 安全上下文 以为构建 pod 设置安全策略。

使用以下选项：

config.toml 中的 pod 安全上下文示例：

toml
1concurrent = %(concurrent)s
2check_interval = 30
3  [[runners]]
4    name = "myRunner"
5    url = "gitlab.example.com"
6    executor = "kubernetes"
7    [runners.kubernetes]
8      helper_image = "gitlab-registry.example.com/helper:latest"
9      [runners.kubernetes.pod_security_context]
10        run_as_non_root = true
11        run_as_user = 59417
12        run_as_group = 59417
13        fs_group = 59417

移除旧的 runner pods#

有时旧的 runner pods 未被清除。当 runner 管理器错误地关闭时可能会发生这种情况。

为了解决这种情况，您可以使用极狐GitLab Runner Pod Cleanup 应用程序来调度旧 pods 的清理。有关更多信息，请参阅：

• 极狐GitLab Runner Pod Cleanup 项目的 README。
• 极狐GitLab Runner Pod Cleanup 文档。

设置容器的安全策略#

在 config.toml 执行器中配置 容器安全上下文 以为构建、助手或服务 pods 设置容器安全策略。

使用以下选项：

在以下 config.toml 示例中，安全上下文配置：

• 设置 pod 安全上下文。
• 覆盖构建和助手容器的 run_as_user 和 run_as_group。
• 指定所有服务容器继承 pod 安全上下文中的 run_as_user 和 run_as_group。

toml
1concurrent = 4
2check_interval = 30
3  [[runners]]
4    name = "myRunner"
5    url = "gitlab.example.com"
6    executor = "kubernetes"
7    [runners.kubernetes]
8      helper_image = "gitlab-registry.example.com/helper:latest"
9      [runners.kubernetes.pod_security_context]
10        run_as_non_root = true
11        run_as_user = 59417
12        run_as_group = 59417
13        fs_group = 59417
14      [runners.kubernetes.init_permissions_container_security_context]
15        run_as_user = 1000
16        run_as_group = 1000
17      [runners.kubernetes.build_container_security_context]
18        run_as_user = 65534
19        run_as_group = 65534
20        [runners.kubernetes.build_container_security_context.capabilities]
21          add = ["NET_ADMIN"]
22      [runners.kubernetes.helper_container_security_context]
23        run_as_user = 1000
24        run_as_group = 1000
25      [runners.kubernetes.service_container_security_context]
26        run_as_user = 1000
27        run_as_group = 1000

设置拉取策略#

在 config.toml 文件中使用 pull_policy 参数来指定单个或多个拉取策略。该策略控制图像的获取和更新方式，并应用于构建图像、助手图像和任何服务。

要确定使用哪个策略，请参阅 Kubernetes 文档关于拉取策略的说明。

单个拉取策略：

toml
[runners.kubernetes]
  pull_policy = "never"

多个拉取策略：

toml
[runners.kubernetes]
  # 使用多个拉取策略
  pull_policy = ["always", "if-not-present"]

当您定义多个策略时，每个策略会被尝试，直到成功获取图像。例如，当您使用 [ always, if-not-present ] 时，如果 always 策略因临时注册表问题失败，则使用 if-not-present 策略。

要重试失败的拉取：

toml
[runners.kubernetes]
  pull_policy = ["always", "always"]

极狐GitLab 的命名约定与 Kubernetes 的不同。

指定容器能力#

您可以指定在容器中使用的 Kubernetes 能力。

要指定容器能力，请在 config.toml 中使用 cap_add 和 cap_drop 选项。容器运行时也可以定义一个默认的能力列表，例如 Docker 或 container。

有一个 能力列表 是 runner 默认删除的。在 cap_add 选项中列出的能力不会被删除。

config.toml 文件中的配置示例：

toml
1concurrent = 1
2check_interval = 30
3[[runners]]
4  name = "myRunner"
5  url = "gitlab.example.com"
6  executor = "kubernetes"
7  [runners.kubernetes]
8    # ...
9    cap_add = ["SYS_TIME", "IPC_LOCK"]
10    cap_drop = ["SYS_ADMIN"]
11    # ...

指定能力时：

• 用户定义的 cap_drop 优先于用户定义的 cap_add。如果您在两个设置中定义了相同的能力，则仅将 cap_drop 中的能力传递给容器。
• 从传递给容器配置的能力标识符中删除 CAP_ 前缀。例如，如果您想添加或删除 CAP_SYS_TIME 能力，在配置文件中，输入字符串 SYS_TIME。
• Kubernetes 集群的所有者可以定义 PodSecurityPolicy，其中指定的能力被允许、限制或默认添加。这些规则优先于任何用户定义的配置。

重写容器资源#

您可以为每个 CI/CD 作业重写 Kubernetes CPU 和内存分配。您可以为构建、助手和服务容器应用请求和限制设置。

要重写容器资源，请在 .gitlab-ci.yml 文件中使用以下变量。

这些变量的值被限制在该资源的 最大重写 设置内。如果未为某个资源设置最大重写，则该变量不被使用。

yaml
1 variables:
2   KUBERNETES_CPU_REQUEST: "3"
3   KUBERNETES_CPU_LIMIT: "5"
4   KUBERNETES_MEMORY_REQUEST: "2Gi"
5   KUBERNETES_MEMORY_LIMIT: "4Gi"
6   KUBERNETES_EPHEMERAL_STORAGE_REQUEST: "512Mi"
7   KUBERNETES_EPHEMERAL_STORAGE_LIMIT: "1Gi"
8
9   KUBERNETES_HELPER_CPU_REQUEST: "3"
10   KUBERNETES_HELPER_CPU_LIMIT: "5"
11   KUBERNETES_HELPER_MEMORY_REQUEST: "2Gi"
12   KUBERNETES_HELPER_MEMORY_LIMIT: "4Gi"
13   KUBERNETES_HELPER_EPHEMERAL_STORAGE_REQUEST: "512Mi"
14   KUBERNETES_HELPER_EPHEMERAL_STORAGE_LIMIT: "1Gi"
15
16   KUBERNETES_SERVICE_CPU_REQUEST: "3"
17   KUBERNETES_SERVICE_CPU_LIMIT: "5"
18   KUBERNETES_SERVICE_MEMORY_REQUEST: "2Gi"
19   KUBERNETES_SERVICE_MEMORY_LIMIT: "4Gi"
20   KUBERNETES_SERVICE_EPHEMERAL_STORAGE_REQUEST: "512Mi"
21   KUBERNETES_SERVICE_EPHEMERAL_STORAGE_LIMIT: "1Gi"

定义服务列表#

在 config.toml 中定义 服务 列表。

toml
1concurrent = 1
2check_interval = 30
3  [[runners]]
4    name = "myRunner"
5    url = "gitlab.example.com"
6    executor = "kubernetes"
7    [runners.kubernetes]
8      helper_image = "gitlab-registy.example.com/helper:latest"
9      [[runners.kubernetes.services]]
10        name = "postgres:12-alpine"
11        alias = "db1"
12      [[runners.kubernetes.services]]
13        name = "registry.example.com/svc1"
14        alias = "svc1"
15        entrypoint = ["entrypoint.sh"]
16        command = ["executable","param1","param2"]
17        environment = ["ENV=value1", "ENV2=value2"]

如果服务环境中包括 HEALTHCHECK_TCP_PORT，极狐GitLab Runner 会在服务响应该端口之前等待，然后再启动用户的 CI 脚本。您还可以在 .gitlab-ci.yml 的 services 部分中配置 HEALTHCHECK_TCP_PORT 环境变量。

重写服务容器资源#

如果一个作业有多个服务容器，您可以为每个服务容器设置明确的资源请求和限制。使用每个服务中的变量属性来重写 .gitlab-ci.yml 中指定的容器资源。

yaml
1  services:
2    - name: redis:5
3      alias: redis5
4      variables:
5        KUBERNETES_SERVICE_CPU_REQUEST: "3"
6        KUBERNETES_SERVICE_CPU_LIMIT: "6"
7        KUBERNETES_SERVICE_MEMORY_REQUEST: "3Gi"
8        KUBERNETES_SERVICE_MEMORY_LIMIT: "6Gi"
9        KUBERNETES_EPHEMERAL_STORAGE_REQUEST: "2Gi"
10        KUBERNETES_EPHEMERAL_STORAGE_LIMIT: "3Gi"
11    - name: postgres:12
12      alias: MY_relational-database.12
13      variables:
14        KUBERNETES_CPU_REQUEST: "2"
15        KUBERNETES_CPU_LIMIT: "4"
16        KUBERNETES_MEMORY_REQUEST: "1Gi"
17        KUBERNETES_MEMORY_LIMIT: "2Gi"
18        KUBERNETES_EPHEMERAL_STORAGE_REQUEST: "1Gi"
19        KUBERNETES_EPHEMERAL_STORAGE_LIMIT: "2Gi"

这些特定设置优先于作业的常规设置。值仍然受到该资源的 最大重写设置 的限制。

重写 Kubernetes 默认服务账户#

要在 .gitlab-ci.yml 文件中为每个 CI/CD 作业重写 Kubernetes 服务账户，请设置变量 KUBERNETES_SERVICE_ACCOUNT_OVERWRITE。

您可以使用此变量指定附加到命名空间的服务账户，这在复杂的 RBAC 配置中可能需要。

yaml
variables:
  KUBERNETES_SERVICE_ACCOUNT_OVERWRITE: ci-service-account

要确保在 CI 运行期间仅使用指定的服务账户，请定义一个正则表达式：

• 对于 service_account_overwrite_allowed 设置。
• 对于 KUBERNETES_SERVICE_ACCOUNT_OVERWRITE_ALLOWED 环境变量。

如果您没有设置其中任何一个，则重写被禁用。

设置 RuntimeClass#

使用 runtime_class_name 为每个作业容器设置 RuntimeClass。

如果您指定了一个 RuntimeClass 名称，但没有在集群中配置它，或者不支持该功能，则执行器无法创建作业。

toml
1concurrent = 1
2check_interval = 30
3  [[runners]]
4    name = "myRunner"
5    url = "gitlab.example.com"
6    executor = "kubernetes"
7    [runners.kubernetes]
8      runtime_class_name = "myclass"

更改构建日志和脚本的基础目录#

您可以更改将 emptyDir 卷挂载到 pod 用于构建日志和脚本的目录。您可以使用该目录来：

• 运行具有修改过图像的作业 pods。
• 以非特权用户身份运行。
• 自定义 SecurityContext 设置。

要更改目录：

• 对于构建日志，设置 logs_base_dir。
• 对于构建脚本，设置 scripts_base_dir。

预期值是一个不带尾部斜杠的基础目录字符串（例如，/tmp 或 /mydir/example）。目录必须已经存在。

此值会在生成的构建日志和脚本路径前加上前缀。例如：

toml
1  [[runners]]
2    name = "myRunner"
3    url = "gitlab.example.com"
4    executor = "kubernetes"
5    [runners.kubernetes]
6      logs_base_dir = "/tmp"
7      scripts_base_dir = "/tmp"

此配置将导致 emptyDir 卷挂载在：

• /tmp/logs-${CI_PROJECT_ID}-${CI_JOB_ID} 用于构建日志，而不是默认的 /logs-${CI_PROJECT_ID}-${CI_JOB_ID}。
• /tmp/scripts-${CI_PROJECT_ID}-${CI_JOB_ID} 用于构建脚本。

用户命名空间#

在 Kubernetes 1.30 及更高版本中，您可以使用 用户命名空间 将在容器中运行的用户与主机上的用户隔离。在容器中以 root 身份运行的进程可以在主机上以不同的非特权用户身份运行。

使用用户命名空间，您可以更好地控制用于运行 CI/CD 作业的镜像。需要额外设置的操作（例如以 root 身份运行）也可以在不增加主机攻击面的情况下运行。

要使用此功能，请确保您的集群已正确配置。以下示例为 hostUsers 键添加 pod_spec 并禁用特权 pods 和权限提升：

toml
1  [[runners]]
2    environment = ["FF_USE_ADVANCED_POD_SPEC_CONFIGURATION=true"]
3    builds_dir = "/tmp/builds"
4  [runners.kubernetes]
5    logs_base_dir = "/tmp"
6    scripts_base_dir = "/tmp"
7    privileged = false
8    allowPrivilegeEscalation = false
9  [[runners.kubernetes.pod_spec]]
10    name = "hostUsers"
11    patch = '''
12      [{"op": "add", "path": "/hostUsers", "value": false}]
13    '''
14    patch_type = "json"

使用用户命名空间时，您不能使用默认路径作为构建目录 (builds_dir)、构建日志 (logs_base_dir) 或构建脚本 (scripts_base_dir)。即使是容器的 root 用户也没有权限挂载卷。它们也不能在容器文件系统的根目录中创建目录。

相反，您可以更改构建日志和脚本的基础目录。您还可以通过设置 [[runners]].builds_dir 来更改构建目录。

操作系统、架构和 Windows 内核版本#

极狐GitLab Runner 使用 Kubernetes 执行器可以在不同操作系统上运行构建，如果配置的集群有运行这些操作系统的节点。

系统确定助手镜像的操作系统、架构和 Windows 内核版本（如果适用）。然后使用这些参数进行构建的其他方面，例如要使用的容器或镜像。

以下图表说明了系统如何检测这些详细信息：

Rendering chart...

以下是唯一影响构建的操作系统、架构和 Windows 内核版本选择的参数。

• helper_image_autoset_arch_and_os 配置
• kubernetes.io/os、kubernetes.io/arch 和 node.kubernetes.io/windows-build 标签选择器来自：
  • node_selector 配置
  • node_selector 重写

其他参数不会影响上述选择过程。但是，您可以使用诸如 affinity 之类的参数来进一步限制构建调度的节点。

节点#

指定执行构建的节点#

使用 node_selector 选项指定 Kubernetes 集群中的哪个节点可以用于执行构建。它是 string=string 格式的 key=value 对（在环境变量的情况下为 string:string）。

Runner 使用提供的信息来确定构建的操作系统和架构。这确保了使用正确的 助手镜像。默认的操作系统和架构是 linux/amd64。

您可以使用特定标签来调度具有不同操作系统和架构的节点。

linux/arm64 的示例#

toml
1  [[runners]]
2    name = "myRunner"
3    url = "gitlab.example.com"
4    executor = "kubernetes"
5
6    [runners.kubernetes.node_selector]
7      "kubernetes.io/arch" = "arm64"
8      "kubernetes.io/os" = "linux"

windows/amd64 的示例#

Kubernetes 对 Windows 有某些 限制。如果您使用进程隔离，还必须使用 node.kubernetes.io/windows-build 标签提供特定的 Windows 构建版本。

toml
1  [[runners]]
2    name = "myRunner"
3    url = "gitlab.example.com"
4    executor = "kubernetes"
5
6    # 必须启用 FF_USE_POWERSHELL_PATH_RESOLVER 功能标志，以便 PowerShell 在 Runner 在 Linux 环境中运行但目标是 Windows 节点时正确解析路径。
7    environment = ["FF_USE_POWERSHELL_PATH_RESOLVER=true"]
8
9    [runners.kubernetes.node_selector]
10      "kubernetes.io/arch" = "amd64"
11      "kubernetes.io/os" = "windows"
12      "node.kubernetes.io/windows-build" = "10.0.20348"

重写节点选择器#

要重写节点选择器：

1. 在 config.toml 或 Helm values.yaml 文件中，启用节点选择器的重写：

   toml
   1runners:
   2 ...
   3 config: |
   4   [[runners]]
   5     [runners.kubernetes]
   6       node_selector_overwrite_allowed = ".*"

2. 在 .gitlab-ci.yml 文件中，定义变量以重写节点选择器：

   yaml
   variables:
     KUBERNETES_NODE_SELECTOR_* = ''

在以下示例中，要重写 Kubernetes 节点架构，在 config.toml 和 .gitlab-ci.yml 文件中配置设置：

toml
1concurrent = 1
2check_interval = 1
3log_level = "debug"
4shutdown_timeout = 0
5
6listen_address = ':9252'
7
8[session_server]
9  session_timeout = 1800
10
11[[runners]]
12  name = ""
13  url = "https://gitlab.com/"
14  id = 0
15  token = "__REDACTED__"
16  token_obtained_at = "0001-01-01T00:00:00Z"
17  token_expires_at = "0001-01-01T00:00:00Z"
18  executor = "kubernetes"
19  shell = "bash"
20  [runners.kubernetes]
21    host = ""
22    bearer_token_overwrite_allowed = false
23    image = "alpine"
24    namespace = ""
25    namespace_overwrite_allowed = ""
26    pod_labels_overwrite_allowed = ""
27    service_account_overwrite_allowed = ""
28    pod_annotations_overwrite_allowed = ""
29    node_selector_overwrite_allowed = "kubernetes.io/arch=.*" # <--- 允许架构的重写

yaml
job:
  image: IMAGE_NAME
  variables:
    KUBERNETES_NODE_SELECTOR_ARCH: 'kubernetes.io/arch=amd64'  # <--- 选择架构

定义节点亲和性的列表#

定义一个 节点亲和性 列表，在构建时添加到 pod 规范中。

toml
1concurrent = 1
2[[runners]]
3  name = "myRunner"
4  url = "gitlab.example.com"
5  executor = "kubernetes"
6  [runners.kubernetes]
7    [runners.kubernetes.affinity]
8      [runners.kubernetes.affinity.node_affinity]
9        [[runners.kubernetes.affinity.node_affinity.preferred_during_scheduling_ignored_during_execution]]
10          weight = 100
11          [runners.kubernetes.affinity.node_affinity.preferred_during_scheduling_ignored_during_execution.preference]
12            [[runners.kubernetes.affinity.node_affinity.preferred_during_scheduling_ignored_during_execution.preference.match_expressions]]
13              key = "cpu_speed"
14              operator = "In"
15              values = ["fast"]
16            [[runners.kubernetes.affinity.node_affinity.preferred_during_scheduling_ignored_during_execution.preference.match_expressions]]
17              key = "mem_speed"
18              operator = "In"
19              values = ["fast"]
20        [[runners.kubernetes.affinity.node_affinity.preferred_during_scheduling_ignored_during_execution]]
21          weight = 50
22          [runners.kubernetes.affinity.node_affinity.preferred_during_scheduling_ignored_during_execution.preference]
23            [[runners.kubernetes.affinity.node_affinity.preferred_during_scheduling_ignored_during_execution.preference.match_expressions]]
24              key = "core_count"
25              operator = "In"
26              values = ["high", "32"]
27            [[runners.kubernetes.affinity.node_affinity.preferred_during_scheduling_ignored_during_execution.preference.match_fields]]
28              key = "cpu_type"
29              operator = "In"
30              values = ["arm64"]
31      [runners.kubernetes.affinity.node_affinity.required_during_scheduling_ignored_during_execution]
32        [[runners.kubernetes.affinity.node_affinity.required_during_scheduling_ignored_during_execution.node_selector_terms]]
33          [[runners.kubernetes.affinity.node_affinity.required_during_scheduling_ignored_during_execution.node_selector_terms.match_expressions]]
34            key = "kubernetes.io/e2e-az-name"
35            operator = "In"
36            values = [
37              "e2e-az1",
38              "e2e-az2"
39            ]

定义 pod 调度的节点#

使用 pod 亲和性和反亲和性来限制节点 您的 pod 有资格 调度的节点，基于其他 pods 上的标签。

config.toml 中的配置示例：

toml
1concurrent = 1
2[[runners]]
3  name = "myRunner"
4  url = "gitlab.example.com"
5  executor = "kubernetes"
6  [runners.kubernetes]
7    [runners.kubernetes.affinity]
8      [runners.kubernetes.affinity.pod_affinity]
9        [[runners.kubernetes.affinity.pod_affinity.required_during_scheduling_ignored_during_execution]]
10          topology_key = "failure-domain.beta.kubernetes.io/zone"
11          namespaces = ["namespace_1", "namespace_2"]
12          [runners.kubernetes.affinity.pod_affinity.required_during_scheduling_ignored_during_execution.label_selector]
13            [[runners.kubernetes.affinity.pod_affinity.required_during_scheduling_ignored_during_execution.label_selector.match_expressions]]
14              key = "security"
15              operator = "In"
16              values = ["S1"]
17        [[runners.kubernetes.affinity.pod_affinity.preferred_during_scheduling_ignored_during_execution]]
18        weight = 100
19        [runners.kubernetes.affinity.pod_affinity.preferred_during_scheduling_ignored_during_execution.pod_affinity_term]
20          topology_key = "failure-domain.beta.kubernetes.io/zone"
21          [runners.kubernetes.affinity.pod_affinity.preferred_during_scheduling_ignored_during_execution.pod_affinity_term.label_selector]
22            [[runners.kubernetes.affinity.pod_affinity.preferred_during_scheduling_ignored_during_execution.pod_affinity_term.label_selector.match_expressions]]
23              key = "security_2"
24              operator = "In"
25              values = ["S2"]
26      [runners.kubernetes.affinity.pod_anti_affinity]
27        [[runners.kubernetes.affinity.pod_anti_affinity.required_during_scheduling_ignored_during_execution]]
28          topology_key = "failure-domain.beta.kubernetes.io/zone"
29          namespaces = ["namespace_1", "namespace_2"]
30          [runners.kubernetes.affinity.pod_anti_affinity.required_during_scheduling_ignored_during_execution.label_selector]
31            [[runners.kubernetes.affinity.pod_anti_affinity.required_during_scheduling_ignored_during_execution.label_selector.match_expressions]]
32              key = "security"
33              operator = "In"
34              values = ["S1"]
35          [runners.kubernetes.affinity.pod_anti_affinity.required_during_scheduling_ignored_during_execution.namespace_selector]
36            [[runners.kubernetes.affinity.pod_anti_affinity.required_during_scheduling_ignored_during_execution.namespace_selector.match_expressions]]
37              key = "security"
38              operator = "In"
39              values = ["S1"]
40        [[runners.kubernetes.affinity.pod_anti_affinity.preferred_during_scheduling_ignored_during_execution]]
41        weight = 100
42        [runners.kubernetes.affinity.pod_anti_affinity.preferred_during_scheduling_ignored_during_execution.pod_affinity_term]
43          topology_key = "failure-domain.beta.kubernetes.io/zone"
44          [runners.kubernetes.affinity.pod_anti_affinity.preferred_during_scheduling_ignored_during_execution.pod_affinity_term.label_selector]
45            [[runners.kubernetes.affinity.pod_anti_affinity.preferred_during_scheduling_ignored_during_execution.pod_affinity_term.label_selector.match_expressions]]
46              key = "security_2"
47              operator = "In"
48              values = ["S2"]
49          [runners.kubernetes.affinity.pod_anti_affinity.preferred_during_scheduling_ignored_during_execution.pod_affinity_term.namespace_selector]
50            [[runners.kubernetes.affinity.pod_anti_affinity.preferred_during_scheduling_ignored_during_execution.pod_affinity_term.namespace_selector.match_expressions]]
51              key = "security_2"
52              operator = "In"
53              values = ["S2"]

网络#

配置容器生命周期钩子#

使用 容器生命周期钩子 在执行相应生命周期钩子时运行为处理程序配置的代码。

您可以配置两种类型的钩子：PreStop 和 PostStart。每种钩子仅允许设置一种类型的处理程序。

config.toml 文件中的配置示例：

toml
1[[runners]]
2  name = "kubernetes"
3  url = "https://gitlab.example.com/"
4  executor = "kubernetes"
5  token = "yrnZW46BrtBFqM7xDzE7dddd"
6  [runners.kubernetes]
7    image = "alpine:3.11"
8    privileged = true
9    namespace = "default"
10    [runners.kubernetes.container_lifecycle.post_start.exec]
11      command = ["touch", "/builds/postStart.txt"]
12    [runners.kubernetes.container_lifecycle.pre_stop.http_get]
13      port = 8080
14      host = "localhost"
15      path = "/test"
16      [[runners.kubernetes.container_lifecycle.pre_stop.http_get.http_headers]]
17        name = "header_name_1"
18        value = "header_value_1"
19      [[runners.kubernetes.container_lifecycle.pre_stop.http_get.http_headers]]
20        name = "header_name_2"
21        value = "header_value_2"

使用以下设置配置每个生命周期钩子：

KubernetesLifecycleExecAction#

KubernetesLifecycleHTTPGet#

KubernetesLifecycleHTTPGetHeader#

KubernetesLifecycleTcpSocket#

配置 Pod 的 DNS 设置#

使用以下选项配置 Pod 的 DNS 设置。

在 config.toml 文件中的示例配置：

toml
1concurrent = 1
2check_interval = 30
3[[runners]]
4  name = "myRunner"
5  url = "https://gitlab.example.com"
6  token = "__REDACTED__"
7  executor = "kubernetes"
8  [runners.kubernetes]
9    image = "alpine:latest"
10    [runners.kubernetes.dns_config]
11      nameservers = [
12        "1.2.3.4",
13      ]
14      searches = [
15        "ns1.svc.cluster-domain.example",
16        "my.dns.search.suffix",
17      ]
18
19      [[runners.kubernetes.dns_config.options]]
20        name = "ndots"
21        value = "2"
22
23      [[runners.kubernetes.dns_config.options]]
24        name = "edns0"

KubernetesDNSConfigOption#

默认丢弃能力列表#

极狐GitLab Runner 默认情况下会丢弃以下能力。

用户定义的 cap_add 优先于默认丢弃能力列表。如果要添加默认情况下丢弃的能力，请将其添加到 cap_add。

• NET_RAW

添加额外的主机别名#

此功能在 Kubernetes 1.7 及更高版本中可用。

配置一个 主机别名 以指示 Kubernetes 在容器的 /etc/hosts 文件中添加条目。

使用以下选项：

在 config.toml 文件中的示例配置：

toml
1concurrent = 4
2
3[[runners]]
4  # 常规配置
5  executor = "kubernetes"
6  [runners.kubernetes]
7    [[runners.kubernetes.host_aliases]]
8      ip = "127.0.0.1"
9      hostnames = ["web1", "web2"]
10    [[runners.kubernetes.host_aliases]]
11      ip = "192.168.1.1"
12      hostnames = ["web14", "web15"]

您还可以使用命令行参数 --kubernetes-host_aliases 和 JSON 输入配置主机别名。例如：

shell
gitlab-runner register --kubernetes-host_aliases '[{"ip":"192.168.1.100","hostnames":["myservice.local"]},{"ip":"192.168.1.101","hostnames":["otherservice.local"]}]'

卷#

使用 Kubernetes 执行器的缓存#

当缓存与 Kubernetes 执行器一起使用时，会在 Pod 上挂载一个名为 /cache 的卷。在作业执行期间，如果需要缓存数据，runner 会检查是否有可用的缓存数据。如果在缓存卷上有压缩文件，则缓存数据可用。

要设置缓存卷，请在 config.toml 文件中使用 cache_dir 设置。

• 如果可用，压缩文件会被解压缩到构建文件夹中，然后可以在作业中使用。
• 如果不可用，则从配置的存储中下载缓存数据，并将其保存到 cache dir 中作为压缩文件。然后将压缩文件解压缩到 build 文件夹中。

配置卷类型#

您可以挂载以下卷类型：

• hostPath
• persistentVolumeClaim
• configMap
• secret
• emptyDir
• csi

多个卷类型的配置示例：

toml
1concurrent = 4
2
3[[runners]]
4  # 常规配置
5  executor = "kubernetes"
6  [runners.kubernetes]
7    [[runners.kubernetes.volumes.host_path]]
8      name = "hostpath-1"
9      mount_path = "/path/to/mount/point"
10      read_only = true
11      host_path = "/path/on/host"
12    [[runners.kubernetes.volumes.host_path]]
13      name = "hostpath-2"
14      mount_path = "/path/to/mount/point_2"
15      read_only = true
16    [[runners.kubernetes.volumes.pvc]]
17      name = "pvc-1"
18      mount_path = "/path/to/mount/point1"
19    [[runners.kubernetes.volumes.config_map]]
20      name = "config-map-1"
21      mount_path = "/path/to/directory"
22      [runners.kubernetes.volumes.config_map.items]
23        "key_1" = "relative/path/to/key_1_file"
24        "key_2" = "key_2"
25    [[runners.kubernetes.volumes.secret]]
26      name = "secrets"
27      mount_path = "/path/to/directory1"
28      read_only = true
29      [runners.kubernetes.volumes.secret.items]
30        "secret_1" = "relative/path/to/secret_1_file"
31    [[runners.kubernetes.volumes.empty_dir]]
32      name = "empty-dir"
33      mount_path = "/path/to/empty_dir"
34      medium = "Memory"
35    [[runners.kubernetes.volumes.csi]]
36      name = "csi-volume"
37      mount_path = "/path/to/csi/volume"
38      driver = "my-csi-driver"
39      [runners.kubernetes.volumes.csi.volume_attributes]
40        size = "2Gi"