• 要求
• 设计选择
• 配置
  • 安装命令行选项
• Chart 配置示例
  • extraEnv
  • extraEnvFrom
  • image.pullSecrets
  • serviceAccount
  • tolerations
  • affinity
  • annotations
  • priorityClassName
  • git.config
  • cgroups
• 外部服务
  • Workhorse
• Chart 设置
  • Git 仓库持久化
  • 通过 TLS 运行 Gitaly
  • 全局服务器 hooks
  • 极狐GitLab 创建的 GPG 签名提交
  • 服务器端备份

使用 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 配置示例

extraEnv

extraEnv 允许您在 Pod 的所有容器中暴露额外的环境变量。

extraEnv 示例如下：

extraEnv:
  SOME_KEY: some_value
  SOME_OTHER_KEY: some_other_value

当容器启动时，您可以确认环境变量是否暴露：

env | grep SOME
SOME_KEY=some_value
SOME_OTHER_KEY=some_other_value

extraEnvFrom

extraEnvFrom 允许您从 pod 中的所有容器中的其它数据源，暴露其它环境变量。

下面是一个使用 extraEnvFrom 的示例：

extraEnvFrom:
  MY_NODE_NAME:
    fieldRef:
      fieldPath: spec.nodeName
  MY_CPU_REQUEST:
    resourceFieldRef:
      containerName: test-container
      resource: requests.cpu
  SECRET_THING:
    secretKeyRef:
      name: special-secret
      key: special_token
      # optional: boolean
  CONFIG_STRING:
    configMapKeyRef:
      name: useful-config
      key: some-string
      # optional: boolean

image.pullSecrets

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

有关私有仓库及其身份验证方法的其它详细信息，请参见 Kubernetes 文档。

下面是一个使用 pullSecrets 的例子：

image:
  repository: my.gitaly.repository
  tag: latest
  pullPolicy: Always
  pullSecrets:
  - name: my-secret-name
  - name: my-secondary-secret-name

serviceAccount

此部分用来控制是否应该创建一个 ServiceAccount 并确定是否应该将默认访问令牌挂载到 pod 中。

tolerations

tolerations 允许您调度 Pod 到受污染的工作节点上。

下面是一个使用 tolerations 的例子：

tolerations:
- key: "node_label"
  operator: "Equal"
  value: "true"
  effect: "NoSchedule"
- key: "node_label"
  operator: "Equal"
  value: "true"
  effect: "NoExecute"

affinity

更多信息，查看 affinity。

annotations

annotations 允许您向 registry pod 添加 annotation。

下面是 annotations 的一个使用示例：

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

priorityClassName

priorityClassName 允许您分配 PriorityClass 给 Gitaly Pods。

下面是 priorityClassName 的一个使用示例：

priorityClassName: persistence-enabled

git.config

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

git:
  config:
    - key: "pack.threads"
      value: 4
    - key: "fsck.missingSpaceBeforeDate"
      value: ignore

cgroups

为了防止资源耗尽，Gitaly 使用cgroups来分配 Git 进程到一个基于仓库的 cgroup。每个 cgroup 都有内存和 CPU 限制，以确保系统稳定，防止资源饱和。

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

Oversubscription 示例

cgroups:
  enabled: true
  # Total limit across all repository cgroups
  memoryBytes: 64424509440 # 60GiB
  cpuShares: 1024
  cpuQuotaUs: 1200000 # 12 cores
  # Per repository limits, 1000 repository cgroups
  repositories:
    count: 1000
    memoryBytes: 32212254720 # 30GiB
    cpuShares: 512
    cpuQuotaUs: 400000 # 4 cores

外部服务

Workhorse service 附在此 chart 中。

Workhorse

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

Chart 设置

以下值用于配置 Gitaly Pods。

Git 仓库持久化

此 chart 提供 PersistentVolumeClaim 并为 Git 仓库数据挂载相应的持久卷。您需要 Kubernetes 集群中有可用的物理存储才能使其工作。 如果您更愿意使用 emptyDir，请使用：persistence.enabled: false 禁用 PersistentVolumeClaim。

persistence:
  enabled: true
  storageClass: standard
  accessMode: ReadWriteOnce
  size: 50Gi
  matchLabels: {}
  matchExpressions: []
  subPath: "data"
  annotations: {}

通过 TLS 运行 Gitaly

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

1. Helm chart 需要提供证书以通过 TLS 与 Gitaly 进行通信。此证书应适用于所有存在的 Gitaly 节点。 因此，每个 Gitaly 节点的所有主机名都应作为 Subject Alternate Name (SAN) 添加到证书中。

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

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

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

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

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

全局服务器 hooks

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

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

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

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

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

极狐GitLab 创建的 GPG 签名提交

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

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

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

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

   gitlab:
     gitaly:
       gpgSigning:
         enabled: true
         secret: gitaly-gpg-signing-key
         key: signing_key
   

服务器端备份

chart 支持 Gitaly 服务端备份。如要使用：

1. 创建存储桶用以存储备份。

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

   gitlab:
     gitaly:
       extraEnvFrom:
          # Mount the exisitign object store secret to the expected environment variables.
          AWS_ACCESS_KEY_ID:
            secretKeyRef:
              name: <Rails object store secret>
              key: aws_access_key_id
          AWS_SECRET_ACCESS_KEY:
            secretKeyRef:
              name: <Rails object store secret>
              key: aws_secret_access_key
       backup:
         # This is the connection string for Gitaly server side backups.
         goCloudUrl: <object store connection URL>
   

   针对您存储后段的期望环境变量和存储 URL 格式详情，可以查看Gitaly 文档。

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