Мы используем IAP, GCP L7 Loadbalancer с контроллером nginx-ingress (версия 0.49.3). Мы развернули собственный GitLab и получили «ERR_TOO_MANY_REDIRECTS».
После нескольких напряженных дней устранения неполадок мы заметили, что
POST /api/v4/jobs/request HTTP/1.1
Host: gitlab.ci.g.nakhoda.ai
X-Request-ID: dfa874d97ed06e0e7a7cf17c0a4ae2c0
X-Real-IP: 35.191.12.183
X-Forwarded-For: 35.191.12.183
X-Forwarded-Host: gitlab.ci.g.nakhoda.ai
X-Forwarded-Port: 80
X-Forwarded-Proto: http
X-Forwarded-Scheme: http
X-Scheme: http
X-Original-Forwarded-For: 62.189.73.245, 35.186.225.221
Content-Length: 714
User-Agent: gitlab-runner 15.6.1 (15-6-stable; go1.18.8; linux/amd64)
Accept: application/json
Content-Type: application/json
Accept-Encoding: gzip
X-Cloud-Trace-Context: 4efdd65224a5882999fd0fb26a888bfd/2273898499790060164
Via: 1.1 google
X-Forwarded-Proto: http и X-Forwarded-Scheme: http в наших первоначальных переадресациях установлено значение http. Немного повозившись с этим, мы выполнили в контейнере nginx-ingress-controller и отредактировали nginx.conf, чтобы у обоих был https, а также добавили аннотацию ssl-redirect: false.
После этого запрос выглядит так:
POST /api/v4/jobs/request HTTP/1.1
Host: gitlab.ci.g.nakhoda.ai
X-Request-ID: f103bba96d47527dae15087d1dd1d476
X-Real-IP: 35.191.12.180
X-Forwarded-For: 35.191.12.180
X-Forwarded-Host: gitlab.ci.g.nakhoda.ai
X-Forwarded-Port: 80
X-Forwarded-Proto: https
X-Forwarded-Scheme: https
X-Scheme: http
X-Original-Forwarded-For: 194.203.216.4, 35.186.225.221
Content-Length: 714
User-Agent: gitlab-runner 15.6.1 (15-6-stable; go1.18.8; linux/amd64)
Accept: application/json
Content-Type: application/json
Accept-Encoding: gzip
X-Cloud-Trace-Context: 3ceb1d9d95fa28be4da929dea1f3ac95/3016269448751760533
Via: 1.1 google
Теперь, редактируя вручную, мы можем получить доступ к GitLab без каких-либо проблем, но проблема в том, что это ручное исправление, которое мы добавили, поэтому каждый раз, когда конвейер выполняет развертывание, оно будет сбрасываться на место.
Проблема в том, что мы искали добавление пользовательских заголовков для перезаписи [nginx.conf](https://kubernetes.github.io/ingress-nginx/examples/customization/custom-headers/ не перезаписывает обычный nginx .conf), но после добавления ConfigMap с конкретными вещами или просто добавления подобных аннотаций, подобных этой, в Ingress контроллера nginx-ingress или в ConfigMap:
Вход в Gitlab
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: gitlab-chart-webservice-default
namespace: gitlab
labels:
app: webservice
app.kubernetes.io/managed-by: Helm
chart: webservice-6.6.2
gitlab.com/webservice-name: default
heritage: Helm
release: gitlab-chart
annotations:
kubernetes.io/ingress.provider: nginx
meta.helm.sh/release-name: gitlab-chart
meta.helm.sh/release-namespace: gitlab
nginx.ingress.kubernetes.io/proxy-body-size: 512m
nginx.ingress.kubernetes.io/proxy-connect-timeout: '15'
nginx.ingress.kubernetes.io/proxy-read-timeout: '600'
nginx.ingress.kubernetes.io/service-upstream: 'true'
nginx.ingress.kubernetes.io/ssl-redirect: 'false'
status:
loadBalancer:
ingress:
- ip: 1.1.1.1
- ip: 1.1.1.1
spec:
ingressClassName: stable-protected
tls:
- hosts:
- gitlab.ci.example.com
secretName: gitlab-cert
rules:
- host: gitlab.ci.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: gitlab-chart-webservice-default
port:
number: 8181
ConfigMap для контроллера nginx
apiVersion: v1
kind: ConfigMap
metadata:
name: nginx
namespace: ingress-stable-protected
annotations:
refresh-me: |
This 'refresh-me' annotation is purely used as a placeholder so we can
modify its value in order to manually force the nginx ingress-controller
to reload its configuration.
Reload.
data:
enable-vts-status: 'true'
hide-headers: Strict-Transport-Security
hsts: 'true'
hsts-include-subdomains: 'false'
hsts-preload: 'false'
proxy-body-size: 2048m
proxy-buffer-size: 16k
proxy-connect-timeout: '5'
proxy-next-upstream: 'off'
proxy-read-timeout: '600'
proxy-send-timeout: '600'
server-name-hash-bucket-size: '256'
server-tokens: 'false'
nginx.ingress.kubernetes.io/x-forwarded-proto=https
nginx.ingress.kubernetes.io/x-forwarded-scheme=https
Он по-прежнему требует nginx.conf http, поэтому мы застряли с этим временным исправлением.
Пытался добавить кучу пользовательских заголовков и x-forwarded-headers, но безрезультатно.

Проблема заключалась в том, что после версии 0.24.0 nginx-ingress произошло изменение аннотации, поэтому, добавив следующее в карту конфигурации nginx, ошибка больше не возникает.
Более подробное описание можно найти в этом билете
use-forwarded-headers: "true"
use-proxy-protcol: "false"
Полный пример:
apiVersion: v1
data:
enable-vts-status: "true"
hide-headers: Strict-Transport-Security
hsts-preload: "false"
proxy-body-size: 2048m
proxy-buffer-size: 16k
proxy-connect-timeout: "5"
proxy-next-upstream: "off"
proxy-read-timeout: "600"
proxy-send-timeout: "600"
server-name-hash-bucket-size: "256"
server-tokens: "false"
use-forwarded-headers: "true"
use-proxy-protcol: "false"
kind: ConfigMap
metadata:
annotations:
refresh-me: |
This 'refresh-me' annotation is purely used as a placeholder so we can
modify its value in order to manually force the nginx ingress-controller
to reload its configuration.
labels:
app.kubernetes.io/managed-by: pulumi
name: nginx
namespace: namespace