tree: 14934c7037e350adca4d58e115b07de0a38bb633 [path history] [tgz]
  1. .helmignore
  2. Chart.yaml
  5. docs/
  6. supplements/
  7. templates/
  8. values.yaml

Gerrit slave on Kubernetes

Gerrit is a web-based code review tool, which acts as a Git server. On large setups Gerrit servers can see a sizable amount of traffic from git operations performed by developers and build servers. The major part of requests are read-only requests (e.g. by git fetch operations). To take some load of the Gerrit master server, Gerrit slaves can be deployed to serve read-only requests.

This helm chart provides a Gerrit slave setup that can be deployed on Kubernetes. The Gerrit slave is capable of receiving replicated git repositories from a Gerrit master. The Gerrit slave can then serve authenticated read-only requests.

Gerrit versions before 3.0 are no longer supported, since the support of ReviewDB was removed.


  • Helm and Tiller (of course)

    (Check out this guide how to install and use helm.)

  • Access to a provisioner for persistent volumes with Read Write Many (RWM)- capability.

    A list of applicaple volume types can be found here. This project was developed using the NFS-server-provisioner helm chart, a NFS-provisioner deployed in the Kubernetes cluster itself. Refer to this guide of how to deploy it in context of this project.

  • A domain name that is configured to point to the IP address of the node running the Ingress controller on the kubernetes cluster (as described here).

  • (Optional: Required, if SSL is configured) A Java keystore to be used by Gerrit.

Installing the Chart

ATTENTION: The value for is required for rendering the chart's templates. The nature of the value does not allow defaults. Thus a custom values.yaml-file setting this value is required!

To install the chart with the release name gerrit-slave, execute:

cd $(git rev-parse --show-toplevel)/helm-charts
helm install ./gerrit-slave \
  -n gerrit-slave \
  -f <path-to-custom-values>.yaml

The command deploys the Gerrit slave on the current Kubernetes cluster. The configuration section lists the parameters that can be configured during installation.

The Gerrit slave requires the replicated All-Projects.git- and All-Users.git- repositories to be present in the /var/gerrit/git-directory. The gerrit-init- InitContainer will wait for this being the case. A way to do this is to access the Gerrit slave pod and to clone the repositories from the Gerrit master (Make sure that you have the correct access rights do so.):

kubectl exec -it <gerrit-slave-pod> -c gerrit-init ash
gerrit@<gerrit-slave-pod>:/var/tools$ cd /var/gerrit/git
gerrit@<gerrit-slave-pod>:/var/gerrit/git$ git clone "" --mirror
Cloning into bare repository 'All-Projects.git'...
gerrit@<gerrit-slave-pod>:/var/gerrit/git$ git clone "" --mirror
Cloning into bare repository 'All-Users.git'...


The following sections list the configurable values in values.yaml. To configure a Gerrit slave setup, make a copy of the values.yaml-file and change the parameters as needed. The configuration can be applied by installing the chart as described above.

In addition, single options can be set without creating a custom values.yaml:

cd $(git rev-parse --show-toplevel)/helm-charts
helm install ./gerrit-slave \
  -n gerrit-slave \

Container images

images.registry.nameThe image registry to pull the container images from``
images.registry.ImagePullSecret.nameName of the ImagePullSecretimage-pull-secret (if empty no image pull secret will be deployed)
images.registry.ImagePullSecret.createWhether to create an ImagePullSecretfalse
images.registry.ImagePullSecret.usernameThe image registry usernamenil
images.registry.ImagePullSecret.passwordThe image registry passwordnil
images.versionThe image version (image tag) to uselatest
images.imagePullPolicyImage pull policyAlways

Storage classes

For information of how a StorageClass is configured in Kubernetes, read the official Documentation.

storageClasses.default.nameThe name of the default StorageClass (RWO)default
storageClasses.default.createWhether to create the StorageClassfalse
storageClasses.default.provisionerProvisioner of the
storageClasses.default.reclaimPolicyWhether to Retain or Delete volumes, when they become unboundDelete
storageClasses.default.parametersParameters for the provisionerparameters.type: gp2, parameters.fsType: ext4
storageClasses.shared.nameThe name of the shared StorageClass (RWM)shared-storage
storageClasses.shared.createWhether to create the StorageClassfalse
storageClasses.shared.provisionerProvisioner of the StorageClassnfs
storageClasses.shared.reclaimPolicyWhether to Retain or Delete volumes, when they become unboundDelete
storageClasses.shared.parametersParameters for the provisionerparameters.mountOptions: vers=4.1

Storage for Git repositories

gitRepositoryStorage.sizeSize of the volume storing the Git repositories5Gi

Apache-Git-HTTP-Backend (Git-Backend)

gitBackend.imageImage name of the Apache-git-http-backend container imagek8s-gerrit/apache-git-http-backend
gitBackend.replicasNumber of pod replicas to deploy1
gitBackend.maxSurgeMax. percentage or number of pods allowed to be scheduled above the desired number25%
gitBackend.maxUnavailableMax. percentage or number of pods allowed to be unavailable at a time100%
gitBackend.resourcesConfigure the amount of resources the pod requests/is allowedrequests.cpu: 100m
requests.memory: 256Mi
limits.cpu: 100m
limits.memory: 256Mi
gitBackend.credentials.htpasswd.htpasswd-file containing username/password-credentials for accessing gitgit:$apr1$O/LbLKC7$Q60GWE7OcqSEMSfe/K8xU. (user: git, password: secret)
gitBackend.logging.persistence.enabledWhether to persist logstrue
gitBackend.logging.persistence.sizeStorage size for persisted logs1Gi
gitBackend.service.typeWhich kind of Service to deployLoadBalancer
gitBackend.service.http.enabledWhether to serve HTTP-requests (needed for Ingress)true
gitBackend.service.http.portPort over which to expose HTTP80
gitBackend.service.https.enabledWhether to serve HTTPS-requestsfalse
gitBackend.service.https.portPort over which to expose HTTPS443
gitBackend.service.https.certPublic SSL server certificate-----BEGIN CERTIFICATE-----
gitBackend.service.https.keyPrivate SSL server certificate-----BEGIN RSA PRIVATE KEY-----
gitBackend.ingress.enabledWhether to deploy an Ingressfalse
gitBackend.ingress.hostHost name to use for the Ingress (required for Ingress)nil
gitBackend.ingress.maxBodySizeMaximum request body size allowed (Set to 0 for an unlimited request body size)50m
gitBackend.ingress.additionalAnnotationsAdditional annotations for the Ingressnil
gitBackend.ingress.tls.enabledWhether to enable TLS termination in the Ingressfalse
gitBackend.ingress.tls.certPublic SSL server certificate-----BEGIN CERTIFICATE-----
gitBackend.ingress.tls.keyPrivate SSL server certificate-----BEGIN RSA PRIVATE KEY-----
At least one endpoint (HTTP and/or HTTPS) has to be enabled in the service!

Git garbage collection

gitGC.imageImage name of the Git-GC container imagek8s-gerrit/git-gc
gitGC.scheduleCron-formatted schedule with which to run Git garbage collection0 6,18 * * *
gitGC.resourcesConfigure the amount of resources the pod requests/is allowedrequests.cpu: 100m
requests.memory: 256Mi
limits.cpu: 100m
limits.memory: 256Mi
gitGC.logging.persistence.enabledWhether to persist logstrue
gitGC.logging.persistence.sizeStorage size for persisted logs1Gi

Gerrit slave

The way the Jetty servlet used by Gerrit works, the Gerrit slave component of the gerrit-slave chart actually requires the URL to be known, when the chart is installed. The suggested way to do that is to use the provided Ingress resource. This requires that a URL is available and that the DNS is configured to point the URL to the IP of the node the Ingress controller is running on!
Setting the canonical web URL in the gerrit.config to the host used for the Ingress is mandatory, if access to the Gerrit slave is required!
gerritSlave.images.gerritInitImage name of the Gerrit init container imagek8s-gerrit/gerrit-init
gerritSlave.images.gerritSlaveImage name of the Gerrit slave container imagek8s-gerrit/gerrit-slave
gerritSlave.replicasNumber of pod replicas to deploy1
gerritSlave.maxSurgeMax. percentage or number of pods allowed to be scheduled above the desired number25%
gerritSlave.maxUnavailableMax. percentage or number of pods allowed to be unavailable at a time100%
gerritSlave.initializeTestSite.enabledEnable the initialization of a site. USE ONLY for testing, if you do not plan to replicate repositories.true
gerritSlave.resourcesConfigure the amount of resources the pod requests/is allowedrequests.cpu: 1
requests.memory: 5Gi
limits.cpu: 1
limits.memory: 6Gi
gerritSlave.persistence.enabledWhether to persist the Gerrit sitetrue
gerritSlave.persistence.sizeStorage size for persisted Gerrit site10Gi
gerritSlave.service.typeWhich kind of Service to deployNodePort
gerritSlave.service.http.portPort over which to expose HTTP80
gerritSlave.ingress.hostREQUIRED: Host name to use for the Ingress (required for Ingress)nil
gerritSlave.ingress.additionalAnnotationsAdditional annotations for the Ingressnil
gerritSlave.ingress.tls.enabledWhether to enable TLS termination in the Ingressfalse
gerritSlave.ingress.tls.certPublic SSL server certificate-----BEGIN CERTIFICATE-----
gerritSlave.ingress.tls.keyPrivate SSL server certificate-----BEGIN RSA PRIVATE KEY-----
gerritSlave.keystorebase64-encoded Java keystore (`cat keystore.jksbase64`) to be used by Gerrit, when using SSL
gerritSlave.config.gerritThe contents of the gerrit.configsee here
gerritSlave.config.secureThe contents of the secure.configsee here

Gerrit config files

The gerrit-slave chart provides a ConfigMap containing the gerrit.config and a Secret containing the secure.config to configure the Gerrit installation in the Gerrit slave component. The content of the gerrit.config and secure.config can be set in the values.yaml under the keys gerritSlave.config.gerrit and respectively. All configuration options are described in detail in the official documentation of Gerrit. Some options however have to be set in a specified way for the Gerrit slave to work as intended:

  • gerrit.basePath

    Path to the directory containing the repositories. The chart mounts this directory from a persistent volume to /var/gerrit/git in the container. For Gerrit to find the correct directory, this has to be set to git.

  • gerrit.serverId

    In Gerrit-version higher than 2.14 Gerrit needs a server ID, which is used by NoteDB. Gerrit would usually generate a random ID on startup, but since the gerrit.config file is read only, when mounted as a ConfigMap this fails. Thus the server ID has to be set manually!

  • gerrit.canonicalWebUrl

    The canonical web URL has to be set to the Ingress host.

  • httpd.listenURL

    This has to be set to proxy-http://*:8080/ or proxy-https://*:8080, depending of TLS is enabled in the Ingress or not, otherwise the Jetty servlet will run into an endless redirect loop.

  • container.user

    The technical user in the Gerrit slave container is called gerrit. Thus, this value is required to be gerrit.

  • container.slave

    Since this chart is meant to install a Gerrit slave, this naturally has to be true.

  • container.javaHome

    This has to be set to /usr/lib/jvm/java-8-openjdk-amd64, since this is the path of the Java installation in the container.

  • container.javaOptions

    The maximum heap size has to be set. And its value has to be lower than the memory resource limit set for the container (e.g. -Xmx4g). In your calculation allow memory for other components running in the container.

Upgrading the Chart

To upgrade an existing installation of the gerrit-slave chart, e.g. to install a newer chart version or to use an updated custom values.yaml-file, execute the following command:

cd $(git rev-parse --show-toplevel)/helm-charts
helm upgrade <release-name> \
  -f <path-to-custom-values>.yaml \

Uninstalling the Chart

To delete the chart from the cluster, use:

helm delete <release-name> \