Using the GitLab-Gitaly chart

gitaly 子图表提供了一个可配置的 Gitaly 服务器部署。

要求#

此图表依赖于对 Workhorse 服务的访问，可以是完整极狐GitLab 图表的一部分，也可以是从 Kubernetes 集群中可以访问的外部服务。

设计选择#

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

配置#

gitaly 图表配置分为两部分：外部服务 和 图表设置。

Gitaly 默认作为组件部署在极狐GitLab 图表中。如果单独部署 Gitaly，需要将 global.gitaly.enabled 设置为 false，并按照外部 Gitaly 文档中的说明进行其他配置。

安装命令行选项#

下表包含可以通过 --set 标志传递给 helm install 命令的所有可能图表配置。

图表配置示例#

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 命令添加配置。接受以 key / value 对形式记录在 git-config(1) 中的配置，如下所示。

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 限制，确保系统稳定性并防止资源耗尽。

请注意，在 Gitaly 启动之前运行的 initContainer 需要 以 root 身份执行。此容器将配置权限，以便 Gitaly 可以管理 cgroups。因此，它将在文件系统上挂载一个卷以具有对 /sys/fs/cgroup 的写访问权限。

超额订阅示例

yaml
1cgroups:
2  enabled: true
3  # 总限制跨所有仓库 cgroups
4  memoryBytes: 64424509440 # 60GiB
5  cpuShares: 1024
6  cpuQuotaUs: 1200000 # 12 cores
7  # 每个仓库限制，1000 个仓库 cgroups
8  repositories:
9    count: 1000
10    memoryBytes: 32212254720 # 30GiB
11    cpuShares: 512
12    cpuQuotaUs: 400000 # 4 cores

外部服务#

此图表应附加到 Workhorse 服务。

Workhorse#

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

图表设置#

以下值用于配置 Gitaly Pods。

Git 仓库持久性#

此图表配置了一个 PersistentVolumeClaim 并为 Git 仓库数据挂载了相应的持久卷。您需要在 Kubernetes 集群中有可用的物理存储才能正常工作。如果您宁愿使用 emptyDir，请禁用 PersistentVolumeClaim：persistence.enabled: false。

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 图表需要提供一个证书，以便通过 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

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 图表。

全局服务器挂钩#

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 创建的所有提交进行 GPG 签名，例如 WebIDE，以及极狐GitLab 创建的提交，如合并提交和压缩。

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

服务器端备份#

该图表支持 Gitaly 服务器端备份。要使用它们：

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

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

   yaml
   1gitlab:
   2  gitaly:
   3    extraEnvFrom:
   4       # 将现有对象存储密钥挂载到预期的环境变量。
   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      # 这是 Gitaly 服务器端备份的连接字符串。
   15      goCloudUrl: <object store connection URL>

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

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