Task Runner

Task Runner Pod 用于在 GitLab 应用程序中执行定期内务管理任务。这些任务包括备份、Sidekiq 维护和 Rake 任务。

配置

以下配置是 Task Runner chart 提供的默认设置：

gitlab:
  ## doc/charts/gitlab/task-runner
  task-runner:
    enabled: true
    replicas: 1
    backups:
      cron:
        enabled: false
        concurrencyPolicy: Replace
        persistence:
          enabled: false
          accessMode: 'ReadWriteOnce'
          size: '10Gi'
        resources:
          requests:
            cpu: '50m'
            memory: '350M'
        schedule: '0 1 * * *'
      objectStorage:
        backend: 's3'
        config: {}
    persistence:
      enabled: false
      accessMode: 'ReadWriteOnce'
      size: '10Gi'
    resources:
      requests:
        cpu: '50m'
        memory: '350M'
    securityContext:
      fsGroup: '1000'
      runAsUser: '1000'

参数	说明	默认值
`annotations`	Annotations to add to the Task Runner Pods and Jobs	`{}`
`common.labels`	应用于此 chart 创建的所有对象的补充标签。	`{}`
`antiAffinityLabels.matchLabels`	用于设置反亲和选项的标签
`backups.cron.concurrencyPolicy`	Kubernetes 作业并发策略	`Replace`
`backups.cron.enabled`	备份 CronJob 启用标志	false
`backups.cron.extraArgs`	传递给备份实用程序的参数字符串
`backups.cron.failedJobsHistoryLimit`	历史上失败的备份作业列表数	`1`
`backups.cron.persistence.accessMode`	备份 cron 持久化访问方式	`ReadWriteOnce`
`backups.cron.persistence.enabled`	备份 cron 启用持久化标志	false
`backups.cron.persistence.matchExpressions`	Label-expression 匹配绑定
`backups.cron.persistence.matchLabels`	Label-value 匹配绑定
`backups.cron.persistence.size`	备份 cron 持久卷大小	`10Gi`
`backups.cron.persistence.storageClass`	用于配置的 StorageClass 名称
`backups.cron.persistence.subPath`	备份 cron 持久卷挂载路径
`backups.cron.persistence.volumeName`	现有的持久卷名称
`backups.cron.resources.requests.cpu`	备份 cron 最低所需的 CPU	`50m`
`backups.cron.resources.requests.memory`	备份 cron 最低所需的内存	`350M`
`backups.cron.schedule`	Cron 样式时间计划字符串	`0 1 * * *`
`backups.cron.successfulJobsHistoryLimit`	历史上成功备份作业列表的数量	`3`
`backups.objectStorage.backend`	要使用的对象存储提供程序（`s3` 或 `gcs`）	`s3`
`backups.objectStorage.config.gcpProject`	当后端为 `gcs` 时使用的 GCP 项目	””
`backups.objectStorage.config.key`	secret 中包含凭证的键	””
`backups.objectStorage.config.secret`	对象存储凭证的secret	””
`common.labels`	应用于此 chart 创建的所有对象的补充标签。	`{}`
`deployment.strategy`	允许配置 deployment 使用的更新策略	{ `type`: `Recreate` }
`enabled`	启用 Task Runner 标记	true
`extra`	额外`gitlab.yml`配置的 YAML 块	{}
`image.pullPolicy`	Task Runner 镜像拉取策略	`IfNotPresent`
`image.pullSecrets`	拉取 Task Runner 镜像使用的 secrets
`image.repository`	Task Runner 镜像仓库	`registry.gitlab.com/gitlab-org/build/cng/gitlab-task-runner-ee`
`image.tag`	Task Runner 镜像标签	`master`
`init.image.repository`	Task Runner init 镜像仓库
`init.image.tag`	Task Runner init 镜像标签
`init.resources`	Task Runner init 容器资源需求	{ `requests`: { `cpu`: `50m` }}
`nodeSelector`	Task Runner 和备份作业的节点选择
`persistence.accessMode`	Task Runner 持久化访问模式	`ReadWriteOnce`
`persistence.enabled`	Task Runner 启用持久化标记	false
`persistence.matchExpressions`	Label-expression 匹配绑定
`persistence.matchLabels`	Label-value 匹配绑定
`persistence.size`	Gitaly 持久化卷大小	`10Gi`
`persistence.storageClass`	配置的 storageClassName
`persistence.subPath`	Gitaly 持久卷挂载路径
`persistence.volumeName`	存在的 PersistentVolume 名称
`podLabels`	运行 Task Runner 的 Pods 的标签	{}
`replicas`	Task Runner Pods 的副本数	`1`
`resources.requests`	Task Runner 的最小请求资源	{ `cpu`: `50m`, `memory`: `350M`
`securityContext.fsGroup`	在其下启动 Pod 的 Group ID	`1000`
`securityContext.runAsUser`	在其下启动 Pod 的 User ID	`1000`
`serviceAccount.annotations`	ServiceAccount 的 annotation	{}
`serviceAccount.enabled`	使用 ServiceAccount 的标记	false
`serviceAccount.create`	创建 ServiceAccount 的标记	false
`serviceAccount.name`	使用的 ServiceAccount 的名称
`tolerations`	分配给 Pod 的容忍标签

备份

有关配置备份的信息，参考备份和恢复文档。有关如何执行备份的技术实施的其他信息，请参考备份和恢复架构文档。

持久化配置

用于备份和恢复的持久存储是单独配置的。为备份和恢复操作配置 GitLab 时，请查看以下注意事项。

备份使用 backup.cron.persistence.* 属性，恢复使用 persistence.* 属性。有关持久性存储配置的进一步描述将仅使用最终属性键（例如 .enabled 或 .size），并且需要添加适当的前缀。

默认情况下，持久化存储是禁用的，因此需要将 .enabled 设置为 true 以备份或恢复任何大小的内容。另外，Kubernetes 创建的 PersistentVolume 需要指定.storageClass，或者需要手动创建 PersistentVolume。如果 .storageClass 被指定为 ‘-‘，那么 PersistentVolume 将使用 Kubernetes 集群中指定的默认 StorageClass 创建。

如果 PersistentVolume 是手动创建的，那么可以使用 .volumeName 属性或使用选择器 .matchLables / .matchExpressions 属性。

在大多数情况下，.accessMode 的默认值将为只有 Task Runner 访问的 PersistentVolumes 提供足够的控制。请查阅 Kubernetes 集群中安装的 CSI 驱动的文档以确保设置正确。

备份注意事项

备份操作需要一定量的磁盘空间来保存要备份的各个组件，然后再将它们写入备份对象存储。磁盘空间量取决于以下因素：

项目数量和每个项目下存储的数据量
PostgresSQL 数据库的大小（议题、MR 等）
每个对象存储后端的大小

一旦确定了粗略大小，就可以设置 backup.cron.persistence.size 属性，以便开始备份。

恢复注意事项

在恢复备份期间，需要先将备份解压到磁盘，然后才能在正在运行的实例上替换文件。这个恢复磁盘空间的大小由 persistence.size 属性控制。请注意，随着 GitLab 安装实例大小的增加，恢复磁盘空间的大小也需要相应地增加。在大多数情况下，恢复磁盘空间的大小应与备份磁盘空间的大小相同。

Task Runner 包含的工具

Task Runner 容器包含有用的 GitLab 工具，例如 Rails 控制台、Rake 任务等。这些命令允许检查数据库迁移的状态、执行管理任务的 Rake 任务、与 Rails 控制台交互：

# locate the Task Runner pod
kubectl get pods -lapp=task-runner

# Launch a shell inside the pod
kubectl exec -it <Task Runner pod name> -- bash

# open Rails console
gitlab-rails console -e production

# execute a Rake task
gitlab-rake gitlab:env:info