• UPGRADE FAILED: Job failed: BackoffLimitExceeded
• UPGRADE FAILED: “$name” has no deployed releases
• Error: this command needs 2 arguments: release name, chart path
• 애플리케이션 컨테이너가 계속 초기화됨
• 구성 변경 적용
• 포함된 GitLab Runner 등록 실패
• 너무 많은 리다이렉트
• 업그레이드가 불변 필드 오류로 실패
  • spec.clusterIP
  • spec.selector
  • “RELEASE-NAME-cert-manager”를 사용하는 Deployment를 패치할 수 없습니다.
  • gitlab-kube-state-metrics를 사용하는 Deployment를 패치할 수 없습니다.
• ImagePullBackOff, Failed to pull image 및 manifest unknown 오류
• UPGRADE FAILED: “cannot patch …” helm 2to3 convert 이후
• UPGRADE FAILED: mailroom의 타입 불일치: %!t(<nil>)
• 복원 실패: ERROR: cannot drop view pg_stat_statements because extension pg_stat_statements requires it
• 번들 PostgreSQL 포드 시작 실패: 데이터베이스 파일이 서버와 호환되지 않음
• 번들 NGINX Ingress 포드 시작 실패: Failed to watch *v1beta1.Ingress
• /api/v4/jobs/request 엔드포인트의 증가된 로드
• SSH를 통한 Git: 원격 끝에서 예기치 않게 종료됨
• YAML 구성: mapping values are not allowed in this context
• TLS 및 인증서
  • 인증서 신뢰 설정 및 문제 해결
  • Rails 콘솔에서 확인하기
  • 초기 컨테이너 문제 해결하기
• 308: Permanent Redirect가 리다이렉트 루프를 일으키는 경우
• nginx-controller 로그에서 “Invalid Word” 오류 및 404 오류
  • 볼륨 마운트 시간이 걸림
  • 간헐적인 502 오류

GitLab 차트 문제 해결

UPGRADE FAILED: Job failed: BackoffLimitExceeded

6.0 버전의 차트로 업그레이드하는 방법에서 이 오류가 발생했다면, 올바른 업그레이드 경로를 따르지 않았기 때문일 수 있습니다. 먼저 최신 5.10.x 버전으로 업그레이드해야 합니다:

1. 모든 릴리스를 나열하여 GitLab Helm 릴리스 이름을 식별하십시오(릴리스가 default K8s 네임스페이스에 배포되지 않은 경우 -n <namespace>를 포함해야 함):

   helm ls
   

2. GitLab Helm 릴리스가 gitlab이라고 가정하면 릴리스 이력을 살펴보고 마지막 성공적인 리비전을 확인해야 합니다(리비전 아래의 DESCRIPTION에서 상태를 확인할 수 있습니다):

   helm history gitlab
   

3. 가장 최근의 성공적인 리비전이 1이라고 가정하고 다음 명령을 사용하여 롤백하십시오:

   helm rollback gitlab 1
   

4. <x>를 적절한 차트 버전으로 바꿔서 업그레이드 명령을 다시 실행하십시오:

   helm upgrade --version=5.10.<x>
   

5. 이 시점에서 --version 옵션을 사용하여 특정 6.x.x 차트 버전을 전달하거나 해당 옵션을 제거하여 GitLab의 최신 버전으로 업그레이드할 수 있습니다:

   helm upgrade --install gitlab gitlab/gitlab <other_options>
   

명령줄 인수에 대한 자세한 내용은 Helm을 사용한 배포 섹션을 참조하세요.

차트 버전과 GitLab 버전 간의 매핑에 대한 내용은 GitLab 버전 매핑을 읽어보세요.

UPGRADE FAILED: “$name” has no deployed releases

이 오류는 초기 설치가 실패했을 경우 두 번째 설치/업그레이드에서 발생합니다.

초기 설치가 완전히 실패하고 GitLab이 작동하지 않았던 경우, 다시 설치하기 전에 실패한 설치를 먼저 삭제해야 합니다.

helm uninstall <release-name>

반대로, 초기 설치 명령이 타임아웃되었지만 GitLab이 여전히 성공적으로 시작되었다면, helm upgrade 명령에 --force 플래그를 추가하여 오류를 무시하고 릴리스를 업데이트하려고 시도할 수 있습니다.

그렇지 않으면 이전에 GitLab 차트의 성공적인 배포가 있었던 경우 이 오류를 경험하게 되며, 이는 버그입니다. 이슈 트래커에 이슈를 열고, 이 문제에서 CI 서버를 복구한 이슈 #630도 확인해 보세요.

Error: this command needs 2 arguments: release name, chart path

이와 같은 오류는 helm upgrade를 실행할 때 매개변수에 공백이 있는 경우 발생할 수 있습니다. 다음 예제에서 Test Username이 문제의 원인입니다:

helm upgrade gitlab gitlab/gitlab --timeout 600s --set global.email.display_name=Test Username ...

이를 수정하려면 매개변수를 작은따옴표로 감싸십시오:

helm upgrade gitlab gitlab/gitlab --timeout 600s --set global.email.display_name='Test Username' ...

애플리케이션 컨테이너가 계속 초기화됨

Sidekiq, Webservice 또는 기타 Rails 기반 컨테이너가 초기화 상태에 있는 경우, dependencies 컨테이너가 성공적으로 통과할 때까지 기다리고 있을 가능성이 높습니다.

주어진 Pod의 dependencies 컨테이너의 로그를 확인하면 다음과 같은 내용이 반복해서 나타날 수 있습니다:

Checking database connection and schema version
WARNING:This version of GitLab depends on gitlab-shell 8.7.1, ...
Database Schema
Current version: 0
Codebase version: 20190301182457

이는 migrations Job이 아직 완료되지 않았음을 나타냅니다. 이 Job의 목적은 데이터베이스가 시드되고 모든 관련 마이그레이션이 준비되었는지 확인하는 것입니다. 애플리케이션 컨테이너는 데이터베이스가 그들의 예상 데이터베이스 버전 이상으로 되어 있기를 기다리고 있습니다. 이는 애플리케이션이 코드베이스의 기대와 일치하지 않는 스키마로 인해 오작동하지 않도록 하기 위함입니다.

1. migrations Job를 찾습니다. kubectl get job -lapp=migrations
2. Job에 의해 실행되는 Pod를 찾습니다. kubectl get pod -ljob-name=<job-name>
3. 출력을 검사하고 STATUS 열을 확인합니다.

STATUS가 Running이면 계속 진행합니다. STATUS가 Completed이면 애플리케이션 컨테이너가 다음 검사 후 곧 시작될 것입니다.

이 Pod의 로그를 검사합니다. kubectl logs <pod-name>

이 작업이 실행되는 동안 실패한 사항은 해결해야 합니다. 이러한 문제는 해결될 때까지 애플리케이션 사용을 차단합니다. 가능한 문제는 다음과 같습니다:

• 구성된 PostgreSQL 데이터베이스에 대한 연결 실패 또는 인증 실패
• 구성된 Redis 서비스에 대한 연결 실패 또는 인증 실패
• Gitaly 인스턴스에 도달하지 못함

구성 변경 적용

다음 명령은 gitlab.yaml에 대한 업데이트를 적용하는 데 필요한 작업을 수행합니다:

helm upgrade <release name> <chart path> -f gitlab.yaml

포함된 GitLab Runner 등록 실패

이는 GitLab에서 러너 등록 토큰이 변경되었을 때 발생할 수 있습니다. (이것은 종종 백업을 복원한 후에 발생합니다)

1. GitLab 설치의 admin/runners 웹페이지에 있는 새로운 공유 러너 토큰을 찾습니다.

2. Kubernetes에 저장된 기존 러너 토큰 비밀의 이름을 찾습니다.

   kubectl get secrets | grep gitlab-runner-secret
   

3. 기존 비밀을 삭제합니다.

   kubectl delete secret <runner-secret-name>
   

4. 두 개의 키를 가진 새로운 비밀을 만듭니다. (runner-registration-token에 공유 토큰을 넣고, 빈 runner-token)

   kubectl create secret generic <runner-secret-name> --from-literal=runner-registration-token=<new-shared-runner-token> --from-literal=runner-token=""
   

너무 많은 리다이렉트

이는 NGINX Ingress 앞에서 TLS 종료가 발생하고, tls-secrets가 구성에 지정되었을 때 발생할 수 있습니다.

1. 값을 업데이트하여 global.ingress.annotations."nginx.ingress.kubernetes.io/ssl-redirect": "false"로 설정합니다.

   값을 파일을 통해:

   # values.yaml
   global:
     ingress:
       annotations:
         "nginx.ingress.kubernetes.io/ssl-redirect": "false"
   

   Helm CLI를 통해:

   helm ... --set-string global.ingress.annotations."nginx.ingress.kubernetes.io/ssl-redirect"=false
   

2. 변경 사항을 적용합니다.

참고:
외부 서비스에서 SSL 종료를 사용하는 경우, 해당 서비스는 https로 리다이렉트할 책임이 있습니다 (필요한 경우).

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

spec.clusterIP

이 차트의 3.0.0 릴리즈 이전에 spec.clusterIP 속성이 여러 서비스에 채워졌습니다 실제 값이 없어("") 문제가 발생했습니다. 이는 버그이며 Helm 3의 속성 3방식 병합에서 문제를 일으킵니다.

Helm 3로 차트가 배포되면, clusterIP 속성을 다양한 서비스에서 수집하고 Helm에 제공된 값에 채우지 않거나, 영향을 받은 서비스가 Kubernetes에서 제거되지 않는 한 업그레이드 경로가 없습니다.

이 차트의 3.0.0 릴리즈는 이 오류를 수정했습니다, 그러나 수동 수정이 필요합니다.

이는 영향을 받는 모든 서비스를 제거함으로써 해결할 수 있습니다.

1. 모든 영향을 받는 서비스를 제거합니다:

   kubectl delete services -lrelease=RELEASE_NAME
   

2. Helm을 통해 업그레이드를 수행합니다.
3. 이후 업그레이드는 이 오류에 직면하지 않을 것입니다.

참고:
이것은 사용 중일 경우 NGINX Ingress의 LoadBalancer에 대한 동적 값을 변경합니다. externalIP에 대한 더 많은 세부정보는 global Ingress settings documentation을 참조하세요. DNS 레코드를 업데이트해야 할 수도 있습니다!

spec.selector

Sidekiq 파드는 차트 릴리즈 3.0.0 이전에 고유한 셀렉터를 받지 않았습니다. 이와 관련된 문제는 기록되어 있습니다.

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

3.0.0 설치 시 Sidekiq 배포에서 여전히 이 오류가 발생하는 경우 다음 단계를 통해 해결하세요:

1. Sidekiq 서비스를 제거합니다.

   kubectl delete deployment --cascade -lrelease=RELEASE_NAME,app=sidekiq
   

2. Helm을 통해 업그레이드를 수행합니다.

“RELEASE-NAME-cert-manager”를 사용하는 Deployment를 패치할 수 없습니다.

CertManager 버전 0.10으로 업그레이드하면서 여러 가지 호환성 문제가 발생했습니다. 오래된 맞춤 리소스 정의는 제거하고 Helm의 추적에서 삭제한 후 다시 설치해야 합니다.

Helm 차트는 기본적으로 이를 시도하지만 이 오류가 발생하면 수동으로 조치를 취해야 할 수 있습니다.

이 오류 메시지가 발생하면, 업그레이드는 새로운 맞춤 리소스 정의가 배포에 실제로 적용되도록 보장하기 위해 일반적인 절차보다 하나의 단계를 더 요구합니다.

1. 오래된 CertManager 배포를 제거합니다.

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

2. 업그레이드를 다시 실행합니다. 이번에는 새로운 맞춤 리소스 정의를 설치합니다.

   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 배포를 제거합니다.

   kubectl delete deployments.apps -l app.kubernetes.io/instance=RELEASE_NAME,app.kubernetes.io/name=kube-state-metrics --cascade=orphan
   

2. Helm을 통해 업그레이드를 수행합니다.

ImagePullBackOff, Failed to pull image 및 manifest unknown 오류

global.gitlabVersion을 사용하는 경우 해당 속성을 제거하는 것으로 시작하세요.

차트와 GitLab 간의 버전 매핑을 확인하고 helm 명령에서 호환 가능한 버전의 gitlab/gitlab 차트를 지정하세요.

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

이것은 알려진 문제입니다. Helm 2 릴리스를 Helm 3로 마이그레이션한 후 이후 업그레이드가 실패할 수 있습니다. 자세한 설명과 해결 방법은 Helm v2에서 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_statements requires it

Helm 차트 인스턴스에서 백업을 복원할 때 이 오류가 발생할 수 있습니다. 다음 단계를 우회 방법으로 사용하세요:

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

   /srv/gitlab/bin/rails dbconsole -p
   

2. 확장을 삭제합니다:

   DROP EXTENSION pg_stat_statements;
   

3. 복원 프로세스를 수행합니다.

4. 복원이 완료된 후 DB 콘솔에서 확장을 다시 생성합니다:

   CREATE EXTENSION pg_stat_statements;
   

pg_buffercache 확장에서 동일한 문제가 발생하는 경우 위와 동일한 단계를 따라 삭제하고 다시 생성합니다.

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

번들 PostgreSQL 포드 시작 실패: 데이터베이스 파일이 서버와 호환되지 않음

다음 오류 메시지는 GitLab Helm 차트를 새 버전으로 업그레이드한 후 번들 PostgreSQL 포드에서 나타날 수 있습니다:

gitlab-postgresql FATAL:  데이터베이스 파일이 서버와 호환되지 않음
gitlab-postgresql DETAIL:  데이터 디렉터리는 PostgreSQL 버전 11로 초기화되었으며, 이 버전 12.7과 호환되지 않습니다.

이를 해결하려면 이전 차트 버전으로 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: 서버에서 요청한 리소스를 찾을 수 없습니다.

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

/api/v4/jobs/request 엔드포인트의 증가된 로드

workhorse.keywatcher 옵션이 /api/*을 제공하는 배포에 대해 false로 설정된 경우 이 문제가 발생할 수 있습니다. 확인하려면 다음 단계를 따르십시오:

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 실패

이 오류의 몇 가지 잠재적인 원인이 있습니다:

• 네트워크 타임아웃:

  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 구성: mapping values are not allowed in this context

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)

개인 인증 기관에서 서명된 인증서의 부분 신뢰가 발생할 수 있는 경우:

• 제공된 인증서가 별도 파일에 있지 않습니다.
• 인증서 init 컨테이너가 모든 필요한 단계를 수행하지 않습니다.

또한, GitLab은 대부분 Ruby on Rails와 Go로 작성되었으며, 각 언어의 TLS 라이브러리는 다르게 작동합니다. 이러한 차이로 인해 작업 로그가 GitLab UI에 렌더링되지 않지만 원시 작업 로그는 문제 없이 다운로드되는 등의 문제가 발생할 수 있습니다.

추가적으로, proxy_download 구성에 따라 브라우저는 신뢰 저장소가 올바르게 구성되어 있으면 문제 없이 객체 저장소로 리디렉션됩니다. 동시에 하나 이상의 GitLab 구성 요소에 의해 TLS 핸드쉐이크가 여전히 실패할 수 있습니다.

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

인증서 문제를 해결하는 과정의 일환으로 다음을 확인하세요:

• 신뢰해야 할 각 인증서에 대한 비밀을 생성하세요.

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

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

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

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

kubectl get secrets와 kubectl describe secrets/secretname로 비밀을 조회할 수 있으며, 이는 Data 아래의 인증서에 대한 키 이름을 보여줍니다.

추가 인증서를 신뢰하도록 제공하려면 global.certificates.customCAs를 차트 전역 설정에서 사용하세요.

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

추가 인증서는 /usr/local/share/ca-certificates에 컨테이너에 마운트되며, 비밀 키 이름을 인증서 파일 이름으로 사용합니다.

init 컨테이너는 /scripts/bundle-certificates를 실행합니다 (source).

이 스크립트에서 update-ca-certificates는:

1. /usr/local/share/ca-certificates에서 사용자 정의 인증서를 /etc/ssl/certs로 복사합니다.
2. ca-certificates.crt 번들을 컴파일합니다.

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

   WARNING:unique_name does not contain exactly one certificate or CRL: skipping
   

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 확인 비활성화
   
   response = http.request(Net::HTTP::Get.new(uri.request_uri))
   

초기 컨테이너 문제 해결하기

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

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는 Load Balancer가 NGINX로 암호화되지 않은 트래픽(HTTP)을 보내도록 구성된 경우 발생할 수 있습니다.

NGINX는 기본적으로 HTTP를 HTTPS로 리다이렉션하므로, “리다이렉트 루프”에 빠질 수 있습니다.

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

nginx-controller 로그에서 “Invalid Word” 오류 및 404 오류

Helm 차트 6.6 이상으로 업그레이드한 후, 클러스터에 설치된 GitLab 또는 타사 도메인을 방문할 때 404 반환 코드가 발생할 수 있으며, gitlab-nginx-ingress-controller 로그에서 “invalid word” 오류도 확인할 수 있습니다:

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 설정을 조정하거나 수정해야 할 수 있습니다.

추가 세부정보는 주석 값 단어 차단 목록을 참조하세요.

볼륨 마운트 시간이 걸림

gitaly 또는 toolbox 차트 볼륨과 같은 큰 볼륨을 마운트하는 데 오랜 시간이 걸릴 수 있습니다.

Kubernetes는 Pod의 securityContext에 맞게 볼륨의 내용에 대한 권한을 재귀적으로 변경하기 때문입니다.

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

예를 들어 Gitaly 서브차트의 경우:

gitlab:
  gitaly:
    securityContext:
      fsGroupChangePolicy: "OnRootMismatch"

자세한 내용은 Kubernetes 문서를 참조하세요.

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

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

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"}

이 문제를 해결하려면, 웹 서비스 포드의 메모리 한계를 늘리십시오.