DevOps-GitLab

Using the GitLab Runner chart | GitLab

Requirements
Configuration
Deploying a stand-alone runner
Using Docker-in-Docker
- Security concerns
Installation command line options
Default runner configuration
Chart configuration examples

Using the GitLab Runner chart

The GitLab Runner subchart provides a GitLab Runner for running CI jobs. It is enabled by default and should work out of the box with support for caching using s3 compatible object storage.

Requirements

This chart depends on the shared-secrets Job to populate its registrationToken for automatic registration. If you intend to run this chart as a stand-alone chart with an existing GitLab instance then you will need to manually set the registrationToken in the gitlab-runner secret to be equal to that displayed by the running GitLab instance.

Configuration

There are no required settings, it should work out of the box if you deploy all of the charts together.

Deploying a stand-alone runner

By default we do infer gitlabUrl , automatically generate a registration token, and generate it through the migrations chart. This behavior will not work if you intend to deploy it with a running GitLab instance.

In this case you will need to set gitlabUrl value to be the URL of the running GitLab instance. You will also need to manually create gitlab-runner secret and fill it with the registrationToken provided by the running GitLab.

Using Docker-in-Docker

In order to run Docker-in-Docker, the runner container needs to be privileged to have access to the needed capabilities. To enable it set the privileged value to true . See the upstream documentation in regards to why this is does not default to true .

Security concerns

Privileged containers have extended capabilities, for example they can mount arbitrary files from the host they run on. Make sure to run the container in an isolated environment such that nothing important runs beside it.

Installation command line options

Parameter	Description	Default
`gitlab-runner.image`	Runner image	`gitlab/gitlab-runner:alpine-v10.5.0`
`gitlab-runner.gitlabUrl`	URL that the Runner uses to register to GitLab Server	GitLab external URL
`gitlab-runner.install`	Install the `gitlab-runner` chart	`true`
`gitlab-runner.imagePullPolicy`	Image pull policy	`IfNotPresent`
`gitlab-runner.init.image.repository`	`initContainer` image
`gitlab-runner.init.image.tag`	`initContainer` image tag
`gitlab-runner.pullSecrets`	Secrets for the image repository
`gitlab-runner.unregisterRunners`	Unregister all runners before termination	`true`
`gitlab-runner.concurrent`	Number of concurrent jobs	`20`
`gitlab-runner.checkInterval`	Polling interval	`30s`
`gitlab-runner.rbac.create`	Whether to create RBAC service account	`true`
`gitlab-runner.rbac.clusterWideAccess`	Deploy containers of jobs cluster-wide	`false`
`gitlab-runner.rbac.serviceAccountName`	Name of the RBAC service account to create	`default`
`gitlab-runner.runners.privileged`	Run in privileged mode, needed for `dind`	`false`
`gitlab-runner.runners.cache.secretName`	Secret to access key and secret key from	`gitlab-minio`
`gitlab-runner.runners.config`	Runner configuration as string	See below
`gitlab-runner.resources.limits.cpu`	Runner CPU limit
`gitlab-runner.resources.limits.memory`	Runner memory limit
`gitlab-runner.resources.requests.cpu`	Runner requested CPU
`gitlab-runner.resources.requests.memory`	Runner requested memory

Default runner configuration

The default runner configuration used in the GitLab chart has been customized to use the included MinIO for cache by default. If you are setting the runner config value, you will need to also configure your own cache configuration.

      gitlab-runner:
  runners:
    config: |
      [[runners]]
        [runners.kubernetes]
        image = "ubuntu:18.04"
        {{- if .Values.global.minio.enabled }}
        [runners.cache]
          Type = "s3"
          Path = "gitlab-runner"
          Shared = true
          [runners.cache.s3]
            ServerAddress = {{ include "gitlab-runner.cache-tpl.s3ServerAddress" . }}
            BucketName = "runner-cache"
            BucketLocation = "us-east-1"
            Insecure = false
        {{ end }}

     

Chart configuration examples

Runners configuration to use only custom nameservers (exclude any cluster or host nameservers):

      gitlab-runner:
  runners:
    config: |
      [[runners]]
        [runners.kubernetes]
          image = "ubuntu:18.04"
          dns_policy = "none"
        [runners.kubernetes.dns_config]
          nameservers = ["8.8.8.8"]

     

See the Runner chart additional configuration.

Using the GitLab Shell chart | GitLab

Requirements
Design Choices
Configuration
Installation command line options
Chart configuration examples
- extraEnv
- extraEnvFrom
- image.pullSecrets
- livenessProbe/readinessProbe
- tolerations
- annotations
External Services
- Workhorse
Chart settings
- hostKeys.secret
- authToken
- LoadBalancer Service
- Configuring the networkpolicy
- Example Network Policy

Using the GitLab Shell chart

The gitlab-shell sub-chart provides an SSH server configured for Git SSH access to GitLab.

Requirements

This chart depends on access to the Workhorse services, either as part of the
complete GitLab chart or provided as an external service reachable from the Kubernetes
cluster this chart is deployed onto.

Design Choices

In order to easily support SSH replicas, and avoid using shared storage for the SSH
authorized keys, we are using the SSH AuthorizedKeysCommand
to authenticate against the GitLab authorized keys endpoint. As a result, we don’t persist
or update the AuthorizedKeys file within these pods.

Configuration

The gitlab-shell chart is configured in two parts: external services,
and chart settings. The port exposed through Ingress is configured
with global.shell.port , and defaults to 22 . The Service’s external port is also
controlled by global.shell.port .

Installation command line options

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.
`config.clientAliveInterval`	`0`	Interval between keepalive pings on otherwise idle connections; the default value of 0 disables this ping
`config.loginGraceTime`	`60`	Specifies amount of time that the server will disconnect after if the user has not successfully logged in
`config.maxStartups.full`	`100`	SSHd refuse probability will increase linearly and all unauthenticated connection attempts would be refused when unauthenticated connections number will reach specified number
`config.maxStartups.rate`	`30`	SSHd will refuse connections with specified probability when there would be too many unauthenticated connections (optional)
`config.maxStartups.start`	`10`	SSHd will refuse connection attempts with some probability if there are currently more than the specified number of unauthenticated connections (optional)
`config.proxyProtocol`	`false`	Enable PROXY protocol support for the `gitlab-sshd` daemon
`config.proxyPolicy`	`"use"`	Specify policy for handling PROXY protocol. Value must be one of `use, require, ignore, reject`
`config.proxyHeaderTimeout`	`"500ms"`	The maximum duration `gitlab-sshd` will wait before giving up on reading the PROXY protocol header. Must include units: `ms` , `s` , or `m` .
`config.ciphers`	`[aes128-gcm@openssh.com, chacha20-poly1305@openssh.com, aes256-gcm@openssh.com, aes128-ctr, aes192-ctr, aes256-ctr]`	Specify the ciphers allowed.
`config.kexAlgorithms`	`[curve25519-sha256, curve25519-sha256@libssh.org, ecdh-sha2-nistp256, ecdh-sha2-nistp384, ecdh-sha2-nistp521, diffie-hellman-group14-sha256, diffie-hellman-group14-sha1]`	Specifies the available KEX (Key Exchange) algorithms.
`config.macs`	`[hmac-sha2-256-etm@openssh.com, hmac-sha2-512-etm@openssh.com, hmac-sha2-256, hmac-sha2-512, hmac-sha1]`	Specifies the available MAC (message authentication code algorithms.
`deployment.livenessProbe.initialDelaySeconds`	10	Delay before liveness probe is initiated
`deployment.livenessProbe.periodSeconds`	10	How often to perform the liveness probe
`deployment.livenessProbe.timeoutSeconds`	3	When the liveness probe times out
`deployment.livenessProbe.successThreshold`	1	Minimum consecutive successes for the liveness probe to be considered successful after having failed
`deployment.livenessProbe.failureThreshold`	3	Minimum consecutive failures for the liveness probe to be considered failed after having succeeded
`deployment.readinessProbe.initialDelaySeconds`	10	Delay before readiness probe is initiated
`deployment.readinessProbe.periodSeconds`	5	How often to perform the readiness probe
`deployment.readinessProbe.timeoutSeconds`	3	When the readiness probe times out
`deployment.readinessProbe.successThreshold`	1	Minimum consecutive successes for the readiness probe to be considered successful after having failed
`deployment.readinessProbe.failureThreshold`	2	Minimum consecutive failures for the readiness probe to be considered failed after having succeeded
`deployment.strategy`	`{}`	Allows one to configure the update strategy utilized by the deployment
`deployment.terminationGracePeriodSeconds`	30	Seconds that Kubernetes will wait for a pod to forcibly exit
`enabled`	`true`	Shell enable flag
`extraContainers`		List of extra containers to include
`extraInitContainers`		List of extra init containers to include
`extraVolumeMounts`		List of extra volumes mounts to do
`extraVolumes`		List of extra volumes to create
`extraEnv`		List of extra environment variables to expose
`extraEnvFrom`		List of extra environment variables from other data sources to expose
`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
`image.pullPolicy`	`IfNotPresent`	Shell image pull policy
`image.pullSecrets`		Secrets for the image repository
`image.repository`	`registry.com/gitlab-org/build/cng/gitlab-shell`	Shell image repository
`image.tag`	`master`	Shell image tag
`init.image.repository`		initContainer image
`init.image.tag`		initContainer image tag
`logging.format`	`text`	Set to `json` for JSON-structured logs
`logging.sshdLogLevel`	`ERROR`	Log level for underlying SSH daemon
`priorityClassName`		Priority class assigned to pods.
`replicaCount`	`1`	Shell replicas
`serviceLabels`	`{}`	Supplemental service labels
`service.externalTrafficPolicy`	`Cluster`	Shell service external traffic policy (Cluster or Local)
`service.internalPort`	`2222`	Shell internal port
`service.nodePort`		Sets shell nodePort if set
`service.name`	`gitlab-shell`	Shell service name
`service.type`	`ClusterIP`	Shell service type
`service.loadBalancerIP`		IP address to assign to LoadBalancer (if supported)
`service.loadBalancerSourceRanges`		List of IP CIDRs allowed access to LoadBalancer (if supported)
`securityContext.fsGroup`	`1000`	Group ID under which the pod should be started
`securityContext.runAsUser`	`1000`	User ID under which the pod should be started
`sshDaemon`	`openssh`	Selects which SSH daemon would be run, possible values ( `openssh` , `gitlab-sshd` )
`tolerations`	`[]`	Toleration labels for pod assignment
`workhorse.serviceName`	`webservice`	Workhorse service name (by default, Workhorse is a part of the webservice Pods / Service)
`metrics.enabled`	`false`	If a metrics endpoint should be made available for scraping
`metrics.port`	`9122`	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, 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
`metrics.annotations`		DEPRECATED Set explicit metrics annotations. Replaced by template content.

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 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.shell.repository
  tag: latest
  pullPolicy: Always
  pullSecrets:
  - name: my-secret-name
  - name: my-secondary-secret-name

     

livenessProbe/readinessProbe

deployment.livenessProbe and deployment.readinessProbe provide a mechanism
to help control the termination of Pods under some scenarios.

Larger repositories benefit from tuning liveness and readiness probe
times to match their typical long-running connections. Set readiness
probe duration shorter than liveness probe duration to minimize
potential interruptions during clone and push operations. Increase
terminationGracePeriodSeconds and give these operations more time before
the scheduler terminates the pod. Consider the example below as a starting
point to tune GitLab Shell pods for increased stability and efficiency
with larger repository workloads.

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

     

Reference the official Kubernetes Documentation
for additional details regarding this configuration.

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 GitLab Shell pods.

Below is an example use of annotations

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

External Services

This chart should be attached the Workhorse service.

Workhorse

      workhorse:
  host: workhorse.example.com
  serviceName: webservice
  port: 8181

     

Name	Type	Default	Description
`host`	String		The hostname of the Workhorse server. This can be omitted in lieu of `serviceName` .
`port`	Integer	`8181`	The port on which to connect to the Workhorse server.
`serviceName`	String	`webservice`	The name of the `service` which is operating the Workhorse server. By default, Workhorse is a part of the webservice Pods / Service. 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 Workhorse as a part of the overall GitLab chart.

Chart settings

The following values are used to configure the GitLab Shell Pods.

hostKeys.secret

The name of the Kubernetes secret to grab the SSH host keys from. The keys in the
secret must start with the key names ssh_host_ in order to be used by GitLab Shell.

authToken

GitLab Shell uses an Auth Token in its communication with Workhorse. Share the token
with GitLab Shell and Workhorse using a shared Secret.

      authToken:
 secret: gitlab-shell-secret
 key: secret

     

Name	Type	Default	Description
`authToken.key`	String		The name of the key in the above secret that contains the auth token.
`authToken.secret`	String		The name of the Kubernetes `Secret` to pull from.

LoadBalancer Service

If the service.type is set to LoadBalancer , you can optionally specify service.loadBalancerIP to create
the LoadBalancer with a user-specified IP (if your cloud provider supports it).

You can also optionally specify a list of service.loadBalancerSourceRanges to restrict
the CIDR ranges that can access the LoadBalancer (if your cloud provider supports it).

Additional information about the LoadBalancer service type can be found in
the Kubernetes documentation

      service:
  type: LoadBalancer
  loadBalancerIP: 1.2.3.4
  loadBalancerSourceRanges:
  - 5.6.7.8/32
  - 10.0.0.0/8

     

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 `NetworkPolicy`
`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 gitlab-shell service requires Ingress connections for port 22 and Egress
connections to various to default workhorse port 8181. This examples adds the
following network policy:

All Ingress requests from the network on TCP 0.0.0.0/0 port 2222 are allowed
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 8181 are allowed for Workhorse
All Egress requests to the network on TCP 10.0.0.0/8 port 8075 are allowed for Gitaly

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

      networkpolicy:
  enabled: true
  ingress:
    enabled: true
    rules:
      - from:
        - ipBlock:
            cidr: 0.0.0.0/0
        ports:
          - port: 2222
            protocol: TCP
  egress:
    enabled: true
    rules:
      - to:
        - ipBlock:
            cidr: 10.0.0.0/8
        ports:
          - port: 8181
            protocol: TCP
          - port: 8075
            protocol: TCP
          - port: 53
            protocol: UDP

     

Read article

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

Read article

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

Welcome to Knowledge Base!

KB at your finger tips

DevOps-GitLab