使用 GitLab Webservice Chart

webservice 子 Chart 为 GitLab Rails Web 服务器提供每个 Pod 两个 Webservice 工作进程，这是单个 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 的配置如下：全局设置、 部署设置、Ingress 设置、外部服务 和 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 允许您更改 Deployment 更新策略。它定义了更新 Deployment 时如何重新创建 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

更多详细信息，请参阅 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）。如果设置了 global.clusterDomain，请改用完全限定的 服务主机名。

请注意，可以存在多个 Webservice 部署， 因此您需要为不同的服务名称准备 TLS 证书。这 可以通过多个 SAN 或通配符证书来实现。

生成 TLS 证书后，为其创建一个 Kubernetes TLS Secret。您还需要创建 另一个仅包含 TLS 证书的 CA 证书且带有 ca.crt 键的 Secret。

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

当 gitlab.webservice.workhorse.tls.verify 为 true（默认情况下）时，您 还需要将 CA 证书 Secret 名称传递给 gitlab.webservice.workhorse.tls.caSecretName。 这对于自签名证书和自定义 CA 是必需的。NGINX 使用此 Secret 来验证 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 Chart。更多信息，请参阅 配置 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 Secret。 例如，要使用本地证书和密钥创建 TLS Secret：

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

使用此 Chart 的基础版#

默认情况下，Helm Charts 使用极狐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。

全局设置#

我们在 Charts 之间共享一些通用的全局设置。有关常见配置选项（例如极狐GitLab 和 Registry 主机名），请参阅 全局文档。

部署设置#

此 Chart 能够创建多个 Deployment 对象及其相关 资源。此功能允许使用基于路径的路由将发往极狐GitLab 应用的请求分发到多组 Pod 之间。

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

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

yaml
1deployments:
2  default:
3    ingress:
4      path: # Does not inherit or default. Leave blank to disable Ingress.
5      pathType: Prefix
6      provider: nginx
7      annotations:
8        # inherits `ingress.anntoations`
9      proxyConnectTimeout: # inherits `ingress.proxyConnectTimeout`
10      proxyReadTimeout:    # inherits `ingress.proxyReadTimeout`
11      proxyBodySize:       # inherits `ingress.proxyBodySize`
12    deployment:
13      annotations: # map
14      labels: # map
15      # inherits `deployment`
16    pod:
17      labels: # additional labels to .podLabels
18      annotations: # map
19        # inherit from .Values.annotations
20    service:
21      labels: # additional labels to .serviceLabels
22      annotations: # additional annotations to .service.annotations
23        # inherits `service.annotations`
24    hpa:
25      minReplicas: # defaults to .minReplicas
26      maxReplicas: # defaults to .maxReplicas
27      metrics: # optional replacement of HPA metrics definition
28      # inherits `hpa`
29    pdb:
30      maxUnavailable: # inherits `maxUnavailable`
31    resources: # `resources` for `webservice` container
32      # inherits `resources`
33    workhorse: # map
34      # inherits `workhorse`
35    extraEnv: #
36      # inherits `extraEnv`
37    extraEnvFrom: #
38      # inherits `extraEnvFrom`
39    puma: # map
40      # inherits `puma`
41    workerProcesses: # inherits `workerProcesses`
42    shutdown:
43      # inherits `shutdown`
44    nodeSelector: # map
45      # inherits `nodeSelector`
46    tolerations: # array
47      # inherits `tolerations`
48    priorityClassName: # inherits `priorityClassName`

部署 Ingress#

每个 deployments 条目都将继承 Chart 范围的 Ingress 设置。此处提供的任何值都将覆盖这些设置。除了 path 之外，所有设置都与这些设置相同。

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

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

您可以通过将 path 设置为空来禁用为给定 Deployment 创建关联的 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:

Ingress 设置#

annotations#

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

serviceUpstream#

这通过告诉 NGINX 直接联系 Service 本身作为上游，有助于更均匀地平衡 Webservice Pod 的流量。更多信息，请参阅 NGINX 文档。

要覆盖此设置，请设置：

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"

额外 Ingress#

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

Gateway API#

如果 GitLab Chart 配置为 通过 Gateway API 暴露，则每个 部署都将作为规则添加到 webservice Chart 的 HTTPRoute 中。

您可以通过将部署的 .rules=[] 设置为空来禁用给定部署在 HTTPRoute 中的规则。

yaml
1webservice:
2  deployments:
3    default:
4      gatewayRoute:
5        rules:
6        - matches:
7          - path:
8              type: PathPrefix
9              value: /
10          timeouts:
11            request: "20s"
12            backendRequest: "20s"
13          filters:
14          - type: RequestHeaderModifier
15            requestHeaderModifier:
16              remove:
17              - X-Forwarded-Host
18    api:
19      gatewayRoute:
20        rules:
21        - matches:
22          - path:
23              type: PathPrefix
24              value: /api
25    internal-api:
26      gatewayRoute:
27        rules: []

每条规则支持 matches、timeouts 和 filters。Filters 接受一个 Gateway API HTTPRouteFilter 对象列表。

Gateway 与 Workhorse 之间的 TLS#

当 Workhorse TLS 启用时，您可以为每个 部署配置一个 BackendTLSPolicy，以便 Gateway 验证到每个 Workhorse 后端的 TLS 连接。设置 workhorse.tls.enabled: true 并在部署级别提供 CA Secret：

yaml
1global:
2  workhorse:
3    tls:
4      enabled: true
5gitlab:
6  webservice:
7    workhorse:
8      tls:
9        enabled: true
10        caSecretName: workhorse-tls-ca
11    deployments:
12      api:
13        workhorse:
14          tls:
15            enabled: true
16            caSecretName: workhorse-api-tls-ca

验证主机名默认为服务 DNS 名称（<service-name>.<namespace>.svc，或当设置 global.clusterDomain 时的完全限定名称）。 使用 backendTLSPolicy.hostname 覆盖它：

yaml
gitlab:
  webservice:
    backendTLSPolicy:
      hostname: workhorse.example.internal

验证 caCertificateRefs 默认为 kind: Secret 的对象。Secret 和 ConfigMap 均受支持。 使用 backendTLSPolicy.kind 覆盖它：

yaml
gitlab:
  webservice:
    backendTLSPolicy:
      kind: ConfigMap

有关完整详细信息，请参阅 Gateway API 文档。

自定义 ClientTrafficPolicy#

当使用 Envoy Gateway 时，Chart 会为 main（gitlab-web）、geo（gitlab-web-geo）和 smartcard（gitlab-smartcard-web） 监听器渲染作用域限定的 ClientTrafficPolicies。这些策略优先于 Webservice 监听器的网关范围 gatewayApiResources.envoy.clientTrafficPolicySpec。

要为监听器自定义策略，请在 clientTrafficPolicy.<variant>.spec 下设置其规范：

yaml
1gitlab:
2  webservice:
3    clientTrafficPolicy:
4      main:
5        spec:
6          path:
7            escapedSlashesAction: KeepUnchanged
8          enableProxyProtocol: true

当您省略 spec.targetRefs 时，Chart 会注入匹配的 Gateway 监听器，因此您只需 设置要更改的字段。这恢复了为 Webservice 监听器配置 ClientTrafficPolicy 行为的能力。更多信息，请参阅 议题 6571。

Envoy Gateway 的 HTTP/2 流控窗口默认值为：

• 流为 64 KiB。
• 连接为 1 MiB。

单个 HTTP/2 流受 initialStreamWindowSize / RTT 限制， 因此 64 KiB 的默认值在约 200 毫秒往返时间内将单个流限制为大约 300 KiB/s。

这些默认值尤其影响极狐GitLab Geo，其中辅助 站点通过高延迟站点间链路将 git 请求作为单个 HTTP/2 请求代理到主站点。

因此，main 和 geo 策略提高了这些默认值：

• http2.initialStreamWindowSize: 8Mi
• http2.initialConnectionWindowSize: 16Mi

您可以按上述方式为每个监听器覆盖这些值。在 spec 中覆盖一个键 会保留其他默认值，因为 Helm 会合并映射。

更多信息，请参阅 议题 6582。

Gateway 超时#

当使用 Envoy Gateway 时，Chart 会渲染一个 BackendTrafficPolicy ，目标是 Webservice HTTPRoute，并具有以下默认超时：

streamIdleTimeout 是一个不活动超时：只要数据在任一方向流动，它就会重置，因此长时间运行的下载、上传和 WebSocket 连接在流量流动时不会中断，只有真正空闲的流 才会被回收。绝对 HTTPRoute 超时默认保持禁用（0s），因为绝对截止时间会终止合法的长时间运行的传输，无论其活动状态如何。

如果您要从 NGINX Ingress 迁移，请参阅 这些设置如何映射到 NGINX Ingress 超时选项。

要更改默认值，请在 backendTrafficPolicy.spec 下整体覆盖规范。例如，要使用更严格的值：

yaml
1gitlab:
2  webservice:
3    backendTrafficPolicy:
4      spec:
5        timeout:
6          tcp:
7            connectTimeout: 15s
8          http:
9            streamIdleTimeout: 600s

当您省略 spec.targetRefs 时，Chart 会注入 Webservice HTTPRoute。设置 backendTrafficPolicy.spec: null 以跳过渲染策略。

Gateway 不强制执行请求体大小限制：Envoy 流式传输请求 体没有大小上限，大小限制由极狐GitLab 本身强制执行 （例如，max_attachment_size、LFS 和产物限制）。

资源#

内存请求/限制#

每个 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

紧密打包或整合环境#

在使用激进装箱或节点整合的 Kubernetes 环境中 （例如，由启用了整合功能的 Karpenter 管理的 EKS 集群），节点 根据 Pod 请求（而非限制）进行配置和整合。当 limits.memory 高于 requests.memory 时，紧密打包的节点可能会耗尽内存，因为 Webservice Pod 使用的内存超出了其请求量，导致内存不足（OOM） 终止。这些 OOM 终止表现为间歇性 502 错误。

因此，AWS Karpenter 最佳实践建议 在使用整合功能时，将所有非 CPU 资源的请求设置为等于限制。

在这些环境中，对于四个工作进程：

• 将 requests.memory 设置为等于 limits.memory，并留出额外空间： 9GB 而不是标准的 7GB。
• 启用 Puma Worker Killer 以便在 Pod 达到其内存限制之前优雅地重启过大的工作进程。这可以防止导致 502 错误的 OOM 终止。

yaml
1workerProcesses: 4
2resources:
3  requests:
4    memory: 9G # equal to limits, per Karpenter consolidation best practice
5  limits:
6    memory: 9G
7puma:
8  disableWorkerKiller: false
9  workerMaxMemory: 1500 # MB per worker (~6GB total for 4 workers), matches the current default

## 外部服务 {#external-services}

Redis#

Redis 文档已整合到 globals 页面中。请查阅该页面以获取最新的 Redis 配置选项。

PostgreSQL#

PostgreSQL 文档已整合到 globals 页面中。请查阅该页面以获取最新的 PostgreSQL 配置选项。

Webservice 部署中的 dependencies initContainer 会运行脚本来检查：

• 极狐GitLab 的依赖项是否可用。
• PostgreSQL 的数据库迁移是否已执行。

您可以使用 Webservice chart 的 extraEnv 配置键来控制这些脚本的行为。支持两个环境变量：

• BYPASS_POST_DEPLOYMENT=true：如果所有常规迁移都已执行，且仅有部署后迁移待处理，则依赖项检查通过。
• BYPASS_SCHEMA_VERSION=true（不推荐）：即使常规迁移尚未执行，依赖项检查也会通过。使用此环境变量可能导致 Rails 部署在启动后出错，因为数据库模式与应用程序代码的预期不匹配。

Gitaly#

yaml
1global:
2  gitaly:
3    ## These settings are used by Gitaly clients: GitLab Rails, GitLab Shell, Workhorse.
4    client:
5      maxAttempts: 4
6      maxBackoff: '1.4s'

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

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

指标#

可以使用 metrics.enabled 值启用指标，并使用极狐GitLab 监控导出器来暴露指标端口。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 通信时使用认证令牌。请使用共享的 Secret 与 GitLab Shell 和 Webservice 共享该令牌。

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

WebServer 选项#

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

Puma 特有选项：

Workhorse 负载削减#

负载削减通过返回配置的 HTTP 状态码来保护 Puma 免受过载影响，当请求积压超过配置的阈值时，允许反向代理将请求重试到其他实例。

要启用负载削减，请配置 loadShedding 参数：

yaml
1gitlab:
2  webservice:
3    workhorse:
4      loadShedding:
5        enabled: true
6        backlogThreshold: 50
7        retryAfterSeconds: 0
8        statusCode: 503
9        strategy: max

• backlogThreshold 指定触发负载削减的积压请求数。
• retryAfterSeconds 设置响应中 Retry-After 头的值。
• statusCode 设置在削减负载时返回的 HTTP 状态码（默认值：503）。使用自定义代码（如 529）可以将负载削减响应与由数据库超时或 Gitaly 问题引起的其他 503 错误区分开来。
• strategy 决定有效积压的计算方式：
  • max：使用所有 Puma worker 中的最大积压（默认）。
  • sum：使用所有 Puma worker 的积压总和。

代理配置#

为使负载削减有效工作，您的反向代理必须配置为在收到 503 响应时重试请求。这可以确保请求被分发到健康的实例。

有关 NGINX 示例，请在 Ingress 上配置以下注解：

yaml
ingress:
  annotations:
    nginx.ingress.kubernetes.io/proxy-next-upstream: "http_503"
    nginx.ingress.kubernetes.io/proxy-next-upstream-tries: "3"
    nginx.ingress.kubernetes.io/proxy-next-upstream-timeout: "10s"

这些设置告诉 NGINX：

• 在 503 响应时重试（负载削减会生成此响应）。
• 在放弃前最多尝试 3 次。
• 重试最多等待 10 秒。

您只应在 503 响应时重试，这是负载削减生成的特定信号。 避免在其他状态码（如 504（网关超时））或错误条件下重试，因为这会通过在中断期间重试可能在后端全部失败的请求来放大负载。

对于其他反向代理，请查阅其文档以了解等效的重试配置。关键是确保 503 响应会触发对其他后端实例的重试。

配置 networkpolicy#

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

网络策略示例#

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

• 允许 Ingress 请求：
  • 从 gitaly、gitlab-pages、gitlab-shell、kas、mailroom 和 nginx-ingress Pod 到端口 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。

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