• 리디렉션이 너무 많음
• 불변 필드 오류로 인한 업그레이드 실패
  • spec.clusterIP
  • spec.selector
  • “RELEASE-NAME-cert-manager”의 종류 Deployment를 패치할 수 없음
  • “gitlab-kube-state-metrics”의 종류 Deployment를 패치할 수 없음
• ImagePullBackOff, 이미지를 끌어올 수 없음 및 manifest unknown 오류
• UPGRADE FAILED: “cannot patch …” after helm 2to3 convert
• UPGRADE FAILED: mailroom의 유형 불일치: %!t(<nil>)
• 복원 실패: ERROR: cannot drop view pg_stat_statements because extension pg_stat_stat_statements requires it
• 번들된 PostgreSQL 팟을 시작하지 못함: 데이터베이스 파일이 서버와 호환되지 않음
• 번들된 NGINX Ingress 팟이 시작하지 못함: Failed to watch *v1beta1.Ingress
• /api/v4/jobs/request 엔드포인트에 대한 부하 증가
• SSH를 통한 Git: 원격 엔드가 예기치 않게 연결을 끊었습니다
• YAML 구성: 이 컨텍스트에서는 매핑 값이 허용되지 않습니다
• TLS 및 인증서
  • 인증서 신뢰 설정 및 문제 해결
  • Rails 콘솔 확인
  • 초기화 컨테이너 문제 해결
• 308: Permanent Redirect가 리디렉션 루프를 발생시키는 경우
• nginx-controller 로그 및 404 오류에서 “잘못된 단어” 오류
  • 볼륨 마운트에 오랜 시간이 걸립니다
  • 간헐적 502 오류

​ # GitLab 차트의 문제 해결 ​ ## UPGRADE FAILED: 작업 실패: BackoffLimitExceeded ​ 만약 차트 6.0 버전으로 업그레이드하는 동안 이 오류를 받았다면, 아마도 올바른 업그레이드 경로를 따르지 않은 것입니다. 먼저 최신 5.10.x 버전으로 업그레이드해야 합니다: ​ 1. 모든 릴리즈를 나열하여 GitLab Helm 릴리즈 이름을 식별합니다(default K8s 네임스페이스에 릴리즈가 배포되지 않은 경우 -n <namespace>를 포함해야 합니다): shell helm ls

1. GitLab Helm 릴리즈가 gitlab이라고 가정하면, 릴리즈 히스토리를 확인하고 마지막으로 성공한 리비전을 식별합니다 (리비전의 상태는 DESCRIPTION 아래에서 확인할 수 있습니다): shell helm history gitlab

2. 최근에 성공한 리비전이 1이라고 가정하면, 다음 명령을 사용하여 롤백합니다: shell helm rollback gitlab 1

3. <x>를 적절한 차트 버전으로 대체하여 업그레이드 명령을 다시 실행합니다: shell helm upgrade --version=5.10.<x>

4. 이 시점에서 --version 옵션을 사용하여 특정 6.x.x 차트 버전을 전달하거나, GitLab의 최신 버전으로 업그레이드하지 않으려면 옵션을 제거합니다: shell helm upgrade --install gitlab gitlab/gitlab <other_options>

명령행 인수에 대한 자세한 정보는 Helm을 사용하여 배포 섹션에서 찾을 수 있습니다. 차트 버전과 GitLab 버전 간의 매핑에 대한 정보는 GitLab 버전 매핑을 확인하세요. ​ ## UPGRADE FAILED: “$name”에 배포된 릴리스가 없음 ​ 이 오류는 초기 설치가 실패한 경우 두 번째 설치/업그레이드에서 발생합니다. ​ 초기 설치가 완전히 실패하고 GitLab이 작동하지 않았다면, 다시 설치하기 전에 먼저 실패한 설치를 제거해야 합니다. shell helm uninstall <릴리스 이름> ​ 반면에 초기 설치 명령이 타임아웃되었지만 GitLab이 여전히 성공적으로 실행된 경우, helm upgrade 명령에 --force 플래그를 추가하여 오류를 무시하고 릴리스를 업데이트할 수 있습니다. ​ 그렇지 않으면, GitLab 차트를 이전에 성공적으로 배포했던 후에 이 오류를 받았다면, 버그를 만났을 가능성이 높습니다. 이 경우 이슈 트래커에서 이슈를 열어보고, 또한 이 문제를 해결한 이슈 #630를 확인하세요. ​ ## 오류: 이 명령에는 2개의 인수가 필요합니다: 릴리스 이름, 차트 경로 ​ 이와 같은 오류는 helm upgrade를 실행하고 파라미터에 공백이 있는 경우에 발생할 수 있습니다. 다음의 예제에서 Test Username이 문제입니다: ​ shell helm upgrade gitlab gitlab/gitlab --timeout 600s --set global.email.display_name=Test Username ... ​ 이를 해결하려면, 단일 따옴표로 매개변수를 전달하세요: ​ shell helm upgrade gitlab gitlab/gitlab --timeout 600s --set global.email.display_name='Test Username' ... ​ ## 응용 프로그램 컨테이너가 지속적으로 초기화됨 ​ 만약 Sidekiq, Webservice 또는 기타 Rails 기반 컨테이너가 지속적인 초기화 상태에 있다면, 아마도 dependencies 컨테이너가 통과되기를 기다리고 있는 것입니다. ​ 주어진 Pod의 로그를 확인하여 dependencies 컨테이너에 대한 로그를 확인하면 다음이 반복되는 것을 볼 수 있습니다: ​ plaintext 데이터베이스 연결 및 스키마 버전 확인 경고: 이 GitLab 버전은 gitlab-shell 8.7.1에 의존합니다, ... 데이터베이스 스키마 현재 버전: 0 코드베이스 버전: 20190301182457 ​ 이것은 migrations 작업이 아직 완료되지 않았음을 나타냅니다. 이 작업의 목적은 데이터베이스가 초기화되고 모든 관련 마이그레이션이 완료되도록 하는 것입니다. 응용 프로그램 컨테이너들은 데이터베이스가 기대하는 데이터베이스 버전과 일치하거나 이를 초과하기를 기다리고 있습니다. 코드베이스의 스키마가 예상과 일치하지 않아 응용 프로그램이 제대로 작동하지 않게 되는 것을 방지하는 것입니다. ​ 1. migrations 작업을 찾으세요. kubectl get job -lapp=migrations 1. 작업에 의해 실행되는 Pod을 찾으세요. kubectl get pod -ljob-name=<작업 이름> 1. STATUS 열을 확인하여 출력을 조사하세요. ​ 만약 STATUS가 Running이라면 계속 진행하세요. 만약 STATUS가 Completed라면 다음 확인이 통과한 후 약간 이후에 응용 프로그램 컨테이너들이 시작될 것입니다. ​ 이 Pod에서의 로그를 확인하세요. kubectl logs <pod 이름> ​ 이 작업 실행 중에 실패가 발생하면 해당 문제를 해결해야 합니다. 이러한 문제는 해결되기 전까지 응용 프로그램의 사용을 차단할 수 있습니다. 가능한 문제는 다음과 같습니다: ​ - 구성된 PostgreSQL 데이터베이스의 접속 불가능 또는 인증 실패 - 구성된 Redis 서비스의 접속 불가능 또는 인증 실패 - Gitaly 인스턴스에 도달하지 못함 ​ ## 구성 변경 적용 ​ 다음 명령은 gitlab.yaml에 만든 업데이트를 적용하는 데 필요한 작업을 수행합니다: ​ shell helm upgrade <릴리스 이름> <차트 경로> -f gitlab.yaml ​ ## 포함된 GitLab Runner 등록 실패 ​ 이것은 GitLab에서 실행 중인 등록 토큰이 변경된 경우(이는 백업을 복원한 후에 종종 발생함)에 발생할 수 있습니다. ​ 1. GitLab 설치의 admin/runners 웹페이지에서 새로운 공유 러너 토큰을 찾으세요. 1. Kubernetes에 저장된 기존 러너 토큰 비밀을 찾으세요: shell kubectl get secrets | grep gitlab-runner-secret

1. 기존 시크릿을 삭제하세요: shell kubectl delete secret <러너 시크릿 이름>

2. 두 개의 키(runner-registration-token과 공유 토큰, 그리고 비어있는 runner-token)으로 새로운 시크릿을 생성하세요: shell kubectl create secret generic <러너 시크릿 이름> --from-literal=runner-registration-token=<새로운 공유 러너 토큰> --from-literal=runner-token=""

리디렉션이 너무 많음

​ 이것은 NGINX Ingress 이전에 TLS 종료가 있고, tls-secrets가 구성된 경우에 발생할 수 있습니다. ​ 1. global.ingress.annotations."nginx.ingress.kubernetes.io/ssl-redirect"를 false로 설정하도록 값을 업데이트하세요:

값 파일을 통해: yaml # values.yaml global: ingress: annotations: "nginx.ingress.kubernetes.io/ssl-redirect": "false"

Helm CLI를 통해: shell helm ... --set-string global.ingress.annotations."nginx.ingress.kubernetes.io/ssl-redirect"=false

1. 변경을 적용하세요.

참고: SSL 종료에 외부 서비스를 사용하는 경우, 해당 서비스가 https로 리디렉션하는 것을 담당합니다(원할 경우).

불변 필드 오류로 인한 업그레이드 실패

spec.clusterIP

이 차트의 3.0.0 릴리스 이전에는 실제 값("")이 없음에도 불구하고 spec.clusterIP 속성이 여러 서비스에 입력되어 있었습니다. 이는 버그였으며, Helm 3의 속성 세 가지 병합에 문제를 일으킵니다.

차트가 Helm 3으로 배포된 후에는 clusterIP 속성을 모으고 해당 값을 Helm에 제공된 값으로 입력하거나, 영향을 받는 서비스가 Kubernetes에서 제거될 때까지 가능한 업그레이드 경로가 없게 됩니다.

이 차트의 3.0.0 릴리스에서 이 오류가 수정되었지만, 수동으로 수정해주어야 합니다.

이는 영향을 받는 서비스를 모두 제거하여 해결할 수 있습니다.

1. 영향을 받는 모든 서비스 제거:

   kubectl delete services -lrelease=릴리스_이름
   

2. Helm을 통해 업그레이드 수행.
3. 이후 업그레이드에서 이 오류에 직면하지 않게 됩니다.

참고: 이는 사용 중인 경우 이 차트의 LoadBalancer에 대한 동적 값이 변경될 수 있음을 의미합니다. 더 자세한 내용은 전역 Ingress 설정 문서를 참조하세요. DNS 레코드를 업데이트해야 할 수 있습니다!

spec.selector

차트 릴리스 3.0.0 이전에는 Sidekiq 팟이 고유한 선택기를받지 못했습니다. 이에 대한 문제점이 문서화되어 있습니다.

Helm을 사용하여 3.0.0로 업그레이드하면 예전 Sidekiq 배포가 자동으로 삭제되고 새로운 Deployments,HPAs, 및 Pods의 이름에 -v1이 추가됩니다.

3.0.0을 설치할 때 Sidekiq 배포에서 계속해서 이 오류가 발생하는 경우 다음 단계로 이를 해결하십시오.

1. Sidekiq 서비스 제거

   kubectl delete deployment --cascade -lrelease=릴리스_이름,app=sidekiq
   

2. Helm을 통해 업그레이드 수행.

“RELEASE-NAME-cert-manager”의 종류 Deployment를 패치할 수 없음

CertManager 버전 0.10에서 업그레이드하는 경우 여러 가지 주요 변경 사항이 있습니다. 기존의 Custom Resource Definitions은 Helm의 추적에서 제거되고 다시 설치해야 합니다.

Helm 차트는 기본적으로 이를 수행하려고 시도하지만 이 오류가 발생하는 경우 수동 조치가 필요할 수 있습니다.

이 오류 메시지가 발생한 경우 새로운 Custom Resource Definitions이 배포에 실제로 적용되도록하려면 일반적인 것보다 한 단계 더 많이 필요합니다.

1. 예전 CertManager Deployment 제거.

   kubectl delete deployments -l app=cert-manager --cascade
   

2. 다시 업그레이드를 실행하세요. 이번에는 새로운 Custom Resource Definitions를 설치하세요.

   helm upgrade --install --values - YOUR-RELEASE-NAME gitlab/gitlab < <(helm get values YOUR-RELEASE-NAME)
   

“gitlab-kube-state-metrics”의 종류 Deployment를 패치할 수 없음

Prometheus 버전 11.16.9에서 15.0.4로 업그레이드하면 kube-state-metrics Deployment에 사용된 선택기 레이블이 변경됩니다.(기본적으로 prometheus.kubeStateMetrics.enabled=false).

이 오류 메시지가 발생하는 경우는 prometheus.kubeStateMetrics.enabled=true를 의미하며, 업그레이드에는 추가 단계가 필요합니다.

1. 예전 kube-state-metrics Deployment 제거.

   kubectl delete deployments.apps -l app.kubernetes.io/instance=릴리스_이름,app.kubernetes.io/name=kube-state-metrics --cascade=orphan
   

2. Helm을 통해 업그레이드 수행.

ImagePullBackOff, 이미지를 끌어올 수 없음 및 manifest unknown 오류

만약 global.gitlabVersion을 사용 중이라면, 이 속성을 제거하는 것으로 시작하십시오. 차트와 GitLab 간의 버전 매핑을 확인한 후 helm 명령어에서 호환되는 gitlab/gitlab 차트의 버전을 지정하십시오.

UPGRADE FAILED: “cannot patch …” after helm 2to3 convert

이는 알려진 문제입니다. Helm 2 릴리스를 Helm 3로 마이그레이션한 후에는 후속 업그레이드가 실패할 수 있습니다. Migrating from Helm v2 to Helm v3에서 완전한 설명과 해결 방법을 찾을 수 있습니다.

UPGRADE FAILED: mailroom의 유형 불일치: %!t(<nil>)

이와 같은 오류는 유효한 맵을 예상하는 키에 유효한 맵을 제공하지 않은 경우 발생할 수 있습니다.

예를 들어, 아래 구성은 이 오류를 발생시킵니다.

gitlab:
  mailroom:

이를 해결하려면 다음 중 하나를 수행하십시오:

1. gitlab.mailroom에 유효한 맵을 제공합니다.
2. mailroom 키를 완전히 제거합니다.

선택적 키의 경우 빈 맵({})은 유효한 값입니다.

복원 실패: ERROR: cannot drop view pg_stat_statements because extension pg_stat_stat_statements requires it

Helm 차트 인스턴스에서 백업을 복원하는 중에 이 오류가 발생할 수 있습니다. 다음 단계를 임시 대책으로 사용하십시오:

1. toolbox 팟 내에서 DB 콘솔을 엽니다.

   /srv/gitlab/bin/rails dbconsole -p
   

2. 확장 기능 삭제:

   DROP EXTENSION pg_stat_statements;
   

3. 복원 프로세스를 실행하십시오.

4. 복원이 완료되면 DB 콘솔에서 확장 기능을 다시 생성하십시오.

   CREATE EXTENSION pg_stat_statements;
   

만약 pg_buffercache 확장 기능에 대해 동일한 문제가 발생한다면, 동일한 단계를 따라 pg_buffercache를 삭제하고 다시 생성하십시오.

이 오류에 대한 더 자세한 내용은 이슈 #2469에서 확인할 수 있습니다.

번들된 PostgreSQL 팟을 시작하지 못함: 데이터베이스 파일이 서버와 호환되지 않음

GitLab Helm 차트의 새 버전으로 업그레이드한 후에는 번들된 PostgreSQL 팟에서 다음과 같은 오류 메시지가 표시될 수 있습니다:

gitlab-postgresql FATAL:  database files are incompatible with server
gitlab-postgresql DETAIL:  데이터 디렉토리가 호환되지 않는 버전 12.7과(와) 호환되지 않는 PostgreSQL 버전 11로 초기화되었습니다.

대응하기 위해 이전 차트 버전으로 Helm 롤백을 수행한 다음, 번들된 PostgreSQL 버전을 업그레이드하기 위해 업그레이드 가이드의 단계를 따릅니다. PostgreSQL이 올바르게 업그레이드되면 GitLab Helm 차트를 다시 업그레이드해보세요.

번들된 NGINX Ingress 팟이 시작하지 못함: Failed to watch *v1beta1.Ingress

Kubernetes 버전 1.22 이상을 실행 중인 경우에는 번들된 NGINX Ingress 컨트롤러 팟에서 다음과 같은 오류 메시지가 표시될 수 있습니다:

Failed to watch *v1beta1.Ingress: failed to list *v1beta1.Ingress: the server could not find the requested resource

이를 해결하려면 Kubernetes 버전이 1.21 또는 이전 버전인지 확인하세요. Kubernetes 1.22 이상에서 NGINX Ingress 지원에 관한 자세한 내용은 #2852를 참조하세요.

/api/v4/jobs/request 엔드포인트에 대한 부하 증가

workhorse.keywatcher 옵션이 /api/*을 서비스하는 배포의 경우 이 문제가 발생할 수 있습니다. 확인하려면 다음 단계를 사용하세요:

1. /api/*를 서비스하는 팟의 gitlab-workhorse 컨테이너에 액세스:

   kubectl exec -it --container=gitlab-workhorse <gitlab_api_pod> -- /bin/bash
   

2. 파일 /srv/gitlab/config/workhorse-config.toml을 검사합니다. [redis] 구성이 누락될 수 있습니다:

   grep '\[redis\]' /srv/gitlab/config/workhorse-config.toml
   

[redis] 구성이 없는 경우 배포 중에 workhorse.keywatcher 플래그가 false로 설정되어 있어 /api/v4/jobs/request 엔드포인트에 추가 부하가 발생합니다. 이를 수정하려면 webservice 차트에서 keywatcher를 활성화하세요:

workhorse:
  keywatcher: true

SSH를 통한 Git: 원격 엔드가 예기치 않게 연결을 끊었습니다

SSH를 통한 Git 작업이 다음과 같은 오류로 때때로 실패할 수 있습니다:

fatal: 원격 엔드가 예기치 않게 연결을 끊었습니다
fatal: early EOF
fatal: index-pack failed

이 오류의 잠재적인 원인들이 있습니다:

• 네트워크 타임아웃:

  Git 클라이언트는 때때로 연결을 열어두고 놔두며, 객체를 압축하는 경우와 같이 유휴 상태로 유지될 수 있습니다. 예를 들어 HAProxy의 timeout client와 같은 설정은 이러한 유휴 연결을 종료시킬 수 있습니다.

  sshd에 keepalive를 설정할 수 있습니다:

  gitlab:
    gitlab-shell:
      config:
        clientAliveInterval: 15
  

• gitlab-shell 메모리:

  차트는 기본적으로 GitLab Shell 메모리에 제한을 두지 않습니다. gitlab.gitlab-shell.resources.limits.memory가 너무 낮게 설정되어 있으면 SSH를 통한 Git 작업이 이러한 오류로 실패할 수 있습니다.

  kubectl describe nodes를 실행하여 이것이 네트워크 타임아웃보다는 메모리 제한으로 인한 것인지 확인하세요.

  시스템 OOM에 의해 피해 프로세스 발생: gitlab-shell
  메모리 cgroup이 부족하여 프로세스 3141592(gitlab-shell)가 종료되었습니다.
  

YAML 구성: 이 컨텍스트에서는 매핑 값이 허용되지 않습니다

다음과 같은 오류 메시지가 나타날 수 있습니다:

template: /var/opt/gitlab/templates/workhorse-config.toml.tpl:16:98:
  executing \"/var/opt/gitlab/templates/workhorse-config.toml.tpl\" at <data.YAML>:
    error calling YAML:
      yaml: line 2: mapping values are not allowed in this context

이를 해결하려면 구성에 선행 공백이 없도록 확인하세요.

예를 들어 다음과 같이 변경하세요:

key1: value1
key2: value2

…을 다음과 같이 변경하세요:

key1: value1
key2: value2

TLS 및 인증서

GitLab 인스턴스가 개인 TLS 인증 기관을 신뢰해야 하는 경우, GitLab이 객체 저장소, Elasticsearch, Jira 또는 Jenkins와 같은 다른 서비스와의 핸드셰이크에 실패할 수 있습니다:

error: certificate verify failed (unable to get local issuer certificate)

특정의 인증서가 별도의 파일에 포함되어 있지 않으면 개인 인증 기관에서 서명된 인증서의 부분적 신뢰가 발생할 수 있습니다.

proxy_download 구성에 따라 브라우저가 올바르게 구성된 신뢰 저장소로 리디렉션되면 문제가 없을 수 있습니다. 동시에 한 개 이상의 GitLab 구성 요소에 의한 TLS 핸드셰이크가 실패할 수 있습니다.

인증서 신뢰 설정 및 문제 해결

인증서 문제 해결의 일환으로 다음과 같은 작업을 수행하세요:

• 신뢰해야 하는 각 인증서에 대한 시크릿을 생성하세요.

• 각 파일 당 하나의 인증서만 제공하세요.

  kubectl create secret generic custom-ca --from-file=unique_name=/path/to/cert
  

  이 예에서는 인증서가 unique_name 키 이름을 사용하여 저장됩니다.

번들 또는 체인을 제공하면 일부 GitLab 구성 요소가 작동하지 않을 수 있습니다.

global.certificates.customCAs를 사용하여 추가 신뢰 할 수 있는 인증서를 제공하세요. 차트 글로벌 (globals.md)에서 자세한 내용을 확인하세요.

팟이 배포되면 init 컨테이너가 인증서를 마운트하고 GitLab 구성 요소가 이를 사용할 수 있도록 설정합니다. init 컨테이너는 registry.gitlab.com/gitlab-org/build/cng/alpine-certificates입니다.

추가 인증서는 /usr/local/share/ca-certificates에 마운트되며, 이 때 시크릿 키 이름이 인증서 파일 이름으로 사용됩니다.

init 컨테이너에서 /scripts/bundle-certificates를 실행합니다 (소스). 해당 스크립트에서 update-ca-certificates를 실행합니다:

1. /usr/local/share/ca-certificates에서 커스텀 인증서를 /etc/ssl/certs로 복사합니다.
2. 번들 ca-certificates.crt를 컴파일합니다.

3. 각 인증서에 대한 해시를 생성하고, Rails에서 필요한 심볼릭 링크를 생성합니다. 인증서 번들은 경고와 함께 건너뜁니다:

   경고: unique_name은 정확히 하나의 인증서 또는 CRL을 포함하지 않습니다: 스킵합니다
   

init 컨테이너의 상태 및 로그를 문제 해결해보세요. 예를 들어, 인증서 init 컨테이너의 로그를 보고 경고를 확인하세요:

kubectl logs gitlab-webservice-default-pod -c certificates

Rails 콘솔 확인

툴박스 파드를 사용하여 제공한 인증서를 Rails가 신뢰하는지 확인하십시오.

1. Rails 콘솔을 시작합니다(<namespace>에는 GitLab이 설치된 네임스페이스로 대체):

   kubectl exec -ti $(kubectl get pod -n <namespace> -lapp=toolbox -o jsonpath='{.items[0].metadata.name}') -n <namespace> -- bash
   /srv/gitlab/bin/rails console
   

2. Rails가 인증 기관을 확인하는 위치를 확인합니다:

   OpenSSL::X509::DEFAULT_CERT_DIR
   

3. Rails 콘솔에서 HTTPS 쿼리를 실행합니다:

   ## 연결할 웹 서버 구성:
   uri = URI.parse("https://myservice.example.com")
   
   require 'openssl'
   require 'net/http'
   Rails.logger.level = 0
   OpenSSL.debug=1
   http = Net::HTTP.new(uri.host, uri.port)
   http.set_debug_output($stdout)
   http.use_ssl = true
   
   http.verify_mode = OpenSSL::SSL::VERIFY_PEER
   # http.verify_mode = OpenSSL::SSL::VERIFY_NONE # TLS verification disabled
   
   response = http.request(Net::HTTP::Get.new(uri.request_uri))
   

초기화 컨테이너 문제 해결

도커를 사용하여 인증서 컨테이너를 실행합니다.

1. 디렉토리 구조를 설정하고 인증서를 채웁니다:

   mkdir -p etc/ssl/certs usr/local/share/ca-certificates
   
     # 비밀 이름은: my-root-ca
     # 키 이름은: corporate_root
   
   kubectl get secret my-root-ca -ojsonpath='{.data.corporate_root}' | \
        base64 --decode > usr/local/share/ca-certificates/corporate_root
   
     # 인증서가 올바른지 확인합니다:
   
   openssl x509 -in usr/local/share/ca-certificates/corporate_root -text -noout
   

2. 올바른 컨테이너 버전을 확인합니다:

   kubectl get deployment -lapp=webservice -ojsonpath='{.items[0].spec.template.spec.initContainers[0].image}'
   

3. etc/ssl/certs 콘텐츠의 준비를 수행하는 컨테이너를 실행합니다:

   docker run -ti --rm \
        -v $(pwd)/etc/ssl/certs:/etc/ssl/certs \
        -v $(pwd)/usr/local/share/ca-certificates:/usr/local/share/ca-certificates \
        registry.gitlab.com/gitlab-org/build/cng/gitlab-base:v15.10.3
   

4. 인증서가 올바르게 작성되었는지 확인합니다:

   • etc/ssl/certs/corporate_root.pem 파일이 생성되어야 합니다.
   • 인증서 자체에 대한 심볼릭 링크인 해시화된 파일 이름이 있어야 합니다(예: etc/ssl/certs/1234abcd.0).

   • 파일 및 심볼릭 링크는 다음과 같이 표시됩니다:

     ls -l etc/ssl/certs/ | grep corporate_root
     

     예:

     lrwxrwxrwx   1 root root      20 Oct  7 11:34 28746b42.0 -> corporate_root.pem
     -rw-r--r--   1 root root    1948 Oct  7 11:34 corporate_root.pem
     

308: Permanent Redirect가 리디렉션 루프를 발생시키는 경우

308: Permanent Redirect는 로드 밸런서가 암호화되지 않은 트래픽(HTTP)을 NGINX로 보내도록 구성된 경우 발생할 수 있습니다. NGINX는 기본적으로 HTTP를 HTTPS로 리디렉션하므로 “리디렉션 루프”에 빠질 수 있습니다.

이를 해결하려면 NGINX의 use-forwarded-headers 설정을 활성화하십시오.

nginx-controller 로그 및 404 오류에서 “잘못된 단어” 오류

Helm 차트 6.6 이상으로 업그레이드한 후 클러스터에 설치된 GitLab 또는 서드 파티 도메인을 방문할 때 404 반환 코드가 발생하거나 gitlab-nginx-ingress-controller 로그에서 “잘못된 단어” 오류가 발생할 수 있습니다:

gitlab-nginx-ingress-controller-899b7d6bf-688hr controller W1116 19:03:13.162001       7 store.go:846] skipping ingress gitlab/gitlab-minio: nginx.ingress.kubernetes.io/configuration-snippet annotation contains invalid word proxy_pass
gitlab-nginx-ingress-controller-899b7d6bf-688hr controller W1116 19:03:13.465487       7 store.go:846] skipping ingress gitlab/gitlab-registry: nginx.ingress.kubernetes.io/configuration-snippet annotation contains invalid word proxy_pass
gitlab-nginx-ingress-controller-899b7d6bf-lqcks controller W1116 19:03:12.233577       6 store.go:846] skipping ingress gitlab/gitlab-kas: nginx.ingress.kubernetes.io/configuration-snippet annotation contains invalid word proxy_pass
gitlab-nginx-ingress-controller-899b7d6bf-lqcks controller W1116 19:03:12.536534       6 store.go:846] skipping ingress gitlab/gitlab-webservice-default: nginx.ingress.kubernetes.io/configuration-snippet annotation contains invalid word proxy_pass
gitlab-nginx-ingress-controller-899b7d6bf-lqcks controller W1116 19:03:12.848844       6 store.go:846] skipping ingress gitlab/gitlab-webservice-default-smartcard: nginx.ingress.kubernetes.io/configuration-snippet annotation contains invalid word proxy_pass
gitlab-nginx-ingress-controller-899b7d6bf-lqcks controller W1116 19:03:13.161640       6 store.go:846] skipping ingress gitlab/gitlab-minio: nginx.ingress.kubernetes.io/configuration-snippet annotation contains invalid word proxy_pass
gitlab-nginx-ingress-controller-899b7d6bf-lqcks controller W1116 19:03:13.465425       6 store.go:846] skipping ingress gitlab/gitlab-registry: nginx.ingress.kubernetes.io/configuration-snippet annotation contains invalid word proxy_pass

이러한 경우 GitLab 값 및 서드 파티 Ingress 객체를 검토하여 구성 스니펫을 사용하는 부분을 조정하거나 수정해야 할 수 있습니다. nginx-ingress.controller.config.annotation-value-word-blocklist 설정을 조정해야 할 수 있습니다.

추가 세부 정보는 Annotation value word blocklist에서 확인하십시오.

볼륨 마운트에 오랜 시간이 걸립니다

gitaly나 toolbox와 같은 대형 볼륨을 마운트하는 것은 Pod의 securityContext와 일치시키기 위해 Kubernetes가 볼륨 내용의 권한을 재귀적으로 변경하기 때문에 시간이 오래 걸릴 수 있습니다.

Kubernetes 1.23부터 securityContext.fsGroupChangePolicy를 OnRootMismatch로 설정하여 이 문제를 완화할 수 있습니다. 이 플래그는 모든 GitLab 하위 차트에서 지원됩니다.

예를 들어 Gitaly 하위 차트의 경우:

gitlab:
  gitaly:
    securityContext:
      fsGroupChangePolicy: "OnRootMismatch"

더 많은 세부 정보는 Kubernetes 문서를 참조하세요.

fsGroupChangePolicy를 지원하지 않는 Kubernetes 버전의 경우 securityContext의 설정을 변경하거나 완전히 삭제하여 이 문제를 완화할 수 있습니다.

gitlab:
  gitaly:
    securityContext:
      fsGroup: ""
      runAsUser: ""

참고: 예시 구문은 securityContext 설정을 완전히 제거합니다. securityContext: {} 또는 securityContext:로 설정하는 것은 Helm이 기본값을 사용자가 제공한 구성과 병합하는 방식 때문에 작동하지 않습니다.

간헐적 502 오류

Puma 워커가 처리하는 요청이 메모리 제한 임계값을 넘으면 노드의 OOMKiller에 의해 종료됩니다. 그러나 요청을 종료해도 웹서비스 파드 자체를 즉시 종료하거나 다시 시작하지는 않습니다. 이 상황은 요청이 502 타임아웃을 반환하게 합니다. 로그에서는 502 오류가 기록된 직후에 Puma 워커가 생성되는 것으로 나타납니다.

2024-01-19T14:12:08.949263522Z {"correlation_id":"XXXXXXXXXXXX","duration_ms":1261,"error":"badgateway: failed to receive response: context canceled"....
2024-01-19T14:12:24.214148186Z {"component": "gitlab","subcomponent":"puma.stdout","timestamp":"2024-01-19T14:12:24.213Z","pid":1,"message":"- Worker 2 (PID: 7414) booted in 0.84s, phase: 0"}

이 문제를 해결하려면 웹서비스 파드의 메모리 제한을 높이세요.