- Installation command line options
- Chart configuration examples
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.
This chart depends on access to the GitLab API.
spamcheck is disabled by default. To enable it on your GitLab instance, set the Helm property
true, for example:
helm upgrade --force --install gitlab . \ --set global.hosts.domain='your.domain.com' \ --set global.hosts.externalIP=XYZ.XYZ.XYZ.XYZ \ --set firstname.lastname@example.org' \ --set global.spamcheck.enabled=true
- On the top bar, select
- On the left sidebar, select
Spam and Anti-bot Protection.
- Update the Spam Check settings:
- Check the
Enable Spam Check via external API endpointcheckbox
- For URL of the external Spam Check endpoint use
defaultis replaced with the Kubernetes namespace where GitLab is deployed.
Spam Check API keyblank.
- Check the
The table below contains all the possible charts configurations that can be supplied to the
helm install command using the
|Supplemental labels that are applied to all objects created by this chart.|
|20||Delay before liveness probe is initiated|
|60||How often to perform the liveness probe|
|30||When the liveness probe times out|
|1||Minimum consecutive successes for the liveness probe to be considered successful after having failed|
|3||Minimum consecutive failures for the liveness probe to be considered failed after having succeeded|
|0||Delay before readiness probe is initiated|
|10||How often to perform the readiness probe|
|2||When the readiness probe times out|
|1||Minimum consecutive successes for the readiness probe to be considered successful after having failed|
|3||Minimum consecutive failures for the readiness probe to be considered failed after having succeeded|
|Allows one to configure the update strategy used by the deployment. When not provided, the cluster default is used.|
|Set the autoscaling target value (CPU)|
|Spamcheck image repository|
|Toggle Prometheus metrics exporter|
|Port number to use for the metrics exporter|
|Path to use for the metrics exporter|
|Supplemental Pod labels. Not used for selectors.|
|Spamcheck minimum CPU|
|Spamcheck minimum memory|
|Group ID under which the pod should be started|
|User ID under which the pod should be started|
|Supplemental service labels|
|Spamcheck external port|
|Spamcheck internal port|
|Spamcheck service type|
|Flag for using ServiceAccount|
|Flag for creating a ServiceAccount|
|Toleration labels for pod assignment|
|List of extra environment variables from other data sources to expose|
tolerations allow you schedule pods on tainted worker nodes
Below is an example use of
tolerations: - key: "node_label" operator: "Equal" value: "true" effect: "NoSchedule" - key: "node_label" operator: "Equal" value: "true" effect: "NoExecute"
annotations allows you to add annotations to the Spamcheck pods. For example:
annotations: kubernetes.io/example-annotation: annotation-value
resources allows you to configure the minimum and maximum amount of resources (memory and CPU) a Spamcheck pod can consume.
resources: requests: memory: 100m cpu: 100M
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.
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.