使用极狐GitLab-Sidekiq chart

sidekiq 子chart 提供了可配置的 Sidekiq 工作进程部署，明确设计用于在多个 Deployment 中提供队列分离，具有单独的可扩展性和配置。

虽然此chart 提供了默认的 pods: 声明，但如果您提供一个空定义，则不会有任何工作进程。

要求#

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

设计选择#

此chart 创建多个 Deployment 和相关的 ConfigMap。我们决定使用 ConfigMap 行为而不是使用 environment 属性或为容器的 command 添加额外的参数，以避免关于命令长度的任何顾虑。这个选择导致了大量的 ConfigMap，但提供了关于每个 pod 应该做什么的非常清晰的定义。

配置#

sidekiq chart 分为三个部分进行配置：全chart 范围的外部服务，全chart 范围的默认值，和每个 pod 的定义。

安装命令行选项#

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

chart 配置示例#

资源#

resources 允许您配置 Sidekiq pod 可以消耗的最小和最大资源量（内存和 CPU）。

Sidekiq pod 工作负载在不同的部署之间差异很大。通常，理解为每个 Sidekiq 进程消耗大约 1 个 vCPU 和 2 GB 内存。垂直扩展通常应与此 1:2 的 vCPU:Memory 比例一致。

以下是 resources 的示例用法：

yaml
1resources:
2  limits:
3    memory: 5G
4  requests:
5    memory: 2G
6    cpu: 900m

extraEnv#

extraEnv 允许您在依赖容器中公开其他环境变量。

以下是 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

您还可以为特定的 pod 设置 extraEnv：

yaml
1extraEnv:
2  SOME_KEY: some_value
3  SOME_OTHER_KEY: some_other_value
4pods:
5  - name: mailers
6    queues: mailers
7    extraEnv:
8      SOME_POD_KEY: some_pod_value
9  - name: catchall

这将仅为 mailers pod 中的应用程序容器设置 SOME_POD_KEY。Pod 级别的 extraEnv 设置不会添加到初始化容器中。

extraEnvFrom#

extraEnvFrom 允许您在 pod 中的所有容器中公开来自其他数据源的额外环境变量。后续变量可以在每个 Sidekiq 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
14pods:
15  - name: immediate
16    extraEnvFrom:
17      CONFIG_STRING:
18        configMapKeyRef:
19          name: useful-config
20          key: some-string
21          # optional: boolean

extraVolumes#

extraVolumes 允许您在全chart 范围内配置额外卷。

以下是 extraVolumes 的示例用法：

yaml
extraVolumes: |
  - name: example-volume
    persistentVolumeClaim:
      claimName: example-pvc

extraVolumeMounts#

extraVolumeMounts 允许您在全chart 范围内为所有容器配置额外的卷挂载。

以下是 extraVolumeMounts 的示例用法：

yaml
extraVolumeMounts: |
  - name: example-volume-mount
    mountPath: /etc/example

image.pullSecrets#

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

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

以下是 pullSecrets 的示例用法：

yaml
1image:
2  repository: my.sidekiq.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 允许您向 Sidekiq pods 添加注释。

以下是 annotations 的示例用法：

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

使用此 chart 的基础版#

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

要使用基础版，请将 image.repository 设置为 registry.gitlab.com/gitlab-org/build/cng/gitlab-sidekiq-ce。

外部服务#

此chart 应附加到与 Webservice chart 相同的 Redis、PostgreSQL 和 Gitaly 实例。外部服务的值将被填充到一个 ConfigMap 中，该 ConfigMap 在所有 Sidekiq pods 中共享。

Redis#

yaml
1redis:
2  host: rank-racoon-redis
3  port: 6379
4  sentinels:
5    - host: sentinel1.example.com
6      port: 26379
7  password:
8    secret: gitlab-redis
9    key: redis-password

PostgreSQL#

yaml
1psql:
2  host: rank-racoon-psql
3  serviceName: pgbouncer
4  port: 5432
5  database: gitlabhq_production
6  username: gitlab
7  preparedStatements: false
8  password:
9    secret: gitlab-postgres
10    key: psql-password

Gitaly#

YAML
1gitaly:
2  internal:
3    names:
4      - default
5      - default2
6  external:
7    - name: node1
8      hostname: node1.example.com
9      port: 8079
10  authToken:
11    secret: gitaly-secret
12    key: token

指标#

默认情况下，每个 pod 都启用了 Prometheus 指标导出器。仅当在管理区域启用了极狐GitLab Prometheus 指标时，指标才可用。导出器在端口 3807 上公开一个 /metrics 端点。当启用指标时，会向每个 pod 添加注释，允许 Prometheus 服务器发现和抓取公开的指标。

全chart 范围的默认值#

在未按 pod 提供值的情况下，将使用以下值在全chart 范围内。

每个 pod 的设置#

pods 声明提供了对工作进程 pod 的所有属性的声明。这些将被模板化为 Deployment，并为其 Sidekiq 实例创建单独的 ConfigMap。

队列#

queues 值是一个包含要处理的队列的逗号分隔列表的字符串。默认情况下，它未设置，这意味着将处理所有队列。

字符串不应包含空格：merge,post_receive,process_commit 将起作用，但 merge, post_receive, process_commit 将不起作用。

任何添加作业但未表示为至少一个 pod 项的一部分的队列将不会被处理。有关所有队列的完整列表，请参阅极狐GitLab 源代码中的这些文件：

1. app/workers/all_queues.yml
2. ee/app/workers/all_queues.yml

除了配置 gitlab.sidekiq.pods[].queues，您还必须配置 global.appConfig.sidekiq.routingRules。有关更多信息，请参阅Sidekiq 路由规则设置。

示例 pod 条目#

YAML
1pods:
2  - name: immediate
3    concurrency: 10
4    minReplicas: 2  # 默认为继承值
5    maxReplicas: 10 # 默认为继承值
6    maxUnavailable: 5 # 默认为继承值
7    queues: merge,post_receive,process_commit
8    extraVolumeMounts: |
9      - name: example-volume-mount
10        mountPath: /etc/example
11    extraVolumes: |
12      - name: example-volume
13        persistentVolumeClaim:
14          claimName: example-pvc
15    resources:
16      limits:
17        cpu: 800m
18        memory: 2Gi
19    hpa:
20      cpu:
21        targetType: Value
22        targetAverageValue: 350m

Sidekiq 配置的完整示例#

以下是使用单独的 Sidekiq pod 进行导入相关作业的 Sidekiq 配置的完整示例，使用单独的 Redis 实例进行导出相关作业的 Sidekiq pod，以及用于其他所有内容的另一个 pod。

yaml
1...
2global:
3  appConfig:
4    sidekiq:
5      routingRules:
6      - ["feature_category=importers", "import"]
7      - ["feature_category=exporters", "export", "queues_shard_extra_shard"]
8      - ["*", "default"]
9  redis:
10    redisYmlOverride:
11      queues_shard_extra_shard: ...
12...
13gitlab:
14  sidekiq:
15    pods:
16    - name: import
17      queues: import
18    - name: export
19      queues: export
20      extraEnv:
21        SIDEKIQ_SHARD_NAME: queues_shard_extra_shard # 与 global.redis.redisYmlOverride 中的键匹配
22    - name: default
23...

配置 networkpolicy#

此部分控制 NetworkPolicy。此配置是可选的，用于限制 Pod 到特定端点的出站和入站。

示例网络策略#

Sidekiq 服务仅需要 Prometheus 导出器的入站连接（如果已启用），并且通常需要到各种地方的出站连接。此示例添加了以下网络策略：

• 允许入站请求：
  • 从 Prometheus pod 到端口 3807
• 允许出站请求：
  • 到 kube-dns 到端口 53
  • 到 gitaly pod 到端口 8075
  • 到 registry pod 到端口 5000
  • 到 kas pod 到端口 8153
  • 到外部数据库 172.16.0.10/32 到端口 5432
  • 到外部 Redis 172.16.0.11/32 到端口 6379
  • 到外部 Elasticsearch 172.16.0.12/32 到端口 443
  • 到邮件网关 172.16.0.13/32 到端口 587
  • 到端点，如 S3 或 STS 的 AWS VPC 端点 172.16.1.0/24 到端口 443
  • 到内部子网 172.16.2.0/24 到端口 443 用于发送 webhooks

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

该示例基于以下假设：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          - namespaceSelector:
8              matchLabels:
9                kubernetes.io/metadata.name: monitoring
10            podSelector:
11              matchLabels:
12                app: prometheus
13                component: server
14                release: gitlab
15        ports:
16          - port: 3807
17  egress:
18    enabled: true
19    rules:
20      - to:
21          - podSelector:
22              matchLabels:
23                app: gitaly
24        ports:
25          - port: 8075
26      - to:
27          - podSelector:
28              matchLabels:
29                app: kas
30        ports:
31          - port: 8153
32      - to:
33          - namespaceSelector:
34              matchLabels:
35                kubernetes.io/metadata.name: kube-system
36            podSelector:
37              matchLabels:
38                k8s-app: kube-dns
39        ports:
40          - port: 53
41            protocol: UDP
42      - to:
43          - ipBlock:
44              cidr: 172.16.0.10/32
45        ports:
46          - port: 5432
47      - to:
48          - ipBlock:
49              cidr: 172.16.0.11/32
50        ports:
51          - port: 6379
52      - to:
53          - ipBlock:
54              cidr: 172.16.0.12/32
55        ports:
56          - port: 25
57      - to:
58          - ipBlock:
59              cidr: 172.16.0.13/32
60        ports:
61          - port: 443
62      - to:
63          - ipBlock:
64              cidr: 172.16.1.0/24
65        ports:
66          - port: 443
67      - to:
68          - ipBlock:
69              cidr: 172.16.2.0/24
70        ports:
71          - port: 443

配置 KEDA#

此 keda 部分启用 KEDA ScaledObjects 的安装，而不是常规的 HorizontalPodAutoscalers。此配置是可选的，当需要基于自定义或外部指标进行自动扩展时可以使用。

大多数设置默认情况下与 hpa 部分中设置的值相同（如果适用）。

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

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

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