GitLab-Sidekiqチャートの使用

sidekiqサブチャートは、Sidekiqワーカーの構成可能なデプロイを提供し、個別のスケーラビリティと構成を備えた複数のDeploymentにわたるキューの分離を提供するように明示的に設計されています。

このチャートはデフォルトのpods:宣言を提供しますが、空の定義を提供すると、ワーカーはいません。

要件

このチャートは、Redis、PostgreSQL、およびGitalyサービスへのアクセスに依存します。GitLabチャート全体の一部として、またはこのチャートがデプロイされているKubernetesクラスターから到達可能な外部サービスとして提供されます。

設計の選択肢

このチャートは、複数のDeploymentと関連するConfigMapを作成します。コマンドの長さに関する懸念を避けるため、environment属性やコンテナのcommandへの追加の引数を使用するよりも、ConfigMapの動作を利用する方が明確になります。この選択により、多数のConfigMapが生成されますが、各ポッドが何をすべきかについて非常に明確な定義が提供されます。

設定

このsidekiqチャートは、チャート全体の外部サービス 、チャート全体のデフォルト 、およびポッドごとの定義の3つの部分で構成されています。

コマンドラインオプションのインストール

以下の表には、helm installコマンドに--setフラグを使用して指定できるすべての可能なチャートの構成が含まれています:

チャート構成の例

リソース

resourcesを使用すると、Sidekiqポッドが消費できるリソース（メモリとCPU）の最小量と最大量を構成できます。

Sidekiqポッドのワークロードは、デプロイによって大きく異なります。一般的に、各Sidekiqプロセスは約1 vCPUと2 GBのメモリを消費すると理解されています。垂直スケールは、一般的に1:2のvCPU:Memory比率に合わせるべきです。

resourcesの使用例を以下に示します。

resources:
  limits:
    memory: 5G
  requests:
    memory: 2G
    cpu: 900m

extraEnv

extraEnvを使用して、依存関係コンテナに追加の環境変数を公開します。

たとえば、SOME_KEYとSOME_OTHER_KEYの環境変数を公開するには、次のようにします:

extraEnv:
  SOME_KEY: some_value
  SOME_OTHER_KEY: some_other_value

コンテナが起動したら、envコマンドを実行し、変数名をgrepして環境変数が公開されていることを確認します。例:

env | grep SOME
SOME_KEY=some_value
SOME_OTHER_KEY=some_other_value

特定のポッドに対してextraEnvを設定することもできます。例:

extraEnv:
  SOME_KEY: some_value
  SOME_OTHER_KEY: some_other_value
pods:
  - name: mailers
    queues: mailers
    extraEnv:
      SOME_POD_KEY: some_pod_value
  - name: catchall

これにより、mailersポッド内のアプリケーションコンテナにのみSOME_POD_KEYが設定されます。ポッドレベルのextraEnv設定は、initコンテナに追加されません。

extraEnvFrom

extraEnvFromを使用すると、ポッド内のすべてのコンテナで他のデータソースから追加の環境変数を公開できます。その後の変数はSidekiqポッドごとにオーバーライドできます。

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
pods:
  - name: immediate
    extraEnvFrom:
      CONFIG_STRING:
        configMapKeyRef:
          name: useful-config
          key: some-string
          # optional: boolean

extraVolumes

extraVolumesを使用すると、チャート全体で追加ボリュームを構成できます。

extraVolumesの使用例を以下に示します。

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

extraVolumeMounts

extraVolumeMountsを使用すると、チャート全体のすべてのコンテナにボリュームマウントを追加構成できます。

extraVolumeMountsの使用例を以下に示します。

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

image.pullSecrets

pullSecretsを使用すると、プライベートレジストリに対して認証し、ポッド用のイメージをプルできます。

プライベートレジストリとその認証方法に関する追加の詳細は、Kubernetesドキュメントで確認できます。

pullSecretsの使用例を以下に示します。

image:
  repository: my.sidekiq.repository
  pullPolicy: Always
  pullSecrets:
  - name: my-secret-name
  - name: my-secondary-secret-name

serviceAccount

このセクションでは、ServiceAccountを作成するかどうか、およびデフォルトのアクセストークンをポッドにマウントするかどうかを制御します。

トレランス

tolerationsは、汚染されたワーカーノードにポッドをスケジュールできるようにします

tolerationsの使用例を以下に示します。

tolerations:
- key: "node_label"
  operator: "Equal"
  value: "true"
  effect: "NoSchedule"
- key: "node_label"
  operator: "Equal"
  value: "true"
  effect: "NoExecute"

アノテーション

annotationsを使用すると、Sidekiqポッドにアノテーションを追加できます。

annotationsの使用例を以下に示します。

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

このチャートのCommunity Editionの使用

デフォルトの場合、HelmチャートではGitLabのEnterprise Editionを使用します。必要に応じて、Community Editionを使用できます。両者の違いについては、こちらをご覧ください。

Community Editionを使用するには、image.repositoryをregistry.gitlab.com/gitlab-org/build/cng/gitlab-sidekiq-ceに設定します。

外部サービス

このチャートは、Webserviceチャートと同じRedis、PostgreSQL、およびGitalyインスタンスにアタッチする必要があります。外部サービスの値は、すべてのSidekiqポッドで共有されるConfigMapに入力されます。

Redis

redis:
  host: rank-racoon-redis
  port: 6379
  sentinels:
    - host: sentinel1.example.com
      port: 26379
      ssl: false
  password:
    secret: gitlab-redis
    key: redis-password

PostgreSQL

psql:
  host: rank-racoon-psql
  serviceName: pgbouncer
  port: 5432
  database: gitlabhq_production
  username: gitlab
  preparedStatements: false
  password:
    secret: gitlab-postgres
    key: psql-password

Sidekiqデプロイのdependencies initContainerは、次のことを確認するスクリプトを実行します:

• GitLabの依存関係が利用可能かどうか。
• PostgreSQLのデータベース移行が実行されているかどうか。

SidekiqチャートのextraEnv構成キーを使用して、これらのスクリプトの動作を制御できます。次の2つの環境変数がサポートされています:

• BYPASS_POST_DEPLOYMENT=true: すべての通常の移行が実行され、デプロイ後の移行のみが保留中の場合、依存関係チェックは合格します
• BYPASS_SCHEMA_VERSION=true (非推奨): 通常の移行が実行されていなくても、依存関係チェックは合格します。この環境変数を使用すると、データベーススキーマがアプリケーションコードデプロイが起動後にエラーが発生する可能性があります。

Gitaly

gitaly:
  internal:
    names:
      - default
      - default2
  external:
    - name: node1
      hostname: node1.example.com
      port: 8079
  authToken:
    secret: gitaly-secret
    key: token

メトリクス

デフォルトでは、Prometheusメトリクスexporterはポッドごとに有効になっています。メトリクスは、GitLab Prometheusメトリクスが管理者エリアで有効になっている場合にのみ利用できます。exporterは/metricsエンドポイントをポート3807で公開します。メトリクスが有効になっている場合、アノテーションが各ポッドに追加され、Prometheusサーバーが公開されたメトリクスを検出してスクレイプできるようになります。

チャート全体のデフォルト

以下の値は、ポッドごとに値が提示されない場合、チャート全体で使用されます。

HPAスケールの無効化

デフォルトでは、Sidekiqチャートは水平ポッドオートスケール（HPA）を有効にして、CPU使用率に基づいてポッドを自動的にスケールします。HPAスケールを無効にし、代わりに固定レプリカ数を使用するには、チャートレベルでminReplicasをmaxReplicasと等しく設定して、すべてのポッドのHPAを無効にします:

gitlab:
  sidekiq:
    minReplicas: 3
    maxReplicas: 3  # Setting equal to minReplicas disables HPA scaling
    concurrency: 25
    pods:
      - name: default

ポッドごとの設定

pods宣言は、ワーカーポッドのすべての属性の宣言を提供します。これらは、Sidekiqインスタンスごとに個別のConfigMapとともに、Deploymentにテンプレート化されます。

[!note]

設定は、すべてのキューを監視するようにセットアップされた単一のポッドを含むことをデフォルトとします。ポッドセクションに変更を加えると、デフォルトポッドを上書きすることになり、別のポッド構成になります。デフォルトに加えて新しいポッドは追加されません。

キュー

queues値は、処理されるキューのコンマ区切りリストを含む文字列です。デフォルトでは、すべてのキューが処理されることを意味し、設定されていません。

文字列にはスペースを含めないでください。merge,post_receive,process_commitは機能しますが、merge, post_receive, process_commitは機能しません。

ジョブが追加されたが、少なくとも1つのポッドエントリの一部として表現されていないキューは、処理されません。すべてのキューの完全なリストについては、GitLabソースのこれらのファイルを参照してください:

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

gitlab.sidekiq.pods[].queuesを構成することに加えて、global.appConfig.sidekiq.routingRulesも構成する必要があります。詳細については、Sidekiqルーティングルール設定を参照してください。

例podエントリ

pods:
  - name: immediate
    concurrency: 10
    minReplicas: 2  # defaults to inherited value
    maxReplicas: 10 # defaults to inherited value
    maxUnavailable: 5 # defaults to inherited value
    queues: merge,post_receive,process_commit
    extraVolumeMounts: |
      - name: example-volume-mount
        mountPath: /etc/example
    extraVolumes: |
      - name: example-volume
        persistentVolumeClaim:
          claimName: example-pvc
    resources:
      limits:
        cpu: 800m
        memory: 2Gi
    hpa:
      cpu:
        targetType: Value
        targetAverageValue: 350m

Sidekiq構成の完全な例

以下は、別のSidekiqポッドをインポート関連のジョブに、別のRedisインスタンスを使用したエクスポート関連のジョブに、そして別のポッドをその他すべてに使用するSidekiq構成の完全な例です。

...
global:
  appConfig:
    sidekiq:
      routingRules:
      - ["feature_category=importers", "import"]
      - ["feature_category=exporters", "export", "queues_shard_extra_shard"]
      - ["*", "default"]
  redis:
    redisYmlOverride:
      queues_shard_extra_shard: ...
...
gitlab:
  sidekiq:
    pods:
    - name: import
      queues: import
    - name: export
      queues: export
      extraEnv:
        SIDEKIQ_SHARD_NAME: queues_shard_extra_shard # to match key in global.redis.redisYmlOverride
    - name: default
...

networkpolicyの構成

このセクションでは、NetworkPolicyを制御します。この構成はオプションであり、ポッドのエグレスとIngressを特定のエンドポイントに制限するために使用されます。

ネットワークポリシーの例

Sidekiqサービスは、有効になっている場合はPrometheus exporterのみのIngress接続を必要とし、通常はさまざまな場所へのエグレス接続を必要とします。この例では、次のネットワークポリシーを追加します:

• Ingressリクエストを許可します:
  • Prometheusポッドからポート3807へ
• エグレスリクエストを許可します:
  • kube-dnsからポート53へ
  • gitalyポッドからポート8075へ
  • registryポッドからポート5000へ
  • kasポッドからポート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へ
  • AWS VPCエンドポイント（S3またはSTS用）172.16.1.0/24からポート443へ
  • 内部サブネット172.16.2.0/24からポート443へWebhookを送信します

提供されている例はあくまで例であり、完全ではない可能性があります。Sidekiqサービスは、ローカルエンドポイントが利用できない場合、外部オブジェクトストレージ上のイメージに対してパブリックインターネットへの送信接続を必要とします。この例は、kube-dnsがkube-systemネームスペースにデプロイされ、prometheusがmonitoringネームスペースにデプロイされ、nginx-ingressがnginx-ingressネームスペースにデプロイされたという前提に基づいています。

networkpolicy:
  enabled: true
  ingress:
    enabled: true
    rules:
      - from:
          - namespaceSelector:
              matchLabels:
                kubernetes.io/metadata.name: monitoring
            podSelector:
              matchLabels:
                app: prometheus
                component: server
                release: gitlab
        ports:
          - port: 3807
  egress:
    enabled: true
    rules:
      - to:
          - podSelector:
              matchLabels:
                app: gitaly
        ports:
          - port: 8075
      - to:
          - podSelector:
              matchLabels:
                app: kas
        ports:
          - port: 8153
      - to:
          - namespaceSelector:
              matchLabels:
                kubernetes.io/metadata.name: kube-system
            podSelector:
              matchLabels:
                k8s-app: kube-dns
        ports:
          - port: 53
            protocol: UDP
      - to:
          - ipBlock:
              cidr: 172.16.0.10/32
        ports:
          - port: 5432
      - to:
          - ipBlock:
              cidr: 172.16.0.11/32
        ports:
          - port: 6379
      - to:
          - ipBlock:
              cidr: 172.16.0.12/32
        ports:
          - port: 25
      - to:
          - ipBlock:
              cidr: 172.16.0.13/32
        ports:
          - port: 443
      - to:
          - ipBlock:
              cidr: 172.16.1.0/24
        ports:
          - port: 443
      - to:
          - ipBlock:
              cidr: 172.16.2.0/24
        ports:
          - port: 443

KEDAの構成

このkedaセクションでは、通常のHorizontalPodAutoscalersの代わりにKEDA ScaledObjectsのインストールを有効にします。この構成はオプションであり、カスタムメトリクスまたは外部メトリクスに基づくオートスケールが必要な場合に使用できます。

ほとんどの設定は、適用可能な場合はhpaセクションで設定された値にデフォルト設定されます。

以下が真の場合、CPUおよびメモリのトリガーは、hpaセクションで設定されたCPUおよびメモリのしきい値に基づいて自動的に追加されます:

• triggersが設定されていません。
• 対応するrequest.cpu.requestまたはrequest.memory.request設定もゼロ以外の値に設定されています。

トリガーが設定されていない場合、ScaledObjectは作成されません。

これらの設定の詳細については、KEDAドキュメントを参照してください。