• 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: helm 2to3 convert 후 “cannot patch …” 오류
• UPGRADE FAILED: mailroom에 대한 타입 불일치: %!t(<nil>)
• 복원 실패: ERROR: cannot drop view pg_stat_statements because extension pg_stat_statements requires it
• 번들 PostgreSQL 팟이 시작하지 못하는 문제: database files are incompatible with server
• 번들 NGINX Ingress 팟이 시작하지 못하는 문제: Failed to watch *v1beta1.Ingress
• /api/v4/jobs/request 엔드포인트에서 부하 증가
• SSH를 통한 Git: 원격 단이 예기치 못하게 연결을 끊었습니다
• YAML 구성: 매핑 값은 이 문맥에서 허용되지 않습니다
• TLS 및 인증서
  • 인증서 신뢰 설정 및 문제 해결
  • Rails 콘솔 확인
  • 초기화 컨테이너 문제 해결
• 308: Permanent Redirect로 인한 리다이렉트 루프
• nginx-controller 로그에서의 “Invalid Word” 오류 및 404 오류
  • Volume mount 작업이 오래 걸립니다
  • 간헐적인 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이 여전히 성공적으로 실행된 경우, 오류를 무시하고 릴리스를 업데이트하려면 --force 플래그를 helm upgrade 명령에 추가할 수 있습니다.

그렇지 않으면, 이 오류가 이전에 GitLab 차트를 성공적으로 배포했던 후에 발생했다면 버그가 발생한 것입니다. 저희 이슈 트래커에서 이슈를 열어주시기 바라며, 이 문제와 관련하여 이슈 #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 컨테이너에 대한 내용을 확인하면 아래 내용이 반복될 수 있습니다:

데이터베이스 연결 및 스키마 버전 확인
경고: 이 GitLab 버전은 gitlab-shell 8.7.1에 의존합니다, ...
데이터베이스 스키마
현재 버전: 0
코드베이스 버전: 20190301182457

이것은 migrations Job이 아직 완료되지 않았음을 나타냅니다. 이 Job의 목적은 데이터베이스가 시드되고 모든 관련 마이그레이션이 완료되도록 하는 것입니다. 애플리케이션 컨테이너는 데이터베이스가 기대한 데이터베이스 버전 이상이거나 동일하도록 기다리려고 합니다. 이것은 애플리케이션이 코드베이스의 기대에 맞지 않는 스키마로 인해 오작동하지 않도록 하기 위한 것입니다.

1. migrations Job을 찾습니다. kubectl get job -lapp=migrations
2. Job에서 실행 중인 Pod를 찾습니다. kubectl get pod -ljob-name=<job-name>
3. STATUS 열을 확인하여 해당 pod의 상태를 확인합니다.

만약 STATUS가 Running이라면 계속 진행하세요. STATUS가 Completed라면, 다음 체크가 통과한 후에 애플리케이션 컨테이너가 곧 시작될 것입니다.

이 pod의 로그를 확인합니다. kubectl logs <pod-name>

이 Job 실행 중의 어떤 실패든 해결해야 합니다. 이러한 실패는 해결하기 전까지 애플리케이션의 사용을 차단할 것입니다. 가능한 문제는:

• 구성된 PostgreSQL 데이터베이스에 대한 접근 불가능 또는 인증 실패
• 구성된 Redis 서비스에 대한 접근 불가능 또는 인증 실패
• Gitaly 인스턴스에 연결 실패

구성 변경 적용

gitlab.yaml에 대한 업데이트를 적용하기 위해 다음 명령을 실행합니다.

helm upgrade <릴리스 이름> <차트 경로> -f gitlab.yaml

포함된 GitLab Runner가 등록에 실패하는 경우

이는 GitLab에서 실행자 등록 토큰이 변경된 경우에 발생할 수 있습니다. (보통 백업을 복원한 후에 발생합니다)

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

2. Kubernetes에 저장된 기존 실행자 토큰 비밀 정보의 이름을 찾습니다.

   kubectl get secrets | grep gitlab-runner-secret
   

3. 기존 시크릿을 삭제합니다.

   kubectl delete secret <러너-시크릿-이름>
   

4. (runner-registration-token에 새로운 공유 토큰과 비어있는 runner-token으로) 두 개의 키를 가진 새 시크릿을 생성합니다.

   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로 설정합니다.

   값 파일을 통해:

   # 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의 속성 세 가지 병합에 문제를 일으킵니다.

Helm 3로 차트를 배포하면 각 서비스의 clusterIP 속성을 수집하여 Helm에 제공된 값으로 채워넣거나 해당 서비스를 Kubernetes에서 제거하지 않는 한 업그레이드 경로가 없게 됩니다.

이 오류를 해결하려면 간단히 영향 받는 모든 서비스를 제거합니다.

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

   kubectl delete services -l release=릴리스_이름
   

2. Helm을 통해 업그레이드를 실행합니다.
3. 향후 업그레이드에서 이 오류가 발생하지 않습니다.

참고: 이것은 사용 중인 경우 이 차트의 NGINX Ingress를 위한 LoadBalancer의 동적 값 변경할 수 있습니다. externalIP에 대한 자세한 내용은 전역 Ingress 설정 설명서를 참조하세요. DNS 레코드를 업데이트해야 할 수도 있습니다!

spec.selector

버전 3.0.0을 설치하기 전에 Sidekiq 팟은 고유한 셀렉터를받지 않았습니다. 이 문제에 대한 문제점은 여기에 문서화되어 있습니다.

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

5.5.0부터 Helm은 이전 버전의 기존 Sidekiq 배포를 삭제하고 Pods, Deployments 및 HPAs에 -v2 접미사를 사용합니다.

3.0.0을 설치할 때 Sidekiq 배포에서 계속해서이 오류가 발생하는 경우 다음 단계로 이것을 해결하세요:

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

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

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

“RELEASE-NAME-cert-manager”에 “DEPLOYMENT”의 패치를 할 수 없음

CertManager 버전 0.10에서 업그레이드하는 것은 여러 가지 파괴적인 변경 사항을 가져왔습니다. 기존 Custom Resource Definitions은 제거되어야 하고 Helm의 추적에서 제거되어야 합니다.

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

만약이 오류 메시지가 만나게 된다면 새로운 Custom Resource Definitions이 실제로 배포에 적용되도록 하기 위해 일반적인 업그레이드보다 한 단계 더 필요합니다.

1. 이전 CertManager 배포를 제거합니다.

    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=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: helm 2to3 convert 후 “cannot patch …” 오류

이는 알려진 문제입니다. 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_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 확장에 대해 동일한 문제가 발생하면, 동일한 단계를 따라 확장을 삭제하고 다시 생성하십시오.

이 오류에 대한 더 많은 세부 정보는 이슈 #2469에서 확인할 수 있습니다.

번들 PostgreSQL 팟이 시작하지 못하는 문제: database files are incompatible with server

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

gitlab-postgresql FATAL:  database files are incompatible with server
gitlab-postgresql DETAIL:  The data directory was initialized by PostgreSQL version 11, which is not compatible with this version 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: the server could not find the requested resource

이 문제를 해결하려면 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: 이른 EOF
fatal: index-pack이 실패했습니다

이 오류의 잠재적인 원인은 다음과 같습니다:

• 네트워크 시간 초과:

  Git 클라이언트는 때로 연결을 여는데 그 후 압축 작업 등에 의해 미루어져 있는 상태로 남겨둘 수 있습니다. 이러한 미루어진 연결이 HAProxy의 timeout client와 같은 설정 때문에 종료될 수 있습니다.

  GitLab 14.0 (차트 버전 5.0) 이후로, 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
  메모리 컨트롤 그룹의 메모리가 부족함: 프로세스 3141592 (gitlab-shell)가 종료됨
  

YAML 구성: 매핑 값은 이 문맥에서 허용되지 않습니다

다음 오류 메시지는 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: 매핑 값은 이 문맥에서 허용되지 않습니다

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

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

key1: value1
key2: value2

…에서 다음과 같이 변경합니다:

key1: value1
key2: value2

이 변경으로 GitLab 14.5 (차트 버전 5.5.0) 에서 추가된 gomplate에 의해 구성이 올바르게 채워질 수 있습니다.

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를 사용하여 추가적인 신뢰할 수 있는 인증서 차트 글로벌에 제공하세요.

팟이 배포될 때, 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 콘솔 확인

도구 상자 pod를 사용하여 제공한 인증서를 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))
   

초기화 컨테이너 문제 해결

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

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

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

Helm 차트 6.6 이상으로 업그레이드한 후에, 클러스터에 설치된 애플리케이션의 GitLab 또는 써드파티 도메인을 방문할 때 404 반환 코드와 함께 “invalid word” 오류가 발생할 수 있습니다. 이 경우, GitLab 값 및 써드파티 Ingress 객체를 검토하여 구성 조각을 사용하는지 확인하세요. nginx-ingress.controller.config.annotation-value-word-blocklist 설정을 조정하거나 수정해야 할 수 있습니다.

자세한 내용은 Annotation value word blocklist를 참조하세요.

Volume mount 작업이 오래 걸립니다

gitaly 또는 toolbox 차트 볼륨과 같이 큰 볼륨을 마운트하면 Kubernetes가 볼륨의 내용의 권한을 Pod의 securityContext에 맞게 재귀적으로 변경하기 때문에 오랜 시간이 걸릴 수 있습니다.

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

예를 들어 Gitaly subchart의 경우:

gitlab:
  gitaly:
    securityContext:
      fsGroupChangePolicy: "OnRootMismatch"

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

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

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

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

간헐적인 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"}

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