使用极狐GitLab Webservice chart

webservice 子图为极狐GitLab Rails 网络服务器提供了每个 pod 两个 Webservice 工作线程，这是极狐GitLab 中单个 pod 能够处理任何 Web 请求所需的最小值。

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

要求#

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

配置#

webservice 图的配置如下：全局设置，部署设置，入口设置，外部服务，和 chart 设置。

安装命令行选项#

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

chart 配置示例#

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
14deployments:
15  default:
16    extraEnvFrom:
17      CONFIG_STRING:
18        configMapKeyRef:
19          name: useful-config
20          key: some-string
21          # optional: boolean

image.pullSecrets#

pullSecrets 允许您对私有注册表进行身份验证以拉取 pod 的镜像。

有关私有注册表及其身份验证方法的更多详细信息，请参阅 Kubernetes 文档。

以下是 pullSecrets 的使用示例：

yaml
1image:
2  repository: my.webservice.repository
3  pullPolicy: Always
4  pullSecrets:
5  - name: my-secret-name
6  - 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"

annotations#

annotations 允许您向 Webservice pod 添加注释。例如：

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

strategy#

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

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

您还可以将更新策略类型更改为 Recreate，但请注意，它会在调度新 pod 之前杀死所有 pod，并且直到新 pod 启动，Web UI 将不可用。在这种情况下，您不需要定义 rollingUpdate，只需定义 type：

yaml
deployment:
  strategy:
    type: Recreate

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 密钥。您还需要创建另一个仅包含 TLS 证书 CA 证书的密钥，并使用 ca.crt 密钥。

通过将 global.workhorse.tls.enabled 设置为 true，可以为 gitlab-workhorse 容器启用 TLS。您可以相应地将自定义密钥名称传递给 gitlab.webservice.workhorse.tls.secretName 和 global.certificates.customCAs。

当 gitlab.webservice.workhorse.tls.verify 为 true（默认情况下是），您还需要将 CA 证书密钥名称传递给 gitlab.webservice.workhorse.tls.caSecretName。这对于自签名证书和自定义 CA 是必要的。此密钥由 NGINX 用于验证 Workhorse 的 TLS 证书。

yaml
1global:
2  workhorse:
3    tls:
4      enabled: true
5  certificates:
6    customCAs:
7      - secret: gitlab-workhorse-ca
8gitlab:
9  webservice:
10    workhorse:
11      tls:
12        verify: true
13        # secretName: gitlab-workhorse-tls
14        caSecretName: gitlab-workhorse-ca
15      monitoring:
16        exporter:
17          enabled: true
18          tls:
19            enabled: true

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

用于指标端点的 TLS 证书可能需要对所包含的主题备用名称（SAN）进行额外的考虑，特别是如果使用包含的 Prometheus Helm 图。有关更多信息，请参阅 配置 Prometheus 抓取 TLS 启用的端点。

webservice#

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

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

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

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

secretName 必须指向一个 Kubernetes TLS 密钥。例如，要使用本地证书和密钥创建 TLS 密钥：

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

使用此 chart 的基础版#

默认情况下，Helm chart 使用极狐GitLab 企业版。如果需要，您可以使用基础版。了解有关两者之间 差异 的更多信息。

为了使用基础版，将 image.repository 设置为 registry.gitlab.com/gitlab-org/build/cng/gitlab-webservice-ce 并将 workhorse.image 设置为 registry.gitlab.com/gitlab-org/build/cng/gitlab-workhorse-ce。

全局设置#

我们在 chart 之间共享一些通用的全局设置。请参阅 全局文档 以获取有关常见配置选项的更多信息，例如极狐GitLab 和 Registry 主机名。

部署设置#

此 chart 可以创建多个部署对象及其相关资源。此功能允许通过基于路径的路由将请求分配到极狐GitLab 应用程序的多个 Pod 集。

此 Map 的键（此示例中的 default）是每个的“名称”。default 将有一个 Deployment、Service、HorizontalPodAutoscaler、PodDisruptionBudget 和可选的 Ingress 使用 RELEASE-webservice-default 创建。

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

yaml
1deployments:
2  default:
3    ingress:
4      path: # 不继承或默认。留空以禁用 Ingress。
5      pathType: Prefix
6      provider: nginx
7      annotations:
8        # 继承 `ingress.anntoations`
9      proxyConnectTimeout: # 继承 `ingress.proxyConnectTimeout`
10      proxyReadTimeout:    # 继承 `ingress.proxyReadTimeout`
11      proxyBodySize:       # 继承 `ingress.proxyBodySize`
12    deployment:
13      annotations: # map
14      labels: # map
15      # 继承 `deployment`
16    pod:
17      labels: # 附加标签到 .podLabels
18      annotations: # map
19        # 从 .Values.annotations 继承
20    service:
21      labels: # 附加标签到 .serviceLabels
22      annotations: # 附加注释到 .service.annotations
23        # 继承 `service.annotations`
24    hpa:
25      minReplicas: # 默认为 .minReplicas
26      maxReplicas: # 默认为 .maxReplicas
27      metrics: # 可选替换 HPA 指标定义
28      # 继承 `hpa`
29    pdb:
30      maxUnavailable: # 继承 `maxUnavailable`
31    resources: # `webservice` 容器的 `resources`
32      # 继承 `resources`
33    workhorse: # map
34      # 继承 `workhorse`
35    extraEnv: #
36      # 继承 `extraEnv`
37    extraEnvFrom: #
38      # 继承 `extraEnvFrom`
39    puma: # map
40      # 继承 `puma`
41    workerProcesses: # 继承 `workerProcesses`
42    shutdown:
43      # 继承 `shutdown`
44    nodeSelector: # map
45      # 继承 `nodeSelector`
46    tolerations: # array
47      # 继承 `tolerations`

部署入口#

每个 deployments 条目将继承来自 chart 范围的 入口设置。此处提供的任何值将覆盖那些提供的值。除了 path，所有设置都与此相同。

yaml
1webservice:
2  deployments:
3    default:
4      ingress:
5        path: /
6   api:
7     ingress:
8       path: /api

path 属性直接填充到 Ingress 的 path 属性中，允许控制将 URI 路径定向到每个服务。在上面的示例中，default 充当兜底路径，api 接收 /api 下的所有流量

您可以通过将 path 设置为空来禁用为给定部署创建相关 Ingress 资源。请参阅下面的示例，其中 internal-api 永远不会接收外部流量。

yaml
1webservice:
2  deployments:
3    default:
4      ingress:
5        path: /
6   api:
7     ingress:
8       path: /api
9   internal-api:
10     ingress:
11       path:

入口设置#

annotations#

annotations 用于在 Webservice Ingress 上设置注释。

serviceUpstream#

这有助于通过告诉 NGINX 直接联系服务本身作为上游来更均匀地平衡 Webservice pod 的流量。

要覆盖此项，请设置：

yaml
gitlab:
  webservice:
    ingress:
      serviceUpstream: "false"

proxyBodySize#

proxyBodySize 用于设置 NGINX 代理的最大主体大小。这通常需要允许比默认值更大的 Docker 镜像。相当于 Linux 包安装 中的 nginx['client_max_body_size'] 配置。作为替代选项，您也可以使用以下两个参数之一设置主体大小：

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

额外入口#

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

资源#

内存请求/限制#

每个 pod 生成的工作线程数量等于 workerProcesses，每个线程使用一定的基线内存。我们建议：

• 每个工作线程至少 1.25GB 内存（requests.memory）
• 每个工作线程最多 1.5GB 内存，加上主线程 1GB 内存（limits.memory）

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

默认：

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

配置 4 个工作线程：

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

外部服务#

Redis#

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

PostgreSQL#

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

Gitaly#

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

MinIO#

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

Registry#

yaml
1registry:
2  host: registry.example.com
3  port: 443
4  api:
5    protocol: http
6    host: registry.example.com
7    serviceName: registry
8    port: 5000
9  tokenIssuer: gitlab-issuer
10  certificate:
11    secret: gitlab-registry
12    key: registry-auth.key

Chart 设置#

以下值用于配置 Webservice Pods。

指标#

可以通过 metrics.enabled 值启用指标，并使用极狐GitLab 监控导出器来暴露一个指标端口。Pods 将被赋予 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 共享该令牌。

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

WebServer 选项#

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

Puma 独特选项：

配置 networkpolicy#

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

示例网络策略#

如果启用了 Prometheus 导出器，webservice 服务需要来自 NGINX Ingress 和多个极狐GitLab pods 的 Ingress 连接。通常，它需要到各个位置的 Egress 连接。此示例添加了以下网络策略：

• 允许的 Ingress 请求：
  • 来自 pods gitaly、gitlab-pages、gitlab-shell、kas、mailroom 和 nginx-ingress 到端口 8181
  • 来自 Prometheus pod 到端口 8080、8083 和 9229
• 允许的 Egress 请求：
  • 到 gitaly pod 到端口 8075
  • 到 kas pod 到端口 8153
  • 到 kube-dns 到端口 53
  • 到 registry pod 到端口 5000
  • 到外部数据库 172.16.0.10/32 到端口 5432
  • 到外部 Redis 172.16.0.11/32 到端口 6379
  • 到互联网 0.0.0.0/0 到端口 443
  • 到像 AWS VPC 端点用于 S3 或 STS 172.16.1.0/24 到端口 443

注意提供的示例仅是一个示例，可能并不完整

注意 Webservice 需要到公网的出站连接以便在外部对象存储上获取图像

该示例基于以下假设：kube-dns 部署到命名空间 kube-system，prometheus 部署到命名空间 monitoring，nginx-ingress 部署到命名空间 nginx-ingress。

yaml
1networkpolicy:
2  enabled: true
3  ingress:
4    enabled: true
5    rules:
6      - from:
7          - podSelector:
8              matchLabels:
9                app: gitaly
10        ports:
11          - port: 8181
12      - from:
13          - podSelector:
14              matchLabels:
15                app: gitlab-pages
16        ports:
17          - port: 8181
18      - from:
19          - podSelector:
20              matchLabels:
21                app: gitlab-shell
22        ports:
23          - port: 8181
24      - from:
25          - podSelector:
26              matchLabels:
27                app: kas
28        ports:
29          - port: 8181
30      - from:
31          - podSelector:
32              matchLabels:
33                app: mailroom
34        ports:
35          - port: 8181
36      - from:
37          - namespaceSelector:
38              matchLabels:
39                kubernetes.io/metadata.name: nginx-ingress
40            podSelector:
41              matchLabels:
42                app: nginx-ingress
43                component: controller
44        ports:
45          - port: 8181
46      - from:
47          - namespaceSelector:
48              matchLabels:
49                kubernetes.io/metadata.name: monitoring
50            podSelector:
51              matchLabels:
52                app: prometheus
53                component: server
54                release: gitlab
55        ports:
56          - port: 9229
57          - port: 8080
58          - port: 8083
59  egress:
60    enabled: true
61    rules:
62      - to:
63          - podSelector:
64              matchLabels:
65                app: gitaly
66        ports:
67          - port: 8075
68      - to:
69          - podSelector:
70              matchLabels:
71                app: kas
72        ports:
73          - port: 8153
74      - to:
75          - ipBlock:
76              cidr: 0.0.0.0/0
77              except:
78                - 10.0.0.0/8
79        ports:
80          - port: 443
81      - to:
82          - ipBlock:
83              cidr: 172.16.0.10/32
84        ports:
85          - port: 5432
86      - to:
87          - ipBlock:
88              cidr: 172.16.0.11/32
89        ports:
90          - port: 6379
91      - to:
92          - namespaceSelector:
93              matchLabels:
94                kubernetes.io/metadata.name: kube-system
95            podSelector:
96              matchLabels:
97                k8s-app: kube-dns
98        ports:
99          - port: 53
100            protocol: UDP

LoadBalancer 服务#

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

当 service.type 设置为 LoadBalancer 时，您还必须设置 service.loadBalancerSourceRanges 来限制可以访问 LoadBalancer 的 CIDR 范围（如果您的云提供商支持）。

有关 LoadBalancer 服务类型的更多信息，请参见 Kubernetes 文档

yaml
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。