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 Redis and Unicorn 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

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 GitLab’s 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.

Installation command line options

ParameterDefaultDescription
annotations Pod annotations
enabledtrueShell enable flag
deployment.livenessProbe.initialDelaySeconds10Delay before liveness probe is initiated
deployment.livenessProbe.periodSeconds10How often to perform the liveness probe
deployment.livenessProbe.timeoutSeconds3When the liveness probe times out
deployment.livenessProbe.successThreshold1Minimum consecutive successes for the liveness probe to be considered successful after having failed
deployment.livenessProbe.failureThreshold3Minimum consecutive failures for the liveness probe to be considered failed after having succeeded
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
hpa.targetAverageValue100mSet the autoscaling target value
image.pullPolicyAlwaysShell image pull policy
image.pullSecrets Secrets for the image repository
image.repositoryregistry.com/gitlab-org/build/cng/gitlab-shellShell image repository
image.taglatestShell image tag
init.imagebusyboxinitContainer image
init.taglatestinitContainer image tag
redis.serviceNameredisRedis service name
replicaCount1Shell replicas
service.externalPort22Shell exposed port
service.internalPort22Shell internal port
service.namegitlab-shellShell service name
service.typeClusterIPShell service type
service.loadBalancerIP IP address to assign to LoadBalancer (if supported)
service.loadBalancerSourceRanges List of IP CIDRs allowed access to LoadBalancer (if supported)
service.typeClusterIPShell service type
tolerations[]Toleration labels for pod assignment
unicorn.serviceNameunicornUnicorn service name

Chart configuration examples

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

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 Unicorn service, and should also use the same Redis as the attached Unicorn service.

Redis

redis:
  host: redis.example.com
  serviceName: redis
  port: 6379
  sentinels:
    - host: sentinel1.example.com
      port: 26379
  password:
    secret: gitlab-redis
    key: redis-password
NameTypeDefaultDescription
hostString 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.keyString The name of the key in the secret below that contains the password.
password.secretString The name of the Kubernetes Secret to pull from.
portInteger6379The port on which to connect to the Redis server.
serviceNameStringredisThe 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.[].hostString The hostname of Redis Sentinel server for a Redis HA setup.
sentinels.[].portInteger26379The port on which to connect to the Redis Sentinel server.

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.enabled=false and redis-ha.enabled=false. The Secret containing the Redis password will need to be manually created before deploying the GitLab chart.

Unicorn

unicorn:
  host: unicorn.example.com
  serviceName: unicorn
  port: 8080
NameTypeDefaultDescription
hostString The hostname of the Unicorn server. This can be omitted in lieu of serviceName.
portInteger8080The port on which to connect to the Unicorn server.
serviceNameStringunicornThe name of the service which is operating the Unicorn 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 Unicorn 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 Unicorn. Share the token with GitLab Shell and Unicorn using a shared Secret.

authToken:
 secret: gitlab-shell-secret
 key: secret
NameTypeDefaultDescription
authToken.keyString The name of the key in the above secret that contains the authToken.
authToken.secretString 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