Using the Mailroom chart

The Mailroom Pod handles the ingestion of email into the GitLab application.

Configuration

image:
  repository: registry.gitlab.com/gitlab-org/build/cng/gitlab-mailroom
  # tag: v0.9.1
  pullSecrets: []
  # pullPolicy: IfNotPresent

enabled: true

init:
  image: {}
    # repository:
    # tag:
  resources:
    requests:
      cpu: 50m

# Tolerations for pod scheduling
tolerations: []

podLabels: {}

hpa:
  minReplicas: 1
  maxReplicas: 2
  cpu:
    targetAverageUtilization: 75

  # Note that the HPA is limited to autoscaling/v2beta1, autoscaling/v2beta2 and autoscaling/v2
  customMetrics: []
  behavior: {}

networkpolicy:
  enabled: false
  egress:
    enabled: false
    rules: []
  ingress:
    enabled: false
    rules: []
  annotations: {}

resources:
  # limits:
  #  cpu: 1
  #  memory: 2G
  requests:
    cpu: 50m
    memory: 150M

## Allow to overwrite under which User and Group we're running.
securityContext:
  runAsUser: 1000
  fsGroup: 1000

## Enable deployment to use a serviceAccount
serviceAccount:
  enabled: false
  create: false
  annotations: {}
  ## Name to be used for serviceAccount, otherwise defaults to chart fullname
  # name:
ParameterDescriptionDefault
deployment.strategyAllows one to configure the update strategy utilized by the deployment{}
enabledMailroom enablement flagtrue
hpa.behaviorBehavior contains the specifications for up- and downscaling behavior (requires autoscaling/v2beta2 or higher){scaleDown: {stabilizationWindowSeconds: 300 }}
hpa.customMetricsCustom metrics contains the specifications for which to use to calculate the desired replica count (overrides the default use of Average CPU Utilization configured in targetAverageUtilization)[]
hpa.cpu.targetTypeSet the autoscaling CPU target type, must be either Utilization or AverageValue Utilization
hpa.cpu.targetAverageValueSet the autoscaling CPU target value 
hpa.cpu.targetAverageUtilizationSet the autoscaling CPU target utilization75
hpa.memory.targetTypeSet the autoscaling memory target type, must be either Utilization or AverageValue  
hpa.memory.targetAverageValueSet the autoscaling memory target value 
hpa.memory.targetAverageUtilizationSet the autoscaling memory target utilization 
hpa.maxReplicasMaximum number of replicas2
hpa.minReplicasMinimum number of replicas1
image.pullPolicyMailroom image pull policyIfNotPresent
extraEnvFromList of extra environment variables from other data sources to expose 
image.pullSecretsMailroom image pull secrets 
image.repositoryMailroom image repositoryregistry.gitlab.com/gitlab-org/build/cng/gitlab-mailroom
image.tagMailroom image tagmaster
init.image.repositoryMailroom init image repository 
init.image.tagMailroom init image tag 
init.resourcesMailroom init container resource requirements{ requests: { cpu: 50m }}
init.containerSecurityContext initContainer container specific securityContext
keda.enabledfalseUse KEDA ScaledObjects instead of HorizontalPodAutoscalers
keda.pollingInterval30The interval to check each trigger on
keda.cooldownPeriod300The period to wait after the last trigger reported active before scaling the resource back to 0
keda.minReplicaCount Minimum number of replicas KEDA will scale the resource down to, defaults to hpa.minReplicas
keda.maxReplicaCount Maximum number of replicas KEDA will scale the resource up to, defaults to hpa.maxReplicas
keda.fallback KEDA fallback configuration, see the documentation
keda.hpaName The name of the HPA resource KEDA will create, defaults to keda-hpa-{scaled-object-name}
keda.restoreToOriginalReplicaCount Specifies whether the target resource should be scaled back to original replicas count after the ScaledObject is deleted
keda.behavior The specifications for up- and downscaling behavior, defaults to hpa.behavior
keda.triggers List of triggers to activate scaling of the target resource, defaults to triggers computed from hpa.cpu and hpa.memory
podLabelsLabels for running Mailroom Pods{}
common.labelsSupplemental labels that are applied to all objects created by this chart.{}
resourcesMailroom resource requirements{ requests: { cpu: 50m, memory: 150M }}
networkpolicy.annotationsAnnotations to add to the NetworkPolicy{}
networkpolicy.egress.enabledFlag to enable egress rules of NetworkPolicyfalse
networkpolicy.egress.rulesDefine a list of egress rules for NetworkPolicy[]
networkpolicy.enabledFlag for using NetworkPolicyfalse
networkpolicy.ingress.enabledFlag to enable ingress rules of NetworkPolicyfalse
networkpolicy.ingress.rulesDefine a list of ingress rules for NetworkPolicy[]
securityContext.fsGroupGroup ID under which the pod should be started1000
securityContext.runAsUserUser ID under which the pod should be started1000
securityContext.fsGroupChangePolicyPolicy for changing ownership and permission of the volume (requires Kubernetes 1.23) 
containerSecurityContext Override container securityContext under which the container is started
containerSecurityContext.runAsUser1000Allow to overwrite the specific security context under which the container is started
serviceAccount.annotationsAnnotations for ServiceAccount{}
serviceAccount.enabledFlag for using ServiceAccountfalse
serviceAccount.createFlag for creating a ServiceAccountfalse
serviceAccount.nameName of ServiceAccount to use 
tolerationsTolerations to add to the Mailroom 
priorityClassName Priority class assigned to pods. 

Configuring KEDA

This keda section enables the installation of KEDA ScaledObjects instead of regular HorizontalPodAutoscalers. This configuration is optional and can be used when there is a need for autoscaling based on custom or external metrics.

Most settings default to the values set in the hpa section where applicable.

If the following are true, CPU and memory triggers are added automatically based on the CPU and memory thresholds set in the hpa section:

  • triggers is not set.
  • The corresponding request.cpu.request or request.memory.request setting is also set to a non-zero value.

If no triggers are set, the ScaledObject is not created.

Refer to the KEDA documentation for more details about those settings.

NameTypeDefaultDescription
enabledBooleanfalseUse KEDA ScaledObjects instead of HorizontalPodAutoscalers
pollingIntervalInteger30The interval to check each trigger on
cooldownPeriodInteger300The period to wait after the last trigger reported active before scaling the resource back to 0
minReplicaCountInteger Minimum number of replicas KEDA will scale the resource down to, defaults to hpa.minReplicas
maxReplicaCountInteger Maximum number of replicas KEDA will scale the resource up to, defaults to hpa.maxReplicas
fallbackMap KEDA fallback configuration, see the documentation
hpaNameString The name of the HPA resource KEDA will create, defaults to keda-hpa-{scaled-object-name}
restoreToOriginalReplicaCountBoolean Specifies whether the target resource should be scaled back to original replicas count after the ScaledObject is deleted
behaviorMap The specifications for up- and downscaling behavior, defaults to hpa.behavior
triggersArray List of triggers to activate scaling of the target resource, defaults to triggers computed from hpa.cpu and hpa.memory

Incoming email

By default, incoming email is disabled. There are two methods for reading incoming email:

First, enable it by setting the common settings. Then configure the IMAP settings or Microsoft Graph settings.

These methods can be configured in values.yaml. See the following examples:

IMAP

To enable incoming e-mail for IMAP, provide details of your IMAP server and access credentials using the global.appConfig.incomingEmail settings.

In addition, the requirements for the IMAP email account should be reviewed to ensure that the targeted IMAP account can be used by GitLab for receiving email. Several common email services are also documented on the same page to aid in setting up incoming email.

The IMAP password will still need to be created as a Kubernetes Secret as described in the secrets guide.

Microsoft Graph

See the GitLab documentation on creating an Azure Active Directory application.

Provide the tenant ID, client ID, and client secret. You can find details for these settings in the command line options.

Create a Kubernetes secret containing the client secret as described in the secrets guide.

Reply-by-email

To use the reply-by-email feature, where users can reply to notification emails to comment on issues and MRs, you need to configure both outgoing email and incoming email settings.

Service Desk email

By default, the Service Desk email is disabled.

As with incoming e-mail, enable it by setting the common settings. Then configure the IMAP settings or Microsoft Graph settings.

These options can also be configured in values.yaml. See the following examples:

Service Desk email requires that Incoming email be configured.

IMAP

Provide details of your IMAP server and access credentials using the global.appConfig.serviceDeskEmail settings. You can find details for these settings in the command line options.

Create a Kubernetes secret containing IMAP password as described in the secrets guide.

Microsoft Graph

See the GitLab documentation on creating an Azure Active Directory application.

Provide the tenant ID, client ID, and client secret using the global.appConfig.serviceDeskEmail settings. You can find details for these settings in the command line options.

You will also have to create a Kubernetes secret containing the client secret as described in the secrets guide.