DevOps-GitLab

GitLab Helm subcharts | GitLab

GitLab Helm subcharts

The GitLab Helm chart is made up of multiple subcharts,
which provide the core GitLab components:

Gitaly
GitLab Exporter
GitLab Grafana
GitLab Pages
GitLab Runner
GitLab Shell
GitLab agent server (KAS)
Mailroom
Migrations
Praefect
Sidekiq
Spamcheck
Toolbox
Webservice

The parameters for each subchart must be under the gitlab key. For example,
GitLab Shell parameters would be similar to:

      gitlab:
  gitlab-shell:
    ...

     

Use these charts for optional dependencies:

MinIO
NGINX
PostgreSQL
Redis
Registry

Use these charts as optional additions:

Prometheus
Grafana
Unprivileged GitLab Runner that uses the Kubernetes executor
Automatically provisioned SSL from Let’s Encrypt, which uses Jetstack’s cert-manager with certmanager-issuer

Using the GitLab `kas` chart | GitLab

Disable the agent server
- Specify an Ingress
- Installation command line options
Enable TLS communication
- Create your certificates
- Chart configuration values
Test the kas chart

Using the GitLab `kas` chart

The kas sub-chart provides a configurable deployment of the
GitLab agent server (KAS).
The agent server is a component you install together with GitLab. It is required to
manage the GitLab agent for Kubernetes.

This chart depends on access to the GitLab API and the Gitaly Servers.
When you enable this chart, an Ingress is deployed.

To consume minimal resources, the kas container uses a distroless image.
The deployed services are exposed by an Ingress, which uses
WebSocket proxying for communication.
This proxy allows long-lived connections with the external component,
agentk .
agentk is the Kubernetes cluster-side agent counterpart.

The route to access the service depends on your Ingress configuration.

For more information, see the
GitLab agent for Kubernetes architecture.

Disable the agent server

The GitLab agent server ( kas ) is enabled by default.
To disable it on your GitLab instance, set the Helm property global.kas.enabled to false .

For example:

      helm upgrade --install kas --set global.kas.enabled=false

     

Specify an Ingress

When you use the chart’s Ingress with the default configuration,
the service for the agent server is reachable on a subdomain.
For example, for global.hosts.domain: example.com , the agent server
is reachable at kas.example.com .

The KAS Ingress
can use a different domain than the global.hosts.domain .

Set global.hosts.kas.name , for example:

global.hosts.kas.name: kas.my-other-domain.com

This example uses kas.my-other-domain.com as the host for the KAS Ingress alone.
The rest of the services (including GitLab, Registry, MinIO, etc.) use the domain
specified in global.hosts.domain .

Installation command line options

You can pass these parameters to the helm install command by using the --set flags.

Parameter	Default	Description
`annotations`	`{}`	Pod annotations.
`common.labels`	`{}`	Supplemental labels that are applied to all objects created by this chart.
`extraContainers`		List of extra containers to include.
`image.repository`	`registry.gitlab.com/gitlab-org/build/cng/gitlab-kas`	Image repository.
`image.tag`	`v13.7.0`	Image tag.
`hpa.behavior`	`{scaleDown: {stabilizationWindowSeconds: 300 }}`	Behavior contains the specifications for up- and downscaling behavior (requires `autoscaling/v2beta2` or higher)
`hpa.customMetrics`	`[]`	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 `targetAverageUtilization` )
`hpa.cpu.targetType`	`AverageValue`	Set the autoscaling CPU target type, must be either `Utilization` or `AverageValue`
`hpa.cpu.targetAverageValue`	`100m`	Set the autoscaling CPU target value
`hpa.cpu.targetAverageUtilization`		Set the autoscaling CPU target utilization
`hpa.memory.targetType`		Set the autoscaling memory target type, must be either `Utilization` or `AverageValue`
`hpa.memory.targetAverageValue`		Set the autoscaling memory target value
`hpa.memory.targetAverageUtilization`		Set the autoscaling memory target utilization
`hpa.targetAverageValue`		DEPRECATED Set the autoscaling CPU target value
`ingress.enabled`	`true` if `global.kas.enabled=true`	You can use `kas.ingress.enabled` to explicitly turn it on or off. If not set, you can optionally use `global.ingress.enabled` for the same purpose.
`ingress.apiVersion`		Value to use in the `apiVersion` field.
`ingress.annotations`	`{}`	Ingress annotations.
`ingress.tls`	`{}`	Ingress TLS configuration.
`ingress.agentPath`	`/`	Ingress path for the agent API endpoint.
`ingress.k8sApiPath`	`/k8s-proxy`	Ingress path for Kubernetes API endpoint.
`metrics.enabled`	`true`	If a metrics endpoint should be made available for scraping.
`metrics.port`	`8151`	DEPRECATED: use `observability.port` . Metrics endpoint port.
`metrics.path`	`/metrics`	Metrics endpoint path.
`metrics.serviceMonitor.enabled`	`false`	If a ServiceMonitor should be created to enable Prometheus Operator to manage the metrics scraping. Enabling removes the `prometheus.io` scrape annotations.
`metrics.serviceMonitor.additionalLabels`	`{}`	Additional labels to add to the ServiceMonitor.
`metrics.serviceMonitor.endpointConfig`	`{}`	Additional endpoint configuration for the ServiceMonitor.
`maxReplicas`	`10`	HPA `maxReplicas` .
`maxUnavailable`	`1`	HPA `maxUnavailable` .
`minReplicas`	`2`	HPA `maxReplicas` .
`nodeSelector`		Define a nodeSelector for the `Pod` s of this `Deployment` , if present.
`observability.port`	`8151`	Observability endpoint port. Used for metrics and probe endpoints.
`observability.livenessProbe.path`	`/liveness`	URI for the liveness probe endpoint. This value has to match the `observability.liveness_probe.url_path` value from the KAS service configuration
`observability.readinessProbe.path`	`/readiness`	URI for the readiness probe endpoint. This value has to match the `observability.readiness_probe.url_path` value from the KAS service configuration
`serviceAccount.annotations`	`{}`	Service account annotations.
`podLabels`	`{}`	Supplemental Pod labels. Not used for selectors.
`serviceLabels`	`{}`	Supplemental service labels.
`common.labels`		Supplemental labels that are applied to all objects created by this chart.
`redis.enabled`	`true`	Allows opting-out of using Redis for KAS features. Warnings: Redis will become a hard dependency soon, so this key is already deprecated.
`resources.requests.cpu`	`75m`	GitLab Exporter minimum CPU.
`resources.requests.memory`	`100M`	GitLab Exporter minimum memory.
`service.externalPort`	`8150`	External port (for `agentk` connections).
`service.internalPort`	`8150`	Internal port (for `agentk` connections).
`service.apiInternalPort`	`8153`	Internal port for the internal API (for GitLab backend).
`service.loadBalancerIP`	`nil`	A custom load balancer IP when `service.type` is `LoadBalancer` .
`service.loadBalancerSourceRanges`	`nil`	A list of custom load balancer source ranges when `service.type` is `LoadBalancer` .
`service.kubernetesApiPort`	`8154`	External port to expose proxied Kubernetes API on.
`service.privateApiPort`	`8155`	Internal port to expose `kas` ’ private API on (for `kas` -> `kas` communication).
`privateApi.secret`	Autogenerated	The name of the secret to use for authenticating with the database.
`privateApi.key`	Autogenerated	The name of the key in `privateApi.secret` to use.
`privateApi.tls`	`false`	Enable `kas` pods to communicate with each other using TLS.
`privateApi.tls.secretName`	`nil`	Name of the Kubernetes TLS secret which contains the certificate and its associated key. Required if `privateApi.tls` is `true` .
`privateApi.host`	`private-api.test`	Name of the host added to your certificate’s SAN. Required if `privateApi.tls` is `true` .
`global.kas.service.apiExternalPort`	`8153`	External port for the internal API (for GitLab backend).
`service.type`	`ClusterIP`	Service type.
`tolerations`	`[]`	Toleration labels for pod assignment.
`customConfig`	`{}`	When given, merges the default `kas` configuration with these values giving precedence to those defined here.
`deployment.minReadySeconds`	`0`	Minimum number of seconds that must pass before a `kas` pod is considered ready.
`deployment.strategy`	`{}`	Allows one to configure the update strategy utilized by the deployment.
`deployment.terminationGracePeriodSeconds`	`300`	How much time in seconds a Pod is allowed to spend shutting down after receiving SIGTERM.
`priorityClassName`		Priority class assigned to pods.

Enable TLS communication

Enable TLS communication between your kas pods and other GitLab chart components.

Prerequisite:

You need at least GitLab 15.5.1 to use this feature. You can set your GitLab version with global.gitlabVersion: master . If you need to force an image update after an initial deployment, also set global.image.pullPolicy: Always .

Create the certificate authority and certificates that your kas pods will trust.
Configure your chart to use the trusted certificates.

Create your certificates

To create a certificate authority (CA) and the required certificates, follow the steps in
Use TLS between components of the GitLab chart.

Chart configuration values

To configure kas to use the certificates you created, set the following values.

Value	Description
`global.certificates.customCAs`	Shares your CA with your GitLab components.
`global.appConfig.gitlab_kas.internalUrl`	Enables `grpcs` communication between the GitLab Webservice and `kas` .
`gitlab.kas.privateApi.tls.enabled`	Mounts the certificates volume and enables TLS communication between `kas` pods.
`gitlab.kas.privateApi.tls.secretName`	Specifies which Kubernetes TLS secret stores your certificates.
`gitlab.kas.customConfig`	Configures `kas` to expose its ports by using `grpcs` .
`gitlab.kas.ingress`	Configures `kas` Ingress to verify the proxied SSL certificate.

For example, you could use this values.yaml file to deploy your chart:

         .internal-ca: &internal-ca gitlab-internal-tls-ca # The secret name you used to share your TLS CA.
   .internal-tls: &internal-tls gitlab-internal-tls # The secret name you used to share your TLS certificate.

   global:
     certificates:
       customCAs:
       - secret: *internal-ca
     hosts:
       domain: gitlab.example.com # Your gitlab domain
     appConfig:
       gitlab_kas:
         internalUrl: "grpcs://RELEASE-kas.NAMESPACE.svc:8153" # Replace RELEASE and NAMESPACE with your chart's release and namespace 

   gitlab:
     kas:
       privateApi:
         tls:
           enabled: true
           secretName: *internal-tls
       customConfig:
         api:
           listen:
             certificate_file: /etc/kas/tls.crt
             key_file: /etc/kas/tls.key
         agent:
           listen:
             certificate_file: /etc/kas/tls.crt
             key_file: /etc/kas/tls.key
           kubernetes_api:
             listen:
               certificate_file: /etc/kas/tls.crt
               key_file: /etc/kas/tls.key
       ingress:
         annotations:
           nginx.ingress.kubernetes.io/backend-protocol: https
           nginx.ingress.kubernetes.io/proxy-ssl-name: RELEASE-kas.NAMESPACE.svc # Replace RELEASE and NAMESPACE with your chart's release and namespace
           nginx.ingress.kubernetes.io/proxy-ssl-secret: NAMESPACE/CA-SECRET-NAME # Replace NAMESPACE and CA-SECRET-NAME with your chart's namespace and CA secret name. The same you used for &internal-ca.
           nginx.ingress.kubernetes.io/proxy-ssl-verify: on

     

Test the `kas` chart

To install the chart:

Create your own Kubernetes cluster.
Check out the merge request’s working branch.

Install (or upgrade) GitLab with kas enabled by default from your local chart branch:

        helm upgrade --force --install gitlab . \
  --timeout 600s \
  --set global.hosts.domain=your.domain.com \
  --set global.hosts.externalIP=XYZ.XYZ.XYZ.XYZ \
  --set certmanager-issuer.email=your@email.com

       

Use the GDK to run the process to configure and use the
GitLab agent for Kubernetes:
(You can also follow the steps to configure and use the agent manually.)
1. From your GDK GitLab repository, move into the QA folder: cd qa .
2. Run the following command to run the QA test:
```
GITLAB_USERNAME=$ROOT_USER
GITLAB_PASSWORD=$ROOT_PASSWORD
GITLAB_ADMIN_USERNAME=$ROOT_USER
GITLAB_ADMIN_PASSWORD=$ROOT_PASSWORD
bundle exec bin/qa Test::Instance::All https://your.gitlab.domain/ -- --tag orchestrated --tag quarantine qa/specs/features/ee/api/7_configure/kubernetes/kubernetes_agent_spec.rb
```
  You can also customize the agentk version to install with an environment variable: GITLAB_AGENTK_VERSION=v13.7.1

Read article

Using the Mailroom chart | GitLab

Configuration
Incoming email
- IMAP
- Microsoft Graph
- Reply-by-email
- Service Desk email
  - IMAP
  - Microsoft Graph

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:

     

Parameter	Description	Default
`deployment.strategy`	Allows one to configure the update strategy utilized by the deployment	`{}`
`enabled`	Mailroom enablement flag	`true`
`hpa.behavior`	Behavior contains the specifications for up- and downscaling behavior (requires `autoscaling/v2beta2` or higher)	`{scaleDown: {stabilizationWindowSeconds: 300 }}`
`hpa.customMetrics`	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 `targetAverageUtilization` )	`[]`
`hpa.cpu.targetType`	Set the autoscaling CPU target type, must be either `Utilization` or `AverageValue`	`Utilization`
`hpa.cpu.targetAverageValue`	Set the autoscaling CPU target value
`hpa.cpu.targetAverageUtilization`	Set the autoscaling CPU target utilization	`75`
`hpa.memory.targetType`	Set the autoscaling memory target type, must be either `Utilization` or `AverageValue`
`hpa.memory.targetAverageValue`	Set the autoscaling memory target value
`hpa.memory.targetAverageUtilization`	Set the autoscaling memory target utilization
`hpa.maxReplicas`	Maximum number of replicas	`2`
`hpa.minReplicas`	Minimum number of replicas	`1`
`image.pullPolicy`	Mailroom image pull policy	`IfNotPresent`
`extraEnvFrom`	List of extra environment variables from other data sources to expose
`image.pullSecrets`	Mailroom image pull secrets
`image.repository`	Mailroom image repository	`registry.gitlab.com/gitlab-org/build/cng/gitlab-mailroom`
`image.tag`	Mailroom image tag	`master`
`init.image.repository`	Mailroom init image repository
`init.image.tag`	Mailroom init image tag
`init.resources`	Mailroom init container resource requirements	`{ requests: { cpu: 50m }}`
`podLabels`	Labels for running Mailroom Pods	`{}`
`common.labels`	Supplemental labels that are applied to all objects created by this chart.	`{}`
`resources`	Mailroom resource requirements	`{ requests: { cpu: 50m, memory: 150M }}`
`networkpolicy.annotations`	Annotations to add to the NetworkPolicy	`{}`
`networkpolicy.egress.enabled`	Flag to enable egress rules of NetworkPolicy	`false`
`networkpolicy.egress.rules`	Define a list of egress rules for NetworkPolicy	`[]`
`networkpolicy.enabled`	Flag for using NetworkPolicy	`false`
`networkpolicy.ingress.enabled`	Flag to enable `ingress` rules of NetworkPolicy	`false`
`networkpolicy.ingress.rules`	Define a list of `ingress` rules for NetworkPolicy	`[]`
`securityContext.fsGroup`	Group ID under which the pod should be started	`1000`
`securityContext.runAsUser`	User ID under which the pod should be started	`1000`
`serviceAccount.annotations`	Annotations for ServiceAccount	`{}`
`serviceAccount.enabled`	Flag for using ServiceAccount	`false`
`serviceAccount.create`	Flag for creating a ServiceAccount	`false`
`serviceAccount.name`	Name of ServiceAccount to use
`tolerations`	Tolerations to add to the Mailroom
`priorityClassName`	Priority class assigned to pods.

Incoming email

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

IMAP
Microsoft Graph

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:

Incoming email with IMAP
Incoming email with Microsoft Graph

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 with IMAP
Service Desk with Microsoft Graph

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.

Read article

Using the GitLab-Migrations chart | GitLab

Requirements
Design Choices
Configuration
Installation command line options
Chart configuration examples
- extraEnv
- extraEnvFrom
- image.pullSecrets
Using the Community Edition of this chart
External Services
- Redis
  - host
  - serviceName
  - port
  - password
  - sentinels
- PostgreSQL
  - host
  - serviceName
  - port
  - database
  - preparedStatements
  - username
  - password

Using the GitLab-Migrations chart

The migrations sub-chart provides a single migration Job that handles seeding/migrating the GitLab database. The chart runs using the GitLab Rails codebase.

After migrating, this Job also edits the application settings in the database to turn off writes to authorized keys file. In the charts we are only supporting use of the GitLab Authorized Keys API with the SSH AuthorizedKeysCommand instead of support for writing to an authorized keys file.

Requirements

This chart depends on Redis, and PostgreSQL, either as part of the complete GitLab chart or provided as external services reachable from the Kubernetes cluster this chart is deployed onto.

Design Choices

The migrations creates a new migrations Job each time the chart is deployed. In order to prevent job name collisions, we append the chart revision, and a random alpha-numeric value to the Job name each time is created. The purpose of the random text is described further in this section.

For now we also have the jobs remain as objects in the cluster after they complete. This is so we can observe the migration logs. Currently this means these Jobs persist even after a helm uninstall . This is one of the reasons why we append random text to the Job name, so that future deployments using the same release name don’t cause conflicts. Once we have some form of log-shipping in place, we can revisit the persistence of these objects.

The container used in this chart has some additional optimizations that we are not currently using in this Chart. Mainly the ability to quickly skip running migrations if they are already up to date, without needing to boot up the rails application to check. This optimization requires us to persist the migration status. Which we are not doing with this chart at the moment. In the future we will introduce storage support for the migrations status to this chart.

Configuration

The migrations chart is configured in two parts: external services, and chart settings.

Installation command line options

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

Parameter	Description	Default
`common.labels`	Supplemental labels that are applied to all objects created by this chart.	`{}`
`image.repository`	Migrations image repository	`registry.gitlab.com/gitlab-org/build/cng/gitlab-toolbox-ee`
`image.tag`	Migrations image tag
`image.pullPolicy`	Migrations pull policy	`Always`
`image.pullSecrets`	Secrets for the image repository
`init.image`	initContainer image	`busybox`
`init.tag`	initContainer image tag	`latest`
`enabled`	Migrations enable flag	`true`
`tolerations`	Toleration labels for pod assignment	`[]`
`annotations`	Annotations for the job spec	`{}`
`podAnnotations`	Annotations for the pob spec	`{}`
`podLabels`	Supplemental Pod labels. Will not be used for selectors.
`redis.serviceName`	Redis service name	`redis`
`psql.serviceName`	Name of Service providing PostgreSQL	`release-postgresql`
`psql.password.secret`	psql secret	`gitlab-postgres`
`psql.password.key`	key to psql password in psql secret	`psql-password`
`psql.port`	Set PostgreSQL server port. Takes precedence over `global.psql.port`
`resources.requests.cpu`	`250m`	GitLab Migrations minimum CPU
`resources.requests.memory`	`200Mi`	GitLab Migrations minimum memory
`securityContext.fsGroup`	`1000`	Group ID under which the pod should be started
`securityContext.runAsUser`	`1000`	User ID under which the pod should be started
`extraInitContainers`	List of extra init containers to include
`extraContainers`	List of extra containers to include
`extraVolumes`	List of extra volumes to create
`extraVolumeMounts`	List of extra volumes mounts to do
`extraEnv`	List of extra environment variables to expose
`extraEnvFrom`	List of extra environment variables from other data sources to expose
`bootsnap.enabled`	Enable the Bootsnap cache for Rails	`true`
`priorityClassName`	Priority class assigned to pods.

Chart configuration examples

extraEnv

extraEnv allows you to expose additional environment variables in all containers in the pods.

Below is an example use of extraEnv :

      extraEnv:
  SOME_KEY: some_value
  SOME_OTHER_KEY: some_other_value

     

When the container is started, you can confirm that the environment variables are exposed:

      env | grep SOME
SOME_KEY=some_value
SOME_OTHER_KEY=some_other_value

     

extraEnvFrom

extraEnvFrom allows you to expose additional environment variables from other data sources in all containers in the pods.

Below is an example use of extraEnvFrom :

      extraEnvFrom:
  MY_NODE_NAME:
    fieldRef:
      fieldPath: spec.nodeName
  MY_CPU_REQUEST:
    resourceFieldRef:
      containerName: test-container
      resource: requests.cpu
  SECRET_THING:
    secretKeyRef:
      name: special-secret
      key: special_token
      # optional: boolean
  CONFIG_STRING:
    configMapKeyRef:
      name: useful-config
      key: some-string
      # optional: boolean

     

image.pullSecrets

pullSecrets allow you to authenticate to a private registry to pull images for a pod.

Additional details about private registries and their authentication methods
can be found in the Kubernetes documentation.

Below is an example use of pullSecrets :

image:
  repository: my.migrations.repository
  pullPolicy: Always
  pullSecrets:
  - name: my-secret-name
  - name: my-secondary-secret-name

Using the Community Edition of this chart

By default, the Helm charts use the Enterprise Edition of GitLab. If desired, you can instead use the Community Edition. Learn more about the difference between the two.

In order to use the Community Edition, set image.repository to registry.gitlab.com/gitlab-org/build/cng/gitlab-toolbox-ce

External Services

Redis

redis:
  host: redis.example.com
  serviceName: redis
  port: 6379
  sentinels:
    - host: sentinel1.example.com
      port: 26379
  password:
    secret: gitlab-redis
    key: redis-password

host

The hostname of the Redis server with the database to use. This can be omitted in lieu of serviceName . If using Redis Sentinels, the host attribute needs to be set to the cluster name as specified in the sentinel.conf .

serviceName

The name of the service which is operating the Redis database. If this is present, and host is not, the chart will template the hostname of the service (and current .Release.Name ) in place of the host value. This is convenient when using Redis as a part of the overall GitLab chart. This will default to redis

port

The port on which to connect to the Redis server. Defaults to 6379 .

password

The password attribute for Redis has two sub keys:

secret defines the name of the Kubernetes Secret to pull from
key defines the name of the key in the above secret that contains the password.

sentinels

The sentinels attribute allows for a connection to a Redis HA cluster.
The sub keys describe each Sentinel connection.

host defines the hostname for the Sentinel service
port defines the port number to reach the Sentinel service, defaults to 26379

Note: The current Redis Sentinel support only supports Sentinels that have
been deployed separately from the GitLab chart. As a result, the Redis
deployment through the GitLab chart should be disabled with redis.install=false .
The Secret containing the Redis password will need to be manually created
before deploying the GitLab chart.

PostgreSQL

      psql:
  host: psql.example.com
  serviceName: pgbouncer
  port: 5432
  database: gitlabhq_production
  username: gitlab
  preparedStatements: false
  password:
    secret: gitlab-postgres
    key: psql-password

     

host

The hostname of the PostgreSQL server with the database to use. This can be omitted if postgresql.install=true (default non-production).

serviceName

The name of the service which is operating the PostgreSQL database. If this is present, and host is not, the chart will template the hostname of the service in place of the host value.

port

The port on which to connect to the PostgreSQL server. Defaults to 5432 .

database

The name of the database to use on the PostgreSQL server. This defaults to gitlabhq_production .

preparedStatements

If prepared statements should be used when communicating with the PostgreSQL server. Defaults to false .

username

The username with which to authenticate to the database. This defaults to gitlab

password

The password attribute for PostgreSQL has to sub keys:

secret defines the name of the Kubernetes Secret to pull from
key defines the name of the key in the above secret that contains the password.

Read article

Using the Praefect chart (alpha) | GitLab

Known limitations and issues
Requirements
Configuration
- Replicas
- Multiple virtual storages
- Persistence
- Migrating to Praefect
- Creating the database
- Running Praefect over TLS
- Installation command line options

Using the Praefect chart (alpha)

The Praefect chart is still under development. The alpha version is not yet suitable for production use. Upgrades may require significant manual intervention.
See our Praefect GA release Epic for more information.

The Praefect chart is used to manage a Gitaly cluster inside a GitLab installment deployed with the Helm charts.

Known limitations and issues

The database has to be manually created.
The cluster size is fixed: Gitaly Cluster does not currently support autoscaling.
Using a Praefect instance in the cluster to manage Gitaly instances outside the cluster is not supported.
Upgrades to version 4.8 of the chart (GitLab 13.8) will encounter an issue that makes it appear that repository data is lost. Data is not lost, but requires manual intervention.

Requirements

This chart consumes the Gitaly chart. Settings from global.gitaly are used to configure the instances created by this chart. Documentation of these settings can be found in Gitaly chart documentation.

Important : global.gitaly.tls is independent of global.praefect.tls . They are configured separately.

By default, this chart will create 3 Gitaly Replicas.

Configuration

The chart is disabled by default. To enable it as part of a chart deploy set global.praefect.enabled=true .

Replicas

The default number of replicas to deploy is 3. This can be changed by setting global.praefect.virtualStorages[].gitalyReplicas with the desired number of replicas. For example:

      global:
  praefect:
    enabled: true
    virtualStorages:
    - name: default
      gitalyReplicas: 4
      maxUnavailable: 1

     

Multiple virtual storages

Multiple virtual storages can be configured (see Gitaly Cluster documentation). For example:

      global:
  praefect:
    enabled: true
    virtualStorages:
    - name: default
      gitalyReplicas: 4
      maxUnavailable: 1
    - name: vs2
      gitalyReplicas: 5
      maxUnavailable: 2

     

This will create two sets of resources for Gitaly. This includes two Gitaly StatefulSets (one per virtual storage).

Administrators can then configure where new repositories are stored.

Persistence

It is possible to provide persistence configuration per virtual storage.

      global:
  praefect:
    enabled: true
    virtualStorages:
    - name: default
      gitalyReplicas: 4
      maxUnavailable: 1
      persistence:
        enabled: true
        size: 50Gi
        accessMode: ReadWriteOnce
        storageClass: storageclass1
    - name: vs2
      gitalyReplicas: 5
      maxUnavailable: 2
      persistence:
        enabled: true
        size: 100Gi
        accessMode: ReadWriteOnce
        storageClass: storageclass2

     

Migrating to Praefect

Group-level wikis cannot be moved using the API at this time.

When migrating from standalone Gitaly instances to a Praefect setup, global.praefect.replaceInternalGitaly can be set to false .
This ensures that the existing Gitaly instances are preserved while the new Praefect-managed Gitaly instances are created.

      global:
  praefect:
    enabled: true
    replaceInternalGitaly: false
    virtualStorages:
    - name: virtualStorage2
      gitalyReplicas: 5
      maxUnavailable: 2

     

When migrating to Praefect, none of Praefect’s virtual storages can be named


          default

.
This is because there must be at least one storage named


          default

at all times,
therefore the name is already taken by the non-Praefect configuration.

The instructions to migrate to Gitaly Cluster
can then be followed to move data from the default storage to virtualStorage2 . If additional storages
were defined under global.gitaly.internal.names , be sure to migrate repositories from those storages as well.

After the repositories have been migrated to virtualStorage2 , replaceInternalGitaly can be set back to true if a storage named
default is added in the Praefect configuration.

      global:
  praefect:
    enabled: true
    replaceInternalGitaly: true
    virtualStorages:
    - name: default
      gitalyReplicas: 4
      maxUnavailable: 1
    - name: virtualStorage2
      gitalyReplicas: 5
      maxUnavailable: 2

     

The instructions to migrate to Gitaly Cluster
can be followed again to move data from virtualStorage2 to the newly-added default storage if desired.

Finally, see the repository storage paths documentation
to configure where new repositories are stored.

Creating the database

Praefect uses its own database to track its state. This has to be manually created in order for Praefect to be functional.

These instructions assume you are using the bundled PostgreSQL server. If you are using your own server,
there will be some variation in how you connect.

Log into your database instance:

        kubectl exec -it $(kubectl get pods -l app=postgresql -o custom-columns=NAME:.metadata.name --no-headers) -- bash

       

        PGPASSWORD=$(cat $POSTGRES_POSTGRES_PASSWORD_FILE) psql -U postgres -d template1

       

Create the database user:
```
CREATE ROLE praefect WITH LOGIN;
```
Set the database user password.

By default, the shared-secrets Job will generate a secret for you.
1. Fetch the password:
```
kubectl get secret RELEASE_NAME-praefect-dbsecret -o jsonpath="{.data.secret}" | base64 --decode
```
2. Set the password in the psql prompt:
```
\password praefect
```

Create the database:

        CREATE DATABASE praefect WITH OWNER praefect;

       

Running Praefect over TLS

Praefect supports communicating with client and Gitaly nodes over TLS. This is
controlled by the settings global.praefect.tls.enabled and global.praefect.tls.secretName .
To run Praefect over TLS follow these steps:

The Helm chart expects a certificate to be provided for communicating over
TLS with Praefect. This certificate should apply to all the Praefect nodes that
are present. Hence all hostnames of each of these nodes should be added as a
Subject Alternate Name (SAN) to the certificate or alternatively, you can use wildcards.

To know the hostnames to use, check the file /srv/gitlab/config/gitlab.yml
file in the Toolbox Pod and check the various gitaly_address fields specified
under repositories.storages key within it.
```
kubectl exec -it <Toolbox Pod> -- grep gitaly_address /srv/gitlab/config/gitlab.yml
```

A basic script for generating custom signed certificates for internal Praefect Pods
can be found in this repository.
Users can use or refer that script to generate certificates with proper SAN attributes.

Create a TLS Secret using the certificate created.

        kubectl create secret tls <secret name> --cert=praefect.crt --key=praefect.key

       

Redeploy the Helm chart by passing --set global.praefect.tls.enabled=true .

When running Gitaly over TLS, a secret name must be provided for each virtual storage.

      global:
  gitaly:
    tls:
      enabled: true
  praefect:
    enabled: true
    tls:
      enabled: true
      secretName: praefect-tls
    virtualStorages:
    - name: default
      gitalyReplicas: 4
      maxUnavailable: 1
      tlsSecretName: default-tls
    - name: vs2
      gitalyReplicas: 5
      maxUnavailable: 2
      tlsSecretName: vs2-tls

     

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.

Parameter	Default	Description
common.labels	`{}`	Supplemental labels that are applied to all objects created by this chart.
failover.enabled	true	Whether Praefect should perform failover on node failure
failover.readonlyAfter	false	Whether the nodes should be in read-only mode after failover
autoMigrate	true	Automatically run migrations on startup
electionStrategy	`sql`	See election strategy
image.repository	`registry.gitlab.com/gitlab-org/build/cng/gitaly`	The default image repository to use. Praefect is bundled as part of the Gitaly image
podLabels	`{}`	Supplemental Pod labels. Will not be used for selectors.
ntpHost	`pool.ntp.org`	Configure the NTP server Praefect should ask the for the current time.

service.name	`praefect`	The name of the service to create
service.type	ClusterIP	The type of service to create
service.internalPort	8075	The internal port number that the Praefect pod will be listening on
service.externalPort	8075	The port number the Praefect service should expose in the cluster
init.resources
init.image
extraEnvFrom		List of extra environment variables from other data sources to expose
logging.level		Log level
logging.format	`json`	Log format
logging.sentryDsn		Sentry DSN URL - Exceptions from Go server
logging.rubySentryDsn		Sentry DSN URL - Exceptions from `gitaly-ruby`
logging.sentryEnvironment		Sentry environment to be used for logging
`metrics.enabled`	`true`	If a metrics endpoint should be made available for scraping
`metrics.port`	`9236`	Metrics endpoint port
`metrics.separate_database_metrics`	`true`	If true then metrics scrapes will not perform database queries, setting to false may cause performance problems
`metrics.path`	`/metrics`	Metrics endpoint path
`metrics.serviceMonitor.enabled`	`false`	If a ServiceMonitor should be created to enable Prometheus Operator to manage the metrics scraping, note that enabling this removes the `prometheus.io` scrape annotations
`metrics.serviceMonitor.additionalLabels`	`{}`	Additional labels to add to the ServiceMonitor
`metrics.serviceMonitor.endpointConfig`	`{}`	Additional endpoint configuration for the ServiceMonitor
securityContext.runAsUser	1000
securityContext.fsGroup	1000
serviceLabels	`{}`	Supplemental service labels
statefulset.strategy	`{}`	Allows one to configure the update strategy utilized by the statefulset

Read article

Using the GitLab-Sidekiq chart | GitLab

Requirements
Design Choices
Configuration
Installation command line options
Chart configuration examples
- resources
- extraEnv
- extraEnvFrom
- extraVolumes
- extraVolumeMounts
- image.pullSecrets
- tolerations
- annotations
Using the Community Edition of this chart
External Services
- Redis
- PostgreSQL
- Gitaly
Metrics
Chart-wide defaults
Per-pod Settings
- queues
- negateQueues
- Example pod entry
Configuring the networkpolicy
- Example Network Policy

Using the GitLab-Sidekiq chart

The sidekiq sub-chart provides configurable deployment of Sidekiq workers, explicitly
designed to provide separation of queues across multiple Deployment s with individual
scalability and configuration.

While this chart provides a default pods: declaration, if you provide an empty definition,
you will have no workers.

Requirements

This chart depends on access to Redis, PostgreSQL, and Gitaly services, either as
part of the complete GitLab chart or provided as external services reachable from
the Kubernetes cluster this chart is deployed onto.

Design Choices

This chart creates multiple Deployment s and associated ConfigMap s. It was decided
that it would be clearer to make use of ConfigMap behaviours instead of using environment
attributes or additional arguments to the command for the containers, in order to
avoid any concerns about command length. This choice results in a large number of
ConfigMap s, but provides very clear definitions of what each pod should be doing.

Configuration

The sidekiq chart is configured in three parts: chart-wide external services,
chart-wide defaults, and per-pod definitions.

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:

Parameter	Default	Description
`annotations`		Pod annotations
`podLabels`		Supplemental Pod labels. Will not be used for selectors.
`common.labels`		Supplemental labels that are applied to all objects created by this chart.
`concurrency`	`20`	Sidekiq default concurrency
`deployment.strategy`	`{}`	Allows one to configure the update strategy utilized by the deployment
`deployment.terminationGracePeriodSeconds`	`30`	Optional duration in seconds the pod needs to terminate gracefully.
`enabled`	`true`	Sidekiq enabled flag
`extraContainers`		List of extra containers to include
`extraInitContainers`		List of extra init containers to include
`extraVolumeMounts`		String template of extra volume mounts to configure
`extraVolumes`		String template of extra volumes to configure
`extraEnv`		List of extra environment variables to expose
`extraEnvFrom`		List of extra environment variables from other data sources to expose
`gitaly.serviceName`	`gitaly`	Gitaly service name
`health_checks.port`	`3808`	Health check server port
`hpa.behaviour`	`{scaleDown: {stabilizationWindowSeconds: 300 }}`	Behavior contains the specifications for up- and downscaling behavior (requires `autoscaling/v2beta2` or higher)
`hpa.customMetrics`	`[]`	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 `targetAverageUtilization` )
`hpa.cpu.targetType`	`AverageValue`	Set the autoscaling CPU target type, must be either `Utilization` or `AverageValue`
`hpa.cpu.targetAverageValue`	`350m`	Set the autoscaling CPU target value
`hpa.cpu.targetAverageUtilization`		Set the autoscaling CPU target utilization
`hpa.memory.targetType`		Set the autoscaling memory target type, must be either `Utilization` or `AverageValue`
`hpa.memory.targetAverageValue`		Set the autoscaling memory target value
`hpa.memory.targetAverageUtilization`		Set the autoscaling memory target utilization
`hpa.targetAverageValue`		DEPRECATED Set the autoscaling CPU target value
`minReplicas`	`2`	Minimum number of replicas
`maxReplicas`	`10`	Maximum number of replicas
`maxUnavailable`	`1`	Limit of maximum number of Pods to be unavailable
`image.pullPolicy`	`Always`	Sidekiq image pull policy
`image.pullSecrets`		Secrets for the image repository
`image.repository`	`registry.gitlab.com/gitlab-org/build/cng/gitlab-sidekiq-ee`	Sidekiq image repository
`image.tag`		Sidekiq image tag
`init.image.repository`		initContainer image
`init.image.tag`		initContainer image tag
`logging.format`	`default`	Set to `json` for JSON-structured logs
`metrics.enabled`	`true`	If a metrics endpoint should be made available for scraping
`metrics.port`	`3807`	Metrics endpoint port
`metrics.path`	`/metrics`	Metrics endpoint path
`metrics.log_enabled`	`false`	Enables or disables metrics server logs written to `sidekiq_exporter.log`
`metrics.podMonitor.enabled`	`false`	If a PodMonitor should be created to enable Prometheus Operator to manage the metrics scraping
`metrics.podMonitor.additionalLabels`	`{}`	Additional labels to add to the PodMonitor
`metrics.podMonitor.endpointConfig`	`{}`	Additional endpoint configuration for the PodMonitor
`metrics.annotations`		DEPRECATED Set explicit metrics annotations. Replaced by template content.
`metrics.tls.enabled`	`false`	TLS enabled for the metrics/sidekiq_exporter endpoint
`metrics.tls.secretName`	`{Release.Name}-sidekiq-metrics-tls`	Secret for the metrics/sidekiq_exporter endpoint TLS cert and key
`psql.password.key`	`psql-password`	key to psql password in psql secret
`psql.password.secret`	`gitlab-postgres`	psql password secret
`psql.port`		Set PostgreSQL server port. Takes precedence over `global.psql.port`
`redis.serviceName`	`redis`	Redis service name
`resources.requests.cpu`	`900m`	Sidekiq minimum needed CPU
`resources.requests.memory`	`2G`	Sidekiq minimum needed memory
`resources.limits.memory`		Sidekiq maximum allowed memory
`timeout`	`25`	Sidekiq job timeout
`tolerations`	`[]`	Toleration labels for pod assignment
`memoryKiller.daemonMode`	`true`	If `false` , uses the legacy memory killer mode
`memoryKiller.maxRss`	`2000000`	Maximum RSS before delayed shutdown triggered expressed in kilobytes
`memoryKiller.graceTime`	`900`	Time to wait before a triggered shutdown expressed in seconds
`memoryKiller.shutdownWait`	`30`	Amount of time after triggered shutdown for existing jobs to finish expressed in seconds
`memoryKiller.hardLimitRss`		Maximum RSS before immediate shutdown triggered expressed in kilobyte in daemon mode
`memoryKiller.checkInterval`	`3`	Amount of time between memory checks
`livenessProbe.initialDelaySeconds`	`20`	Delay before liveness probe is initiated
`livenessProbe.periodSeconds`	`60`	How often to perform the liveness probe
`livenessProbe.timeoutSeconds`	`30`	When the liveness probe times out
`livenessProbe.successThreshold`	`1`	Minimum consecutive successes for the liveness probe to be considered successful after having failed
`livenessProbe.failureThreshold`	`3`	Minimum consecutive failures for the liveness probe to be considered failed after having succeeded
`readinessProbe.initialDelaySeconds`	`0`	Delay before readiness probe is initiated
`readinessProbe.periodSeconds`	`10`	How often to perform the readiness probe
`readinessProbe.timeoutSeconds`	`2`	When the readiness probe times out
`readinessProbe.successThreshold`	`1`	Minimum consecutive successes for the readiness probe to be considered successful after having failed
`readinessProbe.failureThreshold`	`3`	Minimum consecutive failures for the readiness probe to be considered failed after having succeeded
`securityContext.fsGroup`	`1000`	Group ID under which the pod should be started
`securityContext.runAsUser`	`1000`	User ID under which the pod should be started
`priorityClassName`	`""`	Allow configuring pods `priorityClassName` , this is used to control pod priority in case of eviction

Chart configuration examples

resources

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

Sidekiq pod workloads vary greatly between deployments. Generally speaking, it is understood that each Sidekiq
process consumes approximately 1 vCPU and 2 GB of memory. Vertical scaling should generally align to this 1:2
ratio of vCPU:Memory .

Below is an example use of resources :

      resources:
  limits:
    memory: 5G
  requests:
    memory: 2G
    cpu: 900m

     

extraEnv

extraEnv allows you to expose additional environment variables in the dependencies container.

Below is an example use of extraEnv :

      extraEnv:
  SOME_KEY: some_value
  SOME_OTHER_KEY: some_other_value

     

When the container is started, you can confirm that the environment variables are exposed:

      env | grep SOME
SOME_KEY=some_value
SOME_OTHER_KEY=some_other_value

     

You can also set extraEnv for a specific pod:

      extraEnv:
  SOME_KEY: some_value
  SOME_OTHER_KEY: some_other_value
pods:
  - name: mailers
    queues: mailers
    extraEnv:
      SOME_POD_KEY: some_pod_value
  - name: catchall
    negateQueues: mailers

     

This will set SOME_POD_KEY only for application containers in the mailers
pod. Pod-level extraEnv settings are not added to init containers.

extraEnvFrom

extraEnvFrom allows you to expose additional environment variables from other data sources in all containers in the pods.

Below is an example use of extraEnvFrom :

      extraEnvFrom:
  MY_NODE_NAME:
    fieldRef:
      fieldPath: spec.nodeName
  MY_CPU_REQUEST:
    resourceFieldRef:
      containerName: test-container
      resource: requests.cpu
  SECRET_THING:
    secretKeyRef:
      name: special-secret
      key: special_token
      # optional: boolean
  CONFIG_STRING:
    configMapKeyRef:
      name: useful-config
      key: some-string
      # optional: boolean

     

extraVolumes

extraVolumes allows you to configure extra volumes chart-wide.

Below is an example use of extraVolumes :

      extraVolumes: |
  - name: example-volume
    persistentVolumeClaim:
      claimName: example-pvc

     

extraVolumeMounts

extraVolumeMounts allows you to configure extra volumeMounts on all containers chart-wide.

Below is an example use of extraVolumeMounts :

      extraVolumeMounts: |
  - name: example-volume-mount
    mountPath: /etc/example

     

image.pullSecrets

pullSecrets allows you to authenticate to a private registry to pull images for a pod.

Additional details about private registries and their authentication methods can be
found in the Kubernetes documentation.

Below is an example use of pullSecrets :

      image:
  repository: my.sidekiq.repository
  pullPolicy: Always
  pullSecrets:
  - name: my-secret-name
  - name: my-secondary-secret-name

     

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 Sidekiq pods.

Below is an example use of annotations :

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

Using the Community Edition of this chart

By default, the Helm charts use the Enterprise Edition of GitLab. If desired, you
can use the Community Edition instead. Learn more about the
differences between the two.

In order to use the Community Edition, set image.repository to
registry.gitlab.com/gitlab-org/build/cng/gitlab-sidekiq-ce .

External Services

This chart should be attached to the same Redis, PostgreSQL, and Gitaly instances
as the Webservice chart. The values of external services will be populated into a ConfigMap
that is shared across all Sidekiq pods.

Redis

      redis:
  host: rank-racoon-redis
  port: 6379
  sentinels:
    - host: sentinel1.example.com
      port: 26379
  password:
    secret: gitlab-redis
    key: redis-password

     

Name	Type	Default	Description
`host`	String		The hostname of the Redis server with the database to use. This can be omitted in lieu of `serviceName` . If using Redis Sentinels, the `host` attribute needs to be set to the cluster name as specified in the `sentinel.conf` .
`password.key`	String		The `password.key` attribute for Redis defines the name of the key in the secret (below) that contains the password.
`password.secret`	String		The `password.secret` attribute for Redis defines the name of the Kubernetes `Secret` to pull from.
`port`	Integer	`6379`	The port on which to connect to the Redis server.
`serviceName`	String	`redis`	The name of the `service` which is operating the Redis database. If this is present, and `host` is not, the chart will template the hostname of the service (and current `.Release.Name` ) in place of the `host` value. This is convenient when using Redis as a part of the overall GitLab chart.
`sentinels.[].host`	String		The hostname of Redis Sentinel server for a Redis HA setup.
`sentinels.[].port`	Integer	`26379`	The port on which to connect to the Redis Sentinel server.

The current Redis Sentinel support only supports Sentinels that have
been deployed separately from the GitLab chart. As a result, the Redis
deployment through the GitLab chart should be disabled with


          redis.install=false

.
The Secret containing the Redis password needs to be manually created
before deploying the GitLab chart.

PostgreSQL

      psql:
  host: rank-racoon-psql
  serviceName: pgbouncer
  port: 5432
  database: gitlabhq_production
  username: gitlab
  preparedStatements: false
  password:
    secret: gitlab-postgres
    key: psql-password

     

Name	Type	Default	Description
`host`	String		The hostname of the PostgreSQL server with the database to use. This can be omitted if `postgresql.install=true` (default non-production).
`serviceName`	String		The name of the `service` which is operating the PostgreSQL database. If this is present, and `host` is not, the chart will template the hostname of the service in place of the `host` value.
`database`	String	`gitlabhq_production`	The name of the database to use on the PostgreSQL server.
`password.key`	String		The `password.key` attribute for PostgreSQL defines the name of the key in the secret (below) that contains the password.
`password.secret`	String		The `password.secret` attribute for PostgreSQL defines the name of the Kubernetes `Secret` to pull from.
`port`	Integer	`5432`	The port on which to connect to the PostgreSQL server.
`username`	String	`gitlab`	The username with which to authenticate to the database.
`preparedStatements`	Boolean	`false`	If prepared statements should be used when communicating with the PostgreSQL server.

Gitaly

gitaly:
  internal:
    names:
      - default
      - default2
  external:
    - name: node1
      hostname: node1.example.com
      port: 8079
  authToken:
    secret: gitaly-secret
    key: token

Name	Type	Default	Description
`host`	String		The hostname of the Gitaly server to use. This can be omitted in lieu of `serviceName` .
`serviceName`	String	`gitaly`	The name of the `service` which is operating the Gitaly server. If this is present, and `host` is not, the chart will template the hostname of the service (and current `.Release.Name` ) in place of the `host` value. This is convenient when using Gitaly as a part of the overall GitLab chart.
`port`	Integer	`8075`	The port on which to connect to the Gitaly server.
`authToken.key`	String		The name of the key in the secret below that contains the authToken.
`authToken.secret`	String		The name of the Kubernetes `Secret` to pull from.

Metrics

By default, a Prometheus metrics exporter is enabled per pod. Metrics are only available
when GitLab Prometheus metrics
are enabled in the Admin area. The exporter exposes a /metrics endpoint on port
3807 . When metrics are enabled, annotations are added to each pod allowing a Prometheus
server to discover and scrape the exposed metrics.

Chart-wide defaults

The following values will be used chart-wide, in the event that a value is not presented
on a per-pod basis.

Name	Type	Default	Description
`concurrency`	Integer	`25`	The number of tasks to process simultaneously.
`timeout`	Integer	`4`	The Sidekiq shutdown timeout. The number of seconds after Sidekiq gets the TERM signal before it forcefully shuts down its processes.
`memoryKiller.checkInterval`	Integer	`3`	Amount of time in seconds between memory checks
`memoryKiller.maxRss`	Integer	`2000000`	Maximum RSS before delayed shutdown triggered expressed in kilobytes
`memoryKiller.graceTime`	Integer	`900`	Time to wait before a triggered shutdown expressed in seconds
`memoryKiller.shutdownWait`	Integer	`30`	Amount of time after triggered shutdown for existing jobs to finish expressed in seconds
`minReplicas`	Integer	`2`	Minimum number of replicas
`maxReplicas`	Integer	`10`	Maximum number of replicas
`maxUnavailable`	Integer	`1`	Limit of maximum number of Pods to be unavailable

Detailed documentation of the Sidekiq memory killer is available
in the Omnibus documentation.

Per-pod Settings

The pods declaration provides for the declaration of all attributes for a worker
pod. These will be templated to Deployment s, with individual ConfigMap s for their
Sidekiq instances.

The settings default to including a single pod that is set up to monitor
all queues. Making changes to the pods section will overwrite the default pod with
a different pod configuration. It will not add a new pod in addition to the default.

Name	Type	Default	Description
`concurrency`	Integer		The number of tasks to process simultaneously. If not provided, it will be pulled from the chart-wide default.
`name`	String		Used to name the `Deployment` and `ConfigMap` for this pod. It should be kept short, and should not be duplicated between any two entries.
`queues`	String		See below.
`negateQueues`	String		See below.
`queueSelector`	Boolean	`false`	Use the queue selector.
`timeout`	Integer		The Sidekiq shutdown timeout. The number of seconds after Sidekiq gets the TERM signal before it forcefully shuts down its processes. If not provided, it will be pulled from the chart-wide default. This value must be less than `terminationGracePeriodSeconds` .
`resources`			Each pod can present it’s own `resources` requirements, which will be added to the `Deployment` created for it, if present. These match the Kubernetes documentation.
`nodeSelector`			Each pod can be configured with a `nodeSelector` attribute, which will be added to the `Deployment` created for it, if present. These definitions match the Kubernetes documentation.
`memoryKiller.checkInterval`	Integer	`3`	Amount of time between memory checks
`memoryKiller.maxRss`	Integer	`2000000`	Overrides the maximum RSS for a given pod.
`memoryKiller.graceTime`	Integer	`900`	Overrides the time to wait before a triggered shutdown for a given Pod
`memoryKiller.shutdownWait`	Integer	`30`	Overrides the amount of time after triggered shutdown for existing jobs to finish for a given Pod
`minReplicas`	Integer	`2`	Minimum number of replicas
`maxReplicas`	Integer	`10`	Maximum number of replicas
`maxUnavailable`	Integer	`1`	Limit of maximum number of Pods to be unavailable
`podLabels`	Map	`{}`	Supplemental Pod labels. Will not be used for selectors.
`strategy`		`{}`	Allows one to configure the update strategy utilized by the deployment
`extraVolumes`	String		Configures extra volumes for the given pod.
`extraVolumeMounts`	String		Configures extra volume mounts for the given pod.
`priorityClassName`	String	`""`	Allow configuring pods `priorityClassName` , this is used to control pod priority in case of eviction
`hpa.customMetrics`	Array	`[]`	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 `targetAverageUtilization` )
`hpa.cpu.targetType`	String	`AverageValue`	Overrides the autoscaling CPU target type, must be either `Utilization` or `AverageValue`
`hpa.cpu.targetAverageValue`	String	`350m`	Overrides the autoscaling CPU target value
`hpa.cpu.targetAverageUtilization`	Integer		Overrides the autoscaling CPU target utilization
`hpa.memory.targetType`	String		Overrides the autoscaling memory target type, must be either `Utilization` or `AverageValue`
`hpa.memory.targetAverageValue`	String		Overrides the autoscaling memory target value
`hpa.memory.targetAverageUtilization`	Integer		Overrides the autoscaling memory target utilization
`hpa.targetAverageValue`	String		DEPRECATED Overrides the autoscaling CPU target value
`extraEnv`	Map		List of extra environment variables to expose. The chart-wide value is merged into this, with values from the pod taking precedence
`extraEnvFrom`	Map		List of extra environment variables from other data source to expose
`terminationGracePeriodSeconds`	Integer	`30`	Optional duration in seconds the pod needs to terminate gracefully.

queues

The queues value is a string containing a comma-separated list of queues to be
processed. By default, it is not set, meaning that all queues will be processed.

The string should not contain spaces: merge,post_receive,process_commit will
work, but merge, post_receive, process_commit will not.

Any queue to which jobs are added but are not represented as a part of at least
one pod item will not be processed . For a complete list of all queues, see
these files in the GitLab source:

app/workers/all_queues.yml
ee/app/workers/all_queues.yml

negateQueues

negateQueues is in the same format as queues , but it represents
queues to be ignored rather than processed.

The string should not contain spaces: merge,post_receive,process_commit will
work, but merge, post_receive, process_commit will not.

This is useful if you have a pod processing important queues, and another pod
processing other queues: they can use the same list of queues, with one being in
queues and the other being in negateQueues .


          negateQueues

should not be provided alongside


          queues

, as it will have no effect.

Example `pod` entry

pods:
  - name: immediate
    concurrency: 10
    minReplicas: 2  # defaults to inherited value
    maxReplicas: 10 # defaults to inherited value
    maxUnavailable: 5 # defaults to inherited value
    queues: merge,post_receive,process_commit
    extraVolumeMounts: |
      - name: example-volume-mount
        mountPath: /etc/example
    extraVolumes: |
      - name: example-volume
        persistentVolumeClaim:
          claimName: example-pvc
    resources:
      limits:
        cpu: 800m
        memory: 2Gi
    hpa:
      cpu:
        targetType: Value
        targetAverageValue: 350m

Configuring the `networkpolicy`

This section controls the
NetworkPolicy.
This configuration is optional and is used to limit Egress and Ingress of the
Pods to specific endpoints.

Name	Type	Default	Description
`enabled`	Boolean	`false`	This setting enables the network policy
`ingress.enabled`	Boolean	`false`	When set to `true` , the `Ingress` network policy will be activated. This will block all Ingress connections unless rules are specified.
`ingress.rules`	Array	`[]`	Rules for the Ingress policy, for details see https://kubernetes.io/docs/concepts/services-networking/network-policies/#the-networkpolicy-resource and the example below
`egress.enabled`	Boolean	`false`	When set to `true` , the `Egress` network policy will be activated. This will block all egress connections unless rules are specified.
`egress.rules`	Array	`[]`	Rules for the egress policy, these for details see https://kubernetes.io/docs/concepts/services-networking/network-policies/#the-networkpolicy-resource and the example below

Example Network Policy

The Sidekiq service requires Ingress connections for only the Prometheus
exporter if enabled, and normally requires Egress connections to various
places. This examples adds the following network policy:

All Ingress requests from the network on TCP 10.0.0.0/8 port 3807 are allowed for metrics exporting
All Egress requests to the network on UDP 10.0.0.0/8 port 53 are allowed for DNS
All Egress requests to the network on TCP 10.0.0.0/8 port 5432 are allowed for PostgreSQL
All Egress requests to the network on TCP 10.0.0.0/8 port 6379 are allowed for Redis
Other Egress requests to the local network on 10.0.0.0/8 are restricted
Egress requests outside of the 10.0.0.0/8 are allowed

Note the example provided is only an example and may not be complete

Note that the Sidekiq service requires outbound connectivity to the public
internet for images on external object storage

      networkpolicy:
  enabled: true
  ingress:
    enabled: true
    rules:
      - from:
        - ipBlock:
            cidr: 10.0.0.0/8
        ports:
        - port: 3807
  egress:
    enabled: true
    rules:
      - to:
        - ipBlock:
            cidr: 10.0.0.0/8
        ports:
        - port: 53
          protocol: UDP
      - to:
        - ipBlock:
            cidr: 10.0.0.0/8
        ports:
        - port: 5432
          protocol: TCP
      - to:
        - ipBlock:
            cidr: 10.0.0.0/8
        ports:
        - port: 6379
          protocol: TCP
      - to:
        - ipBlock:
            cidr: 0.0.0.0/0
            except:
            - 10.0.0.0/8

     

Read article

Welcome to Knowledge Base!

KB at your finger tips

DevOps-GitLab