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

参数 默认值 说明
annotations   Pod annotations
common.labels {} 应用于此 chart 创建的所有对象的补充标签。
podLabels   补充 Pod 标签。 不会用于选择器。
external[].hostname - "" 外部节点的主机名
external[].name - "" 外部节点存储的名称
external[].port - "" 外部节点的端口
extraContainers   包含的额外容器列表
extraInitContainers   包含的额外 init 容器列表
extraVolumeMounts   要添加的附加挂载卷列表
extraVolumes   要创建的附加卷列表
extraEnv   要暴露的附加环境变量列表
gitaly.serviceName   生成的 Gitaly service 名称。优先于 global.gitaly.serviceName,默认为 <RELEASE-NAME>-gitaly
image.pullPolicy Always Gitaly 镜像拉取策略
image.pullSecrets   用于镜像仓库的 Secrets
image.repository registry.com/gitlab-org/build/cng/gitaly Gitaly 镜像仓库
image.tag master Gitaly 镜像标签
init.image.repository   initContainer 镜像
init.image.tag   initContainer 镜像标签
internal.names[] - default StatefulSet 存储的有序名称
serviceLabels {} 补充的 service 标签
service.externalPort 8075 Gitaly service 暴露的端口
service.internalPort 8075 Gitaly 内部端口
service.name gitaly Gitaly 在 Service 对象后面的 Service 端口的名称。
service.type ClusterIP Gitaly service 类型
securityContext.fsGroup 1000 在其下启动 Pod 的 Group ID
securityContext.runAsUser 1000 在其下启动 Pod 的 User ID
tolerations [] 分配给 Pod 的容忍标签
persistence.accessMode ReadWriteOnce Gitaly 持久化访问模式
persistence.annotations   Gitaly 持久化 annotations
persistence.enabled true Gitaly 启用持久化标记
persistence.matchExpressions   Label-expression 匹配绑定
persistence.matchLabels   Label-value 匹配绑定
persistence.size 50Gi Gitaly 持久化卷大小
persistence.storageClass   配置的 storageClassName
persistence.subPath   Gitaly 持久卷挂载路径
priorityClassName   Gitaly StatefulSet priorityClassName
logging.level   日志级别
logging.format json 日志格式
logging.sentryDsn   Sentry DSN URL - Go 服务器
logging.rubySentryDsn   Sentry DSN URL - gitaly-ruby
logging.sentryEnvironment   用于日志记录的 Sentry 环境
ruby.maxRss   触发内存重启的 Gitaly-Ruby 常驻集大小 (RSS)(单位为 bytes)
ruby.gracefulRestartTimeout   超过最大 RSS 后,强制重启之前的宽限时间
ruby.restartDelay   Gitaly-Ruby 内存在重启前必须保持的时间(秒)
ruby.numWorkers   Gitaly-Ruby worker 进程的数量
shell.concurrency[]   使用 rpcmaxPerRepo 指定的每个 RPC 端点的并发性
git.catFileCacheSize   Git cat-file 进程使用的缓存大小
prometheus.grpcLatencyBuckets   Gitaly 记录的使用 GRPC 方法调用直方图延迟相对应的存储桶。 需要输入字符串形式的数组(例如,"[1.0, 1.5, 2.0]"
statefulset.strategy {} 允许配置 statefulset 使用的更新策略

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

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

tolerations

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

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

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

annotations

annotations 允许您向 registry pod 添加 annotation。

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

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

priorityClassName

priorityClassName 允许您分配 PriorityClass 给 Gitaly Pods。

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

priorityClassName: persistence-enabled

securityContext

由于上游 Kubernetes 中的 fsGroup 已知问题,当仓库包含大量文件时,Gitaly 的 StatefulSet 性能可能会受到影响。 通过更改或完全删除 securityContext 的设置来缓解问题。

gitlab:
  gitaly:
    securityContext:
      fsGroup: ""
      runAsUser: ""
note示例语法完全删除了 securityContext 设置。 由于 Helm 将默认值与用户提供的配置合并的方式,设置 securityContext: {}securityContext: 不起作用。

外部服务

Workhorse service 附在此 chart 中。

Workhorse

workhorse:
  host: workhorse.example.com
  serviceName: webservice
  port: 8181
名称 类型 默认值 说明
host String   Workhorse 服务器的主机名。可以省略,使用 serviceName 进行代替。
port Integer 8181 连接 Workhorse 服务器的端口
serviceName String webservice 运行 Workhorse 数据库的 service名称。如果该配置存在,且 host 的值不存在 , 则 chart 将服务的主机名替换 host 的值。这样使用 Workhorse 作为整个 chart 一部分时很方便。

Chart 设置

以下值用于配置 Gitaly Pods。

noteGitaly 使用身份验证令牌对 Workhorse 和 Sidekiq 服务进行身份验证。 Auth Token secret 和密钥源于 global.gitaly.authToken 值。此外,Gitaly 容器有一份 GitLab Shell 的副本,其中有一些可以设置的配置。 Shell authToken 源自global.shell.authToken 值。

Git 仓库持久化

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

noteGitaly 的持久性设置用于应该对您的所有 Gitaly pod 有效的 volumeClaimTemplate。应包括旨在引用单个特定卷(例如 volumeName)的设置。如果要引用特定卷,需要手动创建 PersistentVolumeClaim。
note部署后,您将无法通过我们的设置进行更改。 在 StatefulSet 中,VolumeClaimTemplate 是不可变的。
persistence:
  enabled: true
  storageClass: standard
  accessMode: ReadWriteOnce
  size: 50Gi
  matchLabels: {}
  matchExpressions: []
  subPath: "/data"
  annotations: {}
名称 类型 默认值 说明
accessMode String ReadWriteOnce 设置 PersistentVolumeClaim 中请求的访问模式。 有关详细信息,请参阅 Kubernetes 访问模式文档
enabled Boolean true 设置是否对存储库数据使用 PersistentVolumeClaims。 如果为 false,则使用 emptyDir 卷。
matchExpressions Array   在选择要绑定的卷时,接受要匹配的标签条件对象数组。用于PersistentVolumeClaimselector部分。 请参阅 卷文档
matchLabels Map   在选择要绑定的卷时,接受要匹配的标签名称和标签值的映射。用于PersistentVolumeClaimselector 部分。 请参阅 卷文档
size String 50Gi 为数据持久化,请求的最小的卷大小
storageClass String   在 Volume Claim 上设置 storageClassName 以进行 dynamic provisioning。当未设置或为空时,将使用默认 provisioner。如果设置为连字符,禁用 dynamic provisioning。
subPath String   设置要挂载的卷中的路径,而不是卷的根路径。 如果子路径为空,则使用根路径。
annotations Map   为动态供应设置卷声明的 annotation。有关详细信息,请参阅 Kubernetes Annotations 文档

通过 TLS 运行 Gitaly

note本节涉及使用 Helm chart 在集群内运行的 Gitaly。如果您使用外部 Gitaly 实例并希望使用 TLS 与之通信,请参阅 外部 Gitaly 文档

Gitaly 支持通过 TLS 与其他组件通信。设置 global.gitaly.tls.enabledglobal.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
    
note为内部 Gitaly pod 生成自定义签名证书的基础脚本,可以以此为例。用户可以使用或参考该脚本来生成具有适当 SAN 属性的证书。
  1. 使用创建的证书创建 k8s TLS 密钥。

    kubectl create secret tls gitaly-server-tls --cert=gitaly.crt --key=gitaly.key
    
  2. 通过传递附加参数 --set global.gitaly.tls.enabled=true --set global.gitaly.tls.secretName=<secret name> 重新部署 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