使用 GitLab-Gitaly chart

gitaly 子 chart 提供可配置的 Gitaly 服务器部署。

要求#

此 chart 依赖对 Workhorse 服务的访问，该服务可以是完整 GitLab chart 的一部分，也可以作为可从部署此 chart 的 Kubernetes 集群访问的外部服务提供。

设计选择#

此 chart 中使用的 Gitaly 容器还包含 GitLab Shell 代码库，以便对尚未移植到 Gitaly 中的 Git 代码仓库执行操作。Gitaly 容器内部包含一份 GitLab Shell 容器的副本，因此我们还需要在此 chart 中配置 GitLab Shell。

配置#

gitaly chart 的配置分为两部分：外部服务和 chart 设置。

默认情况下，部署 GitLab chart 时会将 Gitaly 作为组件部署。如果单独部署 Gitaly，需要将 global.gitaly.enabled 设置为 false，并按照外部 Gitaly 文档中的说明执行额外配置。

安装命令行选项#

下表包含可使用 --set 标志提供给 helm install 命令的所有可能的 chart 配置。

Chart 配置示例#

configuration#

configuration 是一个透传块，其内容会直接渲染到 Gitaly config.toml中。其键与 Gitaly 配置结构一致，因此可以在此提供任何 Gitaly 设置。

在 configuration 下设置的值会合并到 chart 现有的 Gitaly 设置（例如 git 和 dailyMaintenance）之上，并优先于它们。这些现有键仍然受支持，但建议使用 configuration。

映射的键计划弃用。

以下是 configuration的使用示例：

yaml
configuration:
  git:
    catfile_cache_size: 100
  daily_maintenance:
    start_hour: 23

以下部分由 chart 管理，如果在 configuration 下设置将被忽略，因为它们的值仅在 Gitaly pod 启动时确定：

• storage：从 pod 的主机名派生
• auth：从挂载的密钥中读取的令牌
• cgroups：从 pod 的 cgroup 路径读取的挂载点

如果在 configuration 下设置，prometheus 部分也会被忽略，因为其 grpc_latency_buckets 值需要特殊格式，而透传编码无法生成该格式。请改为通过 prometheus.grpcLatencyBuckets 进行配置。

如果在 configuration 下设置，TLS 和指标监听设置（tls_listen_addr、tls 和 prometheus_listen_addr）也会被忽略，因为它们必须与 chart 创建的 Service 端口和挂载的证书匹配。请改为通过 global.gitaly.tls 和 metrics 进行配置。

extraEnv#

extraEnv 允许您在 pod 中的所有容器中公开额外的环境变量。

以下是 extraEnv的使用示例：

yaml
extraEnv:
  SOME_KEY: some_value
  SOME_OTHER_KEY: some_other_value

容器启动后，您可以确认环境变量已公开：

shell
env | grep SOME
SOME_KEY=some_value
SOME_OTHER_KEY=some_other_value

extraEnvFrom#

extraEnvFrom 允许您在 pod 中的所有容器中从其他数据源公开额外的环境变量。

以下是 extraEnvFrom的使用示例：

yaml
1extraEnvFrom:
2  MY_NODE_NAME:
3    fieldRef:
4      fieldPath: spec.nodeName
5  MY_CPU_REQUEST:
6    resourceFieldRef:
7      containerName: test-container
8      resource: requests.cpu
9  SECRET_THING:
10    secretKeyRef:
11      name: special-secret
12      key: special_token
13      # optional: boolean
14  CONFIG_STRING:
15    configMapKeyRef:
16      name: useful-config
17      key: some-string
18      # optional: boolean

image.pullSecrets#

pullSecrets 允许您向私有镜像仓库进行身份验证，以便为 pod 拉取镜像。

有关私有镜像仓库及其身份验证方法的更多详细信息，请参阅 Kubernetes 文档。

以下是 pullSecrets的使用示例

yaml
1image:
2  repository: my.gitaly.repository
3  tag: latest
4  pullPolicy: Always
5  pullSecrets:
6  - name: my-secret-name
7  - name: my-secondary-secret-name

serviceAccount#

本节控制是否应创建 ServiceAccount 以及是否应在 pod 中挂载默认访问令牌。

tolerations#

tolerations 允许您在带有污点的工作节点上调度 pod

以下是 tolerations的使用示例：

yaml
1tolerations:
2- key: "node_label"
3  operator: "Equal"
4  value: "true"
5  effect: "NoSchedule"
6- key: "node_label"
7  operator: "Equal"
8  value: "true"
9  effect: "NoExecute"

affinity#

有关更多信息，请参阅 affinity。

annotations#

annotations 允许您向 Gitaly pod 添加注解。

以下是 annotations的使用示例：

yaml
annotations:
  kubernetes.io/example-annotation: annotation-value

priorityClassName#

priorityClassName 允许您为 Gitaly pod 分配 PriorityClass。

以下是 priorityClassName的使用示例：

yaml
priorityClassName: persistence-enabled

git.config#

git.config 允许您为 Gitaly 生成的所有 Git 命令添加配置。接受 git-config(1)中记录的配置，以 key / value 对的形式提供，如下所示。

yaml
1git:
2  config:
3    - key: "pack.threads"
4      value: 4
5    - key: "fsck.missingSpaceBeforeDate"
6      value: ignore

cgroups#

为防止资源耗尽，Gitaly 使用 cgroups 根据所操作的代码仓库将 Git 进程分配到某个 cgroup。每个 cgroup 都有内存和 CPU 限制，确保系统稳定性并防止资源饱和。

init-cgroups init 容器在 Gitaly 启动之前运行，并配置 cgroup 所有权，以便 Gitaly 可以管理 cgroups。该 init 容器：

• 必须以 root 身份运行（runAsUser: 0）。
• 挂载一个对 /sys/fs/cgroup 具有写访问权限的卷。

以下示例对代码仓库 cgroups 进行了超额订阅，为它们分配的组合资源超过父 cgroup 限制，因此单个代码仓库可以突发而无需提高整体限制。有关更多信息，请参阅配置超额订阅。

yaml
1gitlab:
2  gitaly:
3    cgroups:
4      enabled: true
5      # Total limit across all repository cgroups
6      memoryBytes: 64424509440 # 60GiB
7      cpuShares: 1024
8      cpuQuotaUs: 1200000 # 12 cores
9      # Per repository limits, 1000 repository cgroups
10      repositories:
11        count: 1000
12        memoryBytes: 32212254720 # 30GiB
13        cpuShares: 512
14        cpuQuotaUs: 400000 # 4 cores

init-cgroups 容器安全上下文#

init-cgroups 容器的安全上下文通过 cgroups.initContainer.securityContext 配置。该映射会直接渲染到容器清单中，因此接受 Kubernetes SecurityContext中任何有效的字段。无法识别的字段或 Pod 级字段会导致 Kubernetes API 验证错误，而不会被静默忽略。

在强制执行严格安全策略的集群上，例如使用 restricted 安全上下文约束（SCC）的 OpenShift，init-cgroups 容器还需要 privileged: true 和 allowPrivilegeEscalation: true 才能执行必要的 cgroup 所有权更改。

以下示例以特权容器方式运行 init-cgroups，以满足 OpenShift restricted SCC 的要求。

yaml
1gitlab:
2  gitaly:
3    cgroups:
4      enabled: true
5      initContainer:
6        securityContext:
7          runAsUser: 0
8          runAsGroup: 0
9          runAsNonRoot: false
10          privileged: true
11          allowPrivilegeEscalation: true

外部服务#

此 chart 应附加到 Workhorse 服务。

Workhorse#

yaml
workhorse:
  host: workhorse.example.com
  serviceName: webservice
  port: 8181

Chart 设置#

以下值用于配置 Gitaly Pod。

Git 代码仓库持久化#

此 chart 会预配一个 PersistentVolumeClaim，并为 Git 代码仓库数据挂载相应的持久卷。为此，您需要在 Kubernetes 集群中拥有可用的物理存储。如果您更愿意使用 emptyDir，请通过以下方式禁用 PersistentVolumeClaim：persistence.enabled: false。

Gitaly 的持久化设置用于 volumeClaimTemplate，该模板应对所有 Gitaly pod 有效。您不应包含旨在引用单个特定卷的设置（例如 volumeName）。如果您想引用特定卷，需要手动创建 PersistentVolumeClaim。

部署后，您无法通过我们的设置更改这些内容。在 StatefulSet中，VolumeClaimTemplate 是不可变的。

yaml
1persistence:
2  enabled: true
3  storageClass: standard
4  accessMode: ReadWriteOnce
5  size: 50Gi
6  matchLabels: {}
7  matchExpressions: []
8  subPath: "data"
9  annotations: {}

通过 TLS 运行 Gitaly#

Gitaly 支持通过 TLS 与其他组件通信。这由 global.gitaly.tls.enabled 和 global.gitaly.tls.secretName 设置控制。请按照以下步骤通过 TLS 运行 Gitaly：

1. Helm chart 期望提供证书以通过 TLS 与 Gitaly 通信。此证书应适用于所有存在的 Gitaly 节点。因此，每个 Gitaly 节点的所有主机名都应作为主题备用名称（SAN）添加到证书中。

   要了解要使用的主机名，请检查 Toolbox pod 中的 /srv/gitlab/config/gitlab.yml 文件，并查看其中 repositories.storages 键下指定的各个 gitaly_address 字段。

   shell
   kubectl exec -it <Toolbox pod> -- grep gitaly_address /srv/gitlab/config/gitlab.yml

用于为内部 Gitaly pod 生成自定义签名证书的基本脚本可在此代码仓库中找到。用户可以使用或参考该脚本生成具有正确 SAN 属性的证书。

该脚本涵盖部分地址（.svc）和完全限定地址（.svc.cluster.local）。无论是否设置 global.clusterDomain，证书都保持有效。如果您的集群使用不同的域，请将其作为 CLUSTER_DOMAIN 传入：

shell
CLUSTER_DOMAIN=k8s.example ./scripts/generate_certificates.sh gitaly

上一步中的 gitaly_address 值显示了证书必须涵盖哪些名称。

1. 使用创建的证书创建 k8s TLS 密钥。

   shell
   kubectl create secret tls gitaly-server-tls --cert=gitaly.crt --key=gitaly.key

2. 通过传入 --set global.gitaly.tls.enabled=true 重新部署 Helm chart。

全局服务器钩子#

Gitaly StatefulSet 支持全局服务器钩子。钩子脚本在 Gitaly pod 上运行，因此仅限于 Gitaly 容器中可用的工具。

钩子使用 ConfigMaps 填充，可以通过适当设置以下值来使用：

1. global.gitaly.hooks.preReceive.configmap
2. global.gitaly.hooks.postReceive.configmap
3. global.gitaly.hooks.update.configmap

要填充 ConfigMap，您可以将 kubectl 指向一个脚本目录：

shell
kubectl create configmap MAP_NAME --from-file /PATH/TO/SCRIPT/DIR

对极狐GitLab 创建的提交进行 GPG 签名#

Gitaly 能够对通过极狐GitLab UI（例如 WebIDE）创建的所有提交，以及由极狐GitLab 创建的提交（例如合并提交和压缩提交）进行 GPG 签名。

1. 使用您的 GPG 私钥创建 k8s 密钥。

   shell
   kubectl create secret generic gitaly-gpg-signing-key --from-file=signing_key=/path/to/gpg_signing_key.gpg

2. 在您的 values.yaml中启用 GPG 签名。

   yaml
   1gitlab:
   2  gitaly:
   3    gpgSigning:
   4      enabled: true
   5      secret: gitaly-gpg-signing-key
   6      key: signing_key

服务器端备份#

此 chart 支持 Gitaly 服务器端备份。要使用它们：

1. 创建一个存储桶来存储备份。

2. 配置对象存储凭据和存储 URL。

   yaml
   1gitlab:
   2  gitaly:
   3    extraEnvFrom:
   4       # Mount the existing object store secret to the expected environment variables.
   5       AWS_ACCESS_KEY_ID:
   6         secretKeyRef:
   7           name: <Rails object store secret>
   8           key: aws_access_key_id
   9       AWS_SECRET_ACCESS_KEY:
   10         secretKeyRef:
   11           name: <Rails object store secret>
   12           key: aws_secret_access_key
   13    backup:
   14      # This is the connection string for Gitaly server side backups.
   15      goCloudUrl: <object store connection URL>

   有关您的对象存储后端所需的环境变量和存储 URL 格式，请参阅 Gitaly 文档。

3. 使用 backup-utility 启用服务器端备份。