- Installation command line options
- Chart configuration examples
Using the GitLab-Spamcheck chart
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 email@example.com' \ --set global.spamcheck.enabled=true
Configure GitLab to use Spamcheck
- 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
Installation command line options
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.|
|Behavior contains the specifications for up- and downscaling behavior (requires |
|Custom metrics contains the specifications for which to use to calculate the desired replica count (overrides the default use of Average CPU Utilization configured in |
|Set the autoscaling CPU target type, must be either |
|Set the autoscaling CPU target value|
|Set the autoscaling CPU target utilization|
|Set the autoscaling memory target type, must be either |
|Set the autoscaling memory target value|
|Set the autoscaling memory target utilization|
|DEPRECATED Set the autoscaling CPU target value|
|Spamcheck image repository|
|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|
|Policy for changing ownership and permission of the volume (requires Kubernetes 1.23)|
|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|
|Priority class assigned to pods.|
Chart configuration examples
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.