使用 GitLab Webservice Chart

webservice 子 chart 为 GitLab Rails 网络服务器,使得每个 pod 具有两个 Webservice worker。(单个 pod 能够在 GitLab 中为任何 Web 请求提供服务的最低要求)

目前 chart 中使用的容器还包括一份 GitLab Workhorse 的副本,我们还没有拆分出来。

要求

此 chart 依赖于 Redis、PostgreSQL、Gitaly 和 Registry 服务,可以作为完成 GitLab chart 的一部分,或者作为从此 chart 部署到 Kubernetes 集群访问的外部服务。

配置

webservice chart 配置如下:全局配置deployment 设置Ingress 设置外部服务chart 设置

安装命令行选项

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

参数值 默认值 描述
annotations   Pod annotations
podLabels   补充 Pod 标签。 不会用于选择器。
common.labels   应用于此 chart 创建的所有对象的补充标签。
deployment.terminationGracePeriodSeconds 30 Kubernetes 等待 pod 退出的秒数,注意必须大于 shutdown.blackoutSeconds
deployment.livenessProbe.initialDelaySeconds 20 启动 liveness 探测前的延迟
deployment.livenessProbe.periodSeconds 60 多久执行一次 liveness 探测
deployment.livenessProbe.timeoutSeconds 30 liveness 探测超时时长
deployment.livenessProbe.successThreshold 1 liveness 探测失败后被视为成功的最小连续成功次数
deployment.livenessProbe.failureThreshold 3 探测成功后被视为失败的 liveness 探测的最小连续失败次数
deployment.readinessProbe.initialDelaySeconds 0 启动 readiness 探测前的延迟
deployment.readinessProbe.periodSeconds 10 多久执行一次 readiness 探测
deployment.readinessProbe.timeoutSeconds 2 readiness 探测超时时长
deployment.readinessProbe.successThreshold 1 readiness 探测失败后被视为成功的最小连续成功次数
deployment.readinessProbe.failureThreshold 3 探测成功后被视为失败的 readiness 探测的最小连续失败次数
deployment.strategy {} 允许配置 deployment 使用的更新策略。如果未提供,使用集群默认值。
enabled true 启用 Webservice 标记
extraContainers   包含的额外容器列表
extraInitContainers   包含的额外 init 容器列表
extras.google_analytics_id nil 前端的 Google Analytics ID
extraVolumeMounts   要添加的附加挂载卷列表
extraVolumes   要创建的附加卷列表
extraEnv   要暴露的附加环境变量列表
extraEnvFrom   要暴露的其它数据源的额外环境变量列表
gitlab.webservice.workhorse.image registry.jihulab.com/gitlab-cn/build/cng-images/gitlab-workhorse Workhorse 镜像仓库
gitlab.webservice.workhorse.tag   Workhorse 镜像标签
hpa.behavior {scaleDown: {stabilizationWindowSeconds: 300 }} 包含放大和缩小行为的规范(需要 autoscaling/v2beta2 或更高版本)
hpa.customMetrics [] 自定义指标包含用于计算所需副本数的规范(覆盖在 targetAverageUtilization 中配置的平均 CPU 利用率的默认使用值)
hpa.cpu.targetType AverageValue 设置自动缩放 CPU 目标类型,必须是 UtilizationAverageValue
hpa.targetAverageValue 1 设置自动扩缩容目标值
hpa.cpu.targetAverageUtilization   设置自动缩放 CPU 目标利用率
hpa.memory.targetType   设置自动缩放内存目标类型,必须是 UtilizationAverageValue
hpa.memory.targetAverageValue   设置自动缩放内存目标值
hpa.memory.targetAverageUtilization   设置自动缩放内存目标利用率
hpa.minReplicas   最小副本数
hpa.maxReplicas   最大副本数
hpa.targetAverageValue   已弃用 设置自动缩放 CPU 目标值
sshHostKeys.mount false 是否挂载包含公共 SSH 密钥的 GitLab Shell 密钥。
sshHostKeys.mountName ssh-host-keys 已挂载卷的名称。
sshHostKeys.types [dsa,rsa,ecdsa,ed25519] 要挂载的 SSH 密钥类型列表。
image.pullPolicy Always Webservice 镜像拉取策略
image.pullSecrets   用于镜像仓库的 Secrets
image.repository registry.jihulab.com/gitlab-cn/build/cng-images/gitlab-webservice Webservice 镜像仓库
image.tag   Webservice 镜像标签
init.image.repository   initContainer 镜像
init.image.tag   initContainer 镜像标签
metrics.enabled true 指标端点是否可用于抓取
metrics.port 8083 指标端点端口
metrics.path /metrics 指标端点路径
metrics.serviceMonitor.enabled false 是否创建 ServiceMonitor 使 Prometheus Operator 能够管理指标抓取,请注意启用此功能会删除 prometheus.io 抓取注释
metrics.serviceMonitor.additionalLabels {} 要添加到 ServiceMonitor 的其它标签
metrics.serviceMonitor.endpointConfig {} ServiceMonitor 的附加端点配置
metrics.annotations   已废弃 设置明确的指标注释。替换为模板内容。
metrics.tls.enabled false 为 metrics/web_exporter 端点启用 TLS
metrics.tls.secretName {Release.Name}-webservice-metrics-tls 指标/web_exporter 端点 TLS 证书和密钥的 secret
minio.bucket git-lfs 使用 MinIO 时,存储桶名称
minio.port 9000 MinIO service 的端口
minio.serviceName minio-svc MinIO service 的名称
monitoring.ipWhitelist [0.0.0.0/0] 要为监控端点列入白名单的 IP 列表
monitoring.exporter.enabled false 启用网络服务器以暴露 Prometheus 指标
monitoring.exporter.port 8083 用于 metrics exporter 的端口号
psql.password.key psql-password psql secret 中保存 psql 密码的 key
psql.password.secret gitlab-postgres psql secret 名称
psql.port   设置 PostgreSQL 服务器端口。优先于 global.psql.port
puma.disableWorkerKiller true 禁用 Puma worker memory killer
puma.workerMaxMemory   Puma worker killer 的最大内存(以兆字节为单位)
puma.threads.min 4 最小 Puma 线程数
puma.threads.max 4 最大 Puma 线程数
rack_attack.git_basic_auth {} 查看文档获取详细信息
redis.serviceName redis Redis service 名称
registry.api.port 5000 Registry 端口
registry.api.protocol http Registry 协议
registry.api.serviceName registry Registry service 名称
registry.enabled true 在所有项目菜单中添加/删除仓库链接
registry.tokenIssuer gitlab-issuer Registry 令牌发行者
replicaCount 1 Webservice 副本数
resources.requests.cpu 300m Webservice 最小 CPU
resources.requests.memory 1.5G Webservice 最小内存
service.externalPort 8080 Webservice 暴露的端口
securityContext.fsGroup 1000 在其下启动 Pod 的 Group ID
securityContext.runAsUser 1000 在其下启动 Pod 的 User ID
serviceLabels {} 补充的 service 标签
service.internalPort 8080 Webservice 内部端口
service.type ClusterIP Webservice service 类型
service.workhorseExternalPort 8181 Workhorse 暴露的端口
service.workhorseInternalPort 8181 Workhorse 内部端口
service.loadBalancerIP   分配给 LoadBalancer 的 IP 地址(如果云提供商支持)
service.loadBalancerSourceRanges   允许访问 LoadBalancer 的 IP CIDR 列表(如果支持)。当 service.type = LoadBalancer 需要
shell.authToken.key secret shell secret 中保存 shell 令牌的 key
shell.authToken.secret {Release.Name}-gitlab-shell-secret Shell 令牌 secret
shell.port nil 在 UI 生成的 SSH URL 中使用的端口号
shutdown.blackoutSeconds 10 接收关闭命令后保持 Webservice 运行的秒数,注意必须小于 deployment.terminationGracePeriodSeconds
tls.enabled false Webservice TLS 启用
tls.secretName {Release.Name}-webservice-tls Webservice TLS secrets。secretName 必须指向 Kubernetes TLS secret
tolerations [] 分配给 Pod 的容忍标签
trusted_proxies []
workhorse.logFormat json 日志格式。 有效格式:jsonstructuredtext
workerProcesses 2 Webservice workers 的数量
workhorse.keywatcher true 为 Redis 订阅 Workhorse。对/api/* 的任何 deployment 服务请求是必需的,但对于其它 deployment 可以安全地禁用
workhorse.shutdownTimeout global.webservice.workerTimeout + 1 (秒) 等待所有 Web 请求从 Workhorse 清除的时间。 示例:1min65s
workhorse.trustedCIDRsForPropagation   可信任用于传播关联 ID 的 CIDR 块列表。 -propagateCorrelationID 选项也必须在 workhorse.extraArgs 中使用才能使其工作。有关更多详细信息,请参阅 Workhorse 文档
workhorse.trustedCIDRsForXForwardedFor   可用于通过 X-Forwarded-For HTTP 标头解析实际客户端 IP 的 CIDR 块列表。 这与workhorse.trustedCIDRsForPropagation 一起使用。 有关更多详细信息,请参阅 Workhorse 文档
workhorse.livenessProbe.initialDelaySeconds 20 启动 liveness 探测前的延迟
workhorse.livenessProbe.periodSeconds 60 多久执行一次 liveness 探测
workhorse.livenessProbe.timeoutSeconds 30 liveness 探测超时时长
workhorse.livenessProbe.successThreshold 1 liveness 探测失败后被视为成功的最小连续成功次数
workhorse.livenessProbe.failureThreshold 3 探测成功后被视为失败的 liveness 探测的最小连续失败次数
workhorse.monitoring.exporter.enabled false 启用 workhorse 暴露 Prometheus 指标
workhorse.monitoring.exporter.port 9229 Workhorse Prometheus 指标使用的端口号
workhorse.monitoring.exporter.tls.enabled false 当设置为 true 时,在指标端点上启用 TLS。需要为 Workhorse 启用 TLS
workhorse.readinessProbe.initialDelaySeconds 0 启动 readiness 探测前的延迟
workhorse.readinessProbe.periodSeconds 10 多久执行一次 readiness 探测
workhorse.readinessProbe.timeoutSeconds 2 readiness 探测超时时长
workhorse.readinessProbe.successThreshold 1 readiness 探测失败后被视为成功的最小连续成功次数
workhorse.readinessProbe.failureThreshold 3 探测成功后被视为失败的 readiness 探测的最小连续失败次数
workhorse.imageScaler.maxProcs 2 可以同时运行的最大镜像缩放进程数
workhorse.imageScaler.maxFileSizeBytes 250000 缩放器要处理的镜像的最大文件大小(以字节为单位)
workhorse.tls.verify true 当设置为 true 时,会强制 NGINX Ingress 验证 Workhorse 的 TLS 证书。对于自定义 CA,您还需要设置 workhorse.tls.caSecretName。对于自签名证书,必须设置为 false
workhorse.tls.secretName   包含 TLS 密钥和证书对的 TLS Secret 的名称,在启用 Workhorse TLS 时是必需的。
workhorse.tls.caSecretName   包含 CA 证书的 Secret 的名称。不是 TLS Secret,必须只有 ca.crt 密钥,用于 NGINX 的 TLS 验证。
webServer puma 选择将用于请求处理的 Web 服务器(Webservice/Puma)
priorityClassName "" 允许配置 pod priorityClassName,这用于在驱逐的情况下控制 pod 优先级

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.webservice.repository
  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

strategy

deployment.strategy 允许您更改 deployment 更新策略。 它定义了 deployment 更新时如何重新创建 pod。 如果未提供,则使用集群默认值。 例如,如果您不想在滚动更新开始时创建额外的 Pod,并将最大不可用 Pod 更改为 50%:

deployment:
  strategy:
    rollingUpdate:
      maxSurge: 0
      maxUnavailable: 50%

您还可以将更新策略的类型更改为 Recreate,但要小心,因为它会在调度新 Pod 之前杀死所有 Pod,并且在启动新 Pod 之前 Web UI 将不可用。在这种情况下,您不需要定义 rollingUpdate,只需定义 type

deployment:
  strategy:
    type: Recreate

更多详细信息,请参见 Kubernetes 文档

TLS

一个 Webservice pod 运行两个容器:

  • gitlab-workhorse
  • webservice

gitlab-workhorse

Workhorse 支持 Web 和指标端点的 TLS。将保护 Workhorse 和其他组件之间的通信,特别是 nginx-ingressgitlab-shellgitaly。TLS 证书应在通用名称 (CN) 或主题备用名称 (SAN) 中包含 Workhorse 服务主机名(例如 RELEASE-webservice-default.default.svc)。

注意多个 Webservice 的部署是可以存在的,所以需要为不同的服务名准备 TLS 证书。可以通过多个 SAN 或通配符证书来实现。

生成 TLS 证书后,为其创建一个 Kubernetes TLS Secret。您还需要创建另一个 Secret,它只包含 TLS 证书的 CA 证书和 ca.crt 密钥。

可以通过将 global.workhorse.tls.enabled 设置为 true,并将 Secret 名称传递给 gitlab.webservice.workhorse.tls.secretNameglobal.certificates.customCAs 来为 gitlab-workhorse 容器启用 TLS。 相应的证书.customCAs`。

gitlab.webservice.workhorse.tls.verifytrue(默认)时,还需要将 CA 证书 Secret 名称传递给 gitlab.webservice.workhorse.tls.caSecretName。 这是自签名证书和自定义 CA 所必需的。NGINX 使用此 Secret 来验证 Workhorse 的 TLS 证书。

global:
  workhorse:
    tls:
      enabled: true
  certificates:
    customCAs:
      - secret: gitlab-workhorse-ca
gitlab:
  webservice:
    workhorse:
      tls:
        verify: true
        secretName: gitlab-workhorse-tls
        caSecretName: gitlab-workhorse-ca
      monitoring:
        exporter:
          enabled: true
          tls:
            enabled: true

通过将 gitlab.webservice.workhorse.monitoring.tls.enabled 设置为 true,可以在 gitlab-workhorse 容器的指标端点上启用 TLS。请注意,指标端点上的 TLS 仅在为 Workhorse 启用 TLS 时可用。 指标监听器使用由 gitlab.webservice.workhorse.tls.secretName 指定的相同 TLS 证书。

webservice

启用 TLS 的主要用例是通过 HTTPS 提供加密,抓取 Prometheus 指标 。 因此,TLS 证书应在 Common Name(CN)或 Subject Alternate Name(SAN)中包含 Webservice 主机名(例如:RELEASE-webservice-default.default.svc)。

note与 Chart 捆绑的 Prometheus 服务器尚不支持抓取 HTTPS 端点。

可以通过设置 gitlab.webservice.tls.enabledgitlab.webservice.tls.secretNamewebservice 容器上启用 TLS:

gitlab:
  webservice:
    tls:
      enabled: true
      secretName: gitlab-webservice-tls

secretName 必须指向 Kubernetes TLS secret。 例如,要使用本地证书和密钥创建 TLS 机密:

kubectl create secret tls <secret name> --cert=path/to/puma.crt --key=path/to/puma.key

全局配置

我们在 chart 之间共享一些通用的全局设置。有关详细信息,请参见 Globals 文档

Deployments 设置

此 chart 能够创建多个 Deployment 对象及其相关资源。此功能允许使用基于路径的路由在多组 Pod 之间分发对 GitLab 应用程序的请求。

Map 映射表中的键(本例中为 default)为每个资源的名称。default 包含一个 Deployment、Service、HorizontalPodAutoscaler、PodDisruptionBudget 和使用 RELEASE-webservice-default 创建的可选 Ingress。

任何未提供的属性都将从 gitlab-webservice chart 默认值继承。

deployments:
  default:
    ingress:
      path: # Does not inherit or default. Leave blank to disable Ingress.
      pathType: Prefix
      provider: nginx
      annotations:
        # inherits `ingress.anntoations`
      proxyConnectTimeout: # inherits `ingress.proxyConnectTimeout`
      proxyReadTimeout:    # inherits `ingress.proxyReadTimeout`
      proxyBodySize:       # inherits `ingress.proxyBodySize`
    deployment:
      annotations: # map
      labels: # map
      # inherits `deployment`
    pod:
      labels: # additional labels to .podLabels
      annotations: # map
        # inherit from .Values.annotations
    service:
      labels: # additional labels to .serviceLabels
      annotations: # additional annotations to .service.annotations
        # inherits `service.annotations`
    hpa:
      minReplicas: # defaults to .minReplicas
      maxReplicas: # defaults to .maxReplicas
      metrics: # optional replacement of HPA metrics definition
      # inherits `hpa`
    pdb:
      maxUnavailable: # inherits `maxUnavailable`
    resources: # `resources` for `webservice` container
      # inherits `resources`
    workhorse: # map
      # inherits `workhorse`
    extraEnv: #
      # inherits `extraEnv`
    extraEnvFrom: #
      # inherits `extraEnvFrom`
    puma: # map
      # inherits `puma`
    workerProcesses: # inherits `workerProcesses`
    shutdown:
      # inherits `shutdown`
    nodeSelector: # map
      # inherits `nodeSelector`
    tolerations: # array
      # inherits `tolerations`

Deployments Ingress

每个 deployments 条目都将从 chart 范围的 Ingress 设置 继承。此处提供的任何值都将覆盖 Ingree 设置中提供的值。 在 path 之外,所有设置都与 Ingress 设置相同。

webservice:
  deployments:
    default:
      ingress:
        path: /
   api:
     ingress:
       path: /api

path 属性直接填入到 Ingress 的 path 属性中,并允许控制指向每个服务的 URI 路径。 在上面的例子中,default 作为全域路径,api 接收了 /api 下的所有流量。

您可以通过将 path 设置为空来禁用给定的 Deployment 创建关联的 Ingress 资源。 见下文,其中 internal-api 永远不会接收外部流量。

webservice:
  deployments:
    default:
      ingress:
        path: /
   api:
     ingress:
       path: /api
   internal-api:
     ingress:
       path:

Ingress 设置

名称 类型 默认值 说明
ingress.apiVersion String   apiVersion 字段中使用的值。
ingress.annotations Map 查看下方文档 这些 annotation 将用于每个 Ingress。 例如:ingress.annotations."nginx\.ingress\.kubernetes\.io/enable-access-log"=true
ingress.configureCertmanager Boolean   切换 Ingress annotation cert-manager.io/issuer。有关更多信息,请参阅 GitLab Pages 的 TLS 要求
ingress.enabled Boolean false 控制是否为支持它们的服务创建 Ingress 对象的设置。 当设置为 false 时,使用 global.ingress.enabled 设置值。
ingress.proxyBodySize String 512m 查看下文.
ingress.tls.enabled Boolean true 当设置为false 时,您将禁用 GitLab Web 服务的 TLS。 这主要用于无法在 Ingrss 级别使用 TLS 终止的情况,例如在 Ingress Controller 之前有 TLS 终止代理时。
ingress.tls.secretName String (empty) 包含 GitLab URL 的有效证书和密钥的 Kubernetes TLS Secret 的名称。如果未设置,则使用 global.ingress.tls.secretName 值代替。
ingress.tls.smardcardSecretName String (empty) Kubernetes TLS Secret 的名称,其中包含 GitLab smartcard URL 的有效证书和密钥(如果已启用)。 如果未设置,则使用 global.ingress.tls.secretName 值代替。

annotations

annotations 用于在 Webservice Ingress 上设置 annotation。

我们默认设置了一个注解:nginx.ingress.kubernetes.io/service-upstream: "true"。 通过将 NGINX 作为上游直接联系服务本身,这有助于更均匀地平衡到 Webservice pod 的流量。 有关更多信息,请参阅 NGINX 文档

要覆盖它,请设置:

gitlab:
  webservice:
    ingress:
      annotations:
        nginx.ingress.kubernetes.io/service-upstream: "false"

proxyBodySize

proxyBodySize 用于设置 NGINX 代理的最大 body 大小。这通常是允许比默认值更大的 Docker 镜像所必需的。它相当于 中的 nginx['client_max_body_size'] 配置。作为替代选项,您也可以使用以下两个参数之一设置 body 大小:

  • gitlab.webservice.ingress.annotations."nginx\.ingress\.kubernetes\.io/proxy-body-size"
  • global.ingress.annotations."nginx\.ingress\.kubernetes\.io/proxy-body-size"

资源

内存请求值/限制值

每个 pod 产生的 workers 数量等于 workerProcesses, 每个都使用一些基准内存量,我们推荐:

  • 每个 worker 最小 1.25GB (requests.memory)
  • 每个 worker 最大 1.5GB (limits.memory)

请注意,所需资源取决于用户生成的工作负载,并且将来可能会根据 GitLab 应用程序中的更改或升级而更改。

默认值为:

workerProcesses: 2
resources:
  requests:
    memory: 2.5G # = 2 * 1.25G
# limits:
#   memory: 3G   # = 2 * 1.5G

配置了四个 worker 时:

workerProcesses: 4
resources:
  requests:
    memory: 5G   # = 4 * 1.25G
# limits:
#   memory: 6G   # = 4 * 1.5G

外部服务

Redis

Redis 文档已合并在全局设置 页面中。 请查阅此页面以获取最新的 Redis 配置选项。

PostgreSQL

PostgreSQL 文档已合并在全局设置 页面中。 请查阅此页面以获取最新的 PostgreSQL 配置选项。

Gitaly

Gitaly 由全局设置 配置。 请参阅Gitaly 配置文档

MinIO

minio:
  serviceName: 'minio-svc'
  port: 9000
名称 类型 默认值 说明
port Integer 9000 到达 MinIO Service 的端口号。
serviceName String minio-svc MinIO pod 暴露的 Service 的名称。

Registry

registry:
  host: registry.example.com
  port: 443
  api:
    protocol: http
    host: registry.example.com
    serviceName: registry
    port: 5000
  tokenIssuer: gitlab-issuer
  certificate:
    secret: gitlab-registry
    key: registry-auth.key
名称 类型 默认值 说明
api.host String   使用的 Registry 服务器的主机名。可以省略并以api.serviceName 代替。
api.port Integer 5000 连接到 Registry API 的端口。
api.protocol String   Webservice 用于访问 Registry API 的协议。
api.serviceName String registry The name of the service which is operating the Registry server. If this is present, and api.host is not, the chart will template the hostname of the service (and current .Release.Name) in place of the api.host value. This is convenient when using Registry as a part of the overall GitLab chart.运行 Registry 服务器的 service 的名称。 如果它存在,而 api.host 不存在,chart 将服务的主机名(和当前的 .Release.Name)作为模板代替 api.host 值。 当使用 Registry 作为整个 GitLab chart 的一部分时,这很方便。
certificate.key String   Secret 中的 key 名称,其中包含将作为 auth.token.rootcertbundle 提供给 registry 容器的证书包。
certificate.secret String   Kubernetes Secret 的名称,其中包含用于验证 GitLab 实例创建的令牌的证书包。
host String   用于在 GitLab UI 中向用户提供 Docker 命令的外部主机名。 回退到在registry.hostname 模板中设置的值。 它根据 global.hosts 中设置的值确定注册表主机名。 有关更多信息,请参阅 全局文档
port Integer   主机名中使用的外部端口。 使用端口 80443 将导致 URL 由 http/https 构成。 其他端口都将使用 http 并将端口附加到主机名的末尾,例如 http://registry.example.com:8443
tokenIssuer String gitlab-issuer 身份验证令牌颁发者的名称。 这必须与 Registry 配置中使用的名称相匹配,因为它在发送时已合并到令牌中。gitlab-issuer 的默认值与我们在 Registry 中使用的默认值相同。

Chart 设置

以下值用于配置 Webservice Pods.

名称 类型 默认值 说明
replicaCount Integer 1 要在 deployment 中创建的 Web 服务实例数。
workerProcesses Integer 2 每个 Pod 运行的 Websevice workers 个数。 为了让 GitLab 正常运行,您的集群中必须至少有 2 个可用的 workers。 请注意,增加 workerProcesses 将为每个 worker 增加大约 400MB 所需的内存,因此您应该相应地更新 pod resources

指标

可以使用 metrics.enabled 值启用指标,并使用 GitLab monitoring exporter 公开指标端口。Pod 被赋予 Prometheus 注释,或者如果 metrics.serviceMonitor.enabledtrue,则创建 Prometheus Operator ServiceMonitor。指标也可以从 /-/metrics 端点抓取,但这需要在管理中心启用 GitLab Prometheus 指标。GitLab Workhorse 指标也可以通过 workhorse.metrics.enabled 公开,但无法使用 Prometheus 注释收集这些指标,因此需要 workhorse.metrics.serviceMonitor.enabledtrue 或外部 Prometheus 配置。

GitLab Shell

GitLab Shell 在与 Webservice 的通信中使用 Auth Token。 使用共享 Secret 与 GitLab Shell 和 Webservice 共享令牌。

shell:
  authToken:
    secret: gitlab-shell-secret
    key: secret
  port:
名称 类型 默认值 说明
authToken.key String   定义包含 authToken 的 secret(如下)中的键。
authToken.secret String   定义要拉取的 Kubernetes Secret 的名称。
port Integer 22 在 GitLab UI 中生成 SSH URL 时使用的端口号。 由global.shell.port 控制。

WebServer 选项

当前版本的图表支持 Puma web 服务器。

Puma 的独特选项:

名称 类型 默认值 说明
puma.workerMaxMemory Integer   Puma worker killer 的最大内存(以 MB 为单位)
puma.threads.min Integer 4 最小 Puma 线程数
puma.threads.max Integer 4 最大 Puma 线程数

配置 networkpolicy

此部分控制 NetworkPolicy。此配置是可选的,用于将 Pod 的 Egress 和 Ingress 限制为特定端点。

名称 类型 默认值 说明
enabled Boolean false 该设置启用 NetworkPolicy
ingress.enabled Boolean false 当设置为 trueIngress network policy 将被激活。除非指定规则,否则这将阻止所有 Ingress 连接。
ingress.rules Array [] Ingress 策略规则,详见 https://kubernetes.io/docs/concepts/services-networking/network-policies/#the-networkpolicy-resource 和下面的例子
egress.enabled Boolean false 当设置为 true 时,将激活 Egress 网络策略。 除非指定规则,否则这将阻止所有 egress 连接。
egress.rules Array [] egress 策略规则,这些详细信息参见 https://kubernetes.io/docs/concepts/services-networking/network-policies/#the-networkpolicy-resource 和下面的例子。

Network Policy 示例

当启用了 Prometheus exporter 且流量来自 NGINX Ingress 时,webservice Service 需要 Ingress 连接,并且通常需要到各个地方的 Egress 连接。 此示例添加以下网络策略:

  • 所有来自 TCP 10.0.0.0/8 端口 8080 上的 Ingress 请求都允许用于指标导出和 NGINX Ingress
  • DNS 允许在 UDP 10.0.0.0/8 端口 53 上对网络的所有 Egress 请求
  • PostgreSQL 允许在 TCP 10.0.0.0/8 端口 5432 上向网络发出的所有 Egress 请求
  • Redis 允许通过 TCP 10.0.0.0/8 端口 6379 向网络发出所有 Egress 请求
  • Gitaly 允许在 TCP 10.0.0.0/8 端口 8075 上对网络的所有 Egress 请求
  • 其它对 10.0.0.0/8 本地网络的 Egress 请求受到限制
  • 允许在 10.0.0.0/8 之外的出口请求

请注意,提供的示例仅为示例,可能并不完整

请注意,对于外部对象存储 上的镜像,Web 服务需要与公共 Internet 的出站连接

networkpolicy:
  enabled: true
  ingress:
    enabled: true
    rules:
      - from:
        - ipBlock:
            cidr: 10.0.0.0/8
        ports:
        - port: 8080
  egress:
    enabled: true
    rules:
      - to:
        - ipBlock:
            cidr: 10.0.0.0/8
        ports:
        - port: 53
          protocol: UDP
      - to:
        - ipBlock:
            cidr: 10.0.0.0/8
        ports:
        - port: 5432
          protocol: TCP
      - to:
        - ipBlock:
            cidr: 10.0.0.0/8
        ports:
        - port: 6379
          protocol: TCP
      - to:
        - ipBlock:
            cidr: 10.0.0.0/8
        ports:
        - port: 8075
          protocol: TCP
      - to:
        - ipBlock:
            cidr: 0.0.0.0/0
            except:
            - 10.0.0.0/8

LoadBalancer Service

如果service.type 设置为LoadBalancer,您可以选择指定 service.loadBalancerIP,以创建具有用户指定 IP 的LoadBalancer(如果您的云提供商支持)。

您还可以选择指定 service.loadBalancerSourceRanges 列表,来限制可以访问 LoadBalancer 的 CIDR 范围(如果您的云提供商支持)。

有关 LoadBalancer Service 类型的其它信息可以查看 Kubernetes 文档

service:
  type: LoadBalancer
  loadBalancerIP: 1.2.3.4
  loadBalancerSourceRanges:
  - 10.0.0.0/8