• 要件
• 設定
  • Spamcheckの有効化
  • GitLabでスパムチェックを使う設定
• インストールのコマンドラインオプション
• KEDAの設定
• Chart設定例
  • 許容範囲
  • 注釈
  • リソース
  • livenessProbe/readinessProbe

GitLab-Spamcheckチャートの使い方

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

要件

このChartは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

GitLabでスパムチェックを使う設定

1. 左のサイドバーで、Search を選択するか、次のページに進んでください。
2. Admin Areaを選択します。
3. 設定 > レポートを選択します。
4. スパムとボット対策を展開します。
5. スパムチェックの設定を更新します：
   1. 外部APIエンドポイント経由のスパムチェックを有効にする」チェックボックスにチェックを入れてください。
   2. 外部スパムチェックエンドポイントのURLはgrpc://gitlab-spamcheck.default.svc:8001 を使用します。default は GitLab がデプロイされている Kubernetes ネームスペースに置き換えてください。
   3. Spam Check API key」は空欄のままにしてください。
6. 変更を保存を選択します。

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

以下の表は、--set フラグを使用してhelm install コマンドに提供できるすべての可能な Chart 設定です。

KEDAの設定

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

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

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

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

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

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

Chart設定例

許容範囲

tolerations 汚染されたワーカーノードでポッドのスケジューリングが可能

以下は、tolerations の使用例です：

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

注釈

annotations では、スパムチェックのポッドに注釈を追加できます。例えば

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

リソース

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

使用例：

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

livenessProbe/readinessProbe

deployment.livenessProbe およびdeployment.readinessProbe は、コンテナが壊れた状態など、特定のシナリオにおいてスパムチェックポッドの終了を制御するのに役立つメカニズムを提供します。

使用例：

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

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