- TCP services in the external Ingress Controller
- Customize the GitLab Ingress options
- Custom certifcate management
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.
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 additonal 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.
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
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
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.
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:
tcp: 22: "gitlab/mygitlab-gitlab-shell:22"
The format for the value is the same as describe above in the “Direct Deployment” section.
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.
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:
The full scope of your TLS options are documented elswhere.
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