• 要求
• 配置
• 安装命令行选项
• Chart 配置示例
  • extraEnv
  • extraEnvFrom
  • image.pullSecrets
  • tolerations
  • annotations
  • strategy
  • TLS
    • gitlab-workhorse
    • webservice
• 全局配置
• Deployments 设置
  • Deployments Ingress
• Ingress 设置
  • annotations
  • proxyBodySize
  • 额外 Ingress
• 资源
  • 内存请求值/限制值
• 外部服务
  • Redis
  • PostgreSQL
  • Gitaly
  • MinIO
  • Registry
• Chart 设置
  • 指标
  • 极狐GitLab Shell
  • WebServer 选项
• 配置 networkpolicy
  • Network Policy 示例
  • LoadBalancer Service
• 配置 KEDA

使用 GitLab Webservice Chart

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

此 chart 的 pod 使用两个容器：gitlab-workhorse 和 webservice。极狐GitLab Workhorse 侦听端口 8181，并且应该始终是到 pod 的入站流量的目的地。 webservice 包含极狐GitLab Rails 代码库，在 8080 上侦听，并可用于指标收集目的。webservice 不应该直接接收正常流量。

要求

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

配置

webservice chart 配置如下：全局配置、deployment 设置、Ingress 设置、外部服务和 chart 设置。

安装命令行选项

下表包含可以使用 --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
deployments:
  default:
    extraEnvFrom:
      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-ingress、gitlab-shell 和 gitaly。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.secretName 和 global.certificates.customCAs 来为 gitlab-workhorse 容器启用 TLS。 相应的证书.customCAs`。

当 gitlab.webservice.workhorse.tls.verify 为 true（默认）时，还需要将 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
        secretName: gitlab-workhorse-tls
        caSecretName: gitlab-workhorse-ca
      monitoring:
        exporter:
          enabled: true
          tls:
            enabled: true

gitlab-workhorse 容器的指标端点上的 TLS 继承自 global.workhorse.tls.enabled。请注意，指标端点上的 TLS 仅在为 Workhorse 启用 TLS 时可用。指标侦听器使用由 gitlab.webservice.workhorse.tls.secretName 指定的相同 TLS 证书。

用于指标端点的 TLS 证书可能需要对包含的主题备用名称 (SAN) 的额外关注，尤其是在使用包含的 Prometheus Helm chart时。有关更多信息，请参阅配置 Prometheus 并抓取启用 TLS 的端点。

webservice

启用 TLS 的主要用例是通过 HTTPS 提供加密，抓取 Prometheus 指标。

为了让 Prometheus 使用 HTTPS 抓取 /metrics/ 端点，需要对证书的 CommonName 属性或 SubjectAlternativeName 条目进行额外配置。 有关这些要求，请参阅配置 Prometheus 以抓取启用 TLS 的端点。

可以通过设置 gitlab.webservice.tls.enabled 和 gitlab.webservice.tls.secretName 在 webservice 容器上启用 TLS：

gitlab:
  webservice:
    tls:
      enabled: true
      secretName: gitlab-webservice-tls
      # 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:

</a

Ingress 设置

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 镜像所必需的。它相当于 Linux 软件包安装中的 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"

额外 Ingress

可以通过设置 extraIngress.enabled=true 来部署额外的 Ingress。Ingress 以 -extra 后缀命名为默认 Ingress，并支持与默认 Ingress 相同的设置。

资源

内存请求值/限制值

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

• 每个 worker 最小 1.25GB (requests.memory)
• 每个 worker 最大 1.5GB (limits.memory)，加上 1GB 用于主节点 (limits.memory)

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

默认值为：

workerProcesses: 2
resources:
  requests:
    memory: 2.5G # = 2 * 1.25G
# limits:
#   memory: 4G   # = (2 * 1.5G) + 950M

配置了四个 worker 时：

workerProcesses: 4
resources:
  requests:
    memory: 5G   # = 4 * 1.25G
# limits:
#   memory: 7G   # = (4 * 1.5G) + 950M

外部服务

Redis

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

PostgreSQL

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

Gitaly

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

MinIO

minio:
  serviceName: 'minio-svc'
  port: 9000

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

Chart 设置

以下值用于配置 Webservice Pods.

指标

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

极狐GitLab Shell

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

shell:
  authToken:
    secret: gitlab-shell-secret
    key: secret
  port:

WebServer 选项

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

Puma 的独特选项：

配置 networkpolicy

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

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

配置 KEDA

keda 部分允许安装 KEDA ScaledObjects，而不是常规的 HorizontalPodAutoscalers。 此配置是可选的，可以在需要根据自定义或外部指标进行自动缩放时使用。

大多数设置默认为 hpa 部分中适用的值。

如果满足以下条件，则会根据 hpa 部分中设置的 CPU 和内存阈值自动添加 CPU 和内存触发器：

• 未设置 triggers。
• 相应的 request.cpu.request 或 request.memory.request 也设置为非零值。

如果未设置触发器，则不会创建 ScaledObject。

有关这些设置的更多详细信息，请参阅 KEDA 文档。