External NGINX Ingress Controller

This chart configures Ingress resources for use with the official NGINX Ingress implementation. The NGINX Ingress Controller is deployed as a part of this chart. If you want to reuse an existing NGINX Ingress Controller already available in your cluster, this guide will help.

TCP services in the external Ingress Controller

The GitLab Shell component requires TCP traffic to pass through on port 22 (by default; this can be changed). Ingress does not directly support TCP services, so some additional configuration is necessary. Your NGINX Ingress Controller may have been deployed directly (i.e. with a Kubernetes spec file) or through the official Helm chart. The configuration of the TCP pass through will differ depending on the deployment approach.

Direct deployment

In a direct deployment, the NGINX Ingress Controller handles configuring TCP services with a ConfigMap (see docs here). Assuming your GitLab chart is deployed to the namespace gitlab and your Helm release is named mygitlab, your ConfigMap should be something like this: 

apiVersion: v1
kind: ConfigMap
metadata:
  name: tcp-configmap-example
data:
  22: "gitlab/mygitlab-gitlab-shell:22"

After you have that ConfigMap, you can enable it as described in the NGINX Ingress Controller docs using the --tcp-services-configmap option. 

args:
  - /nginx-ingress-controller
  - --tcp-services-configmap=gitlab/tcp-configmap-example

Finally make sure that the Service for your NGINX Ingress Controller is exposing port 22 in addition to 80 and 443.

Helm deployment

If you have installed or will install the NGINX Ingress Controller via it’s Helm chart, then you will need to add a value to the chart via the command line: 

--set tcp.22="gitlab/mygitlab-gitlab-shell:22"

or a values.yaml file: 

tcp:
  22: "gitlab/mygitlab-gitlab-shell:22"

The format for the value is the same as describe above in the “Direct Deployment” section.

Customize the GitLab Ingress options

The NGINX Ingress Controller uses an annotation to mark which Ingress Controller will service a particular Ingress (see docs). You can configure the Ingress class to use with this chart using the global.ingress.class setting. Make sure to set this in your Helm options. 

--set global.ingress.class=myingressclass

While not necessarily required, if you’re using an external Ingress Controller, you will likely want to disable the Ingress Controller that is deployed by default with this chart: 

--set nginx-ingress.enabled=false

Custom certificate management

The full scope of your TLS options are documented elsewhere.

If you are using an external Ingress Controller, you may also be using an external cert-manager instance or managing your certificates in some other custom manner. The full documentation around your TLS options is here, however for the purposes of this discussion, here are the two values that would need to be set to disable the cert-manager chart and tell the GitLab component charts to NOT look for the built in certificate resources: 

--set certmanager.install=false
--set global.ingress.configureCertmanager=false