• Requirements
• Configuration
  • Enable Spamcheck
  • Configure GitLab to use Spamcheck
• Installation command line options
• Chart configuration examples
  • tolerations
  • annotations
  • resources
  • livenessProbe/readinessProbe

Using the GitLab-Spamcheck chart

The spamcheck sub-chart provides a deployment of Spamcheck which is an anti-spam engine developed by GitLab originally to combat the rising amount of spam in GitLab.com, and later made public to be used in self-managed GitLab instances.

Requirements

This chart depends on access to the GitLab API.

Configuration

Enable Spamcheck

spamcheck is disabled by default. To enable it on your GitLab instance, set the Helm property global.spamcheck.enabled to true, for example:

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

Configure GitLab to use Spamcheck

1. On the top bar, select Menu > Admin.
2. On the left sidebar, select Settings > Reporting.
3. Expand Spam and Anti-bot Protection.
4. Update the Spam Check settings:
   1. Check the Enable Spam Check via external API endpoint checkbox
   2. For URL of the external Spam Check endpoint use grpc://gitlab-spamcheck.default.svc:8001, where default is replaced with the Kubernetes namespace where GitLab is deployed.
   3. Leave Spam Check API key blank.
5. Select Save changes.

Installation command line options

The table below contains all the possible charts configurations that can be supplied to the helm install command using the --set flags.

Chart configuration examples

tolerations

tolerations allow you schedule pods on tainted worker nodes

Below is an example use of tolerations:

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

annotations

annotations allows you to add annotations to the Spamcheck pods. For example:

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

resources

resources allows you to configure the minimum and maximum amount of resources (memory and CPU) a Spamcheck pod can consume.

For example:

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

livenessProbe/readinessProbe

deployment.livenessProbe and deployment.readinessProbe provide a mechanism to help control the termination of Spamcheck Pods in certain scenarios, such as, when a container is in a broken state.

For example:

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

Refer to the official Kubernetes Documentation for additional details regarding this configuration.