GitLab-Spamcheckチャートの使用

spamcheckサブチャートは、元々GitLab.comでのスパムの増加に対抗するためにGitLabによって開発され、後にGitLab自己管理で使用するために公開されたアンチスパムエンジンであるSpamcheckのデプロイを提供します。

要件

このチャートは、GitLab APIへのアクセスに依存します。

設定

Spamcheckを有効にする

spamcheckは、デフォルトで無効になっています。GitLabインスタンスで有効にするには、Helmプロパティglobal.spamcheck.enabledをtrueに設定します。以下に例を示します:

helm upgrade --force --install gitlab . \
--set global.hosts.domain='your.domain.com' \
--set global.hosts.externalIP=XYZ.XYZ.XYZ.XYZ \
--set certmanager-issuer.email='me@example.com' \
--set global.spamcheck.enabled=true

Spamcheckを使用するようにGitLabを設定する

1. 左側のサイドバーの下部で、管理者エリアを選択します。
2. 左側のサイドバーの下部にある設定 > レポートを選択します。
3. スパムとアンチボット対策を展開します。
4. スパムチェック設定を更新します:
   1. 「外部APIエンドポイント経由でスパムチェックを有効にする」チェックボックスをオンにします。
   2. 外部スパムチェックエンドポイントのURLには、grpc://gitlab-spamcheck.default.svc:8001を使用します。defaultは、GitLabがデプロイされているKubernetesネームスペースに置き換えられます。
   3. 「スパムチェックAPIキー」は空白のままにします。
5. 変更を保存を選択します。

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

以下の表に、helm installフラグを使用して--setコマンドに指定できるすべてのチャートの設定を示します。

KEDAの設定

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

ほとんどの設定は、該当する場合、hpaセクションで設定された値にデフォルト設定されます。

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

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

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

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

チャート設定の例

serviceAccount

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

トレランス

tolerationsを使用すると、汚染されたワーカーノードでポッドをスケジュールできます

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

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

affinity

詳細については、affinityを参照してください。

annotations

annotationsを使用すると、Spamcheckポッドに注釈を追加できます。例:

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

リソース

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

例:

resources:
  requests:
    memory: 100m
    cpu: 100M

活性プローブ/準備プローブ

deployment.livenessProbeおよびdeployment.readinessProbeは、コンテナが破損状態にある場合など、特定のシナリオでSpamcheckポッドの終了を制御するのに役立つメカニズムを提供します。

例:

deployment:
  livenessProbe:
    initialDelaySeconds: 10
    periodSeconds: 20
    timeoutSeconds: 3
    successThreshold: 1
    failureThreshold: 10
  readinessProbe:
    initialDelaySeconds: 10
    periodSeconds: 5
    timeoutSeconds: 2
    successThreshold: 1
    failureThreshold: 3

この設定に関する追加の詳細については、公式のKubernetesドキュメントを参照してください。