- UPGRADE FAILED: 작업 실패: BackoffLimitExceeded
- UPGRADE FAILED: “$name”에 배포된 릴리스가 없음
- Error: this command needs 2 arguments: release name, chart path
- 응용 프로그램 컨테이너가 계속 초기화 중인 경우
- 구성 변경 적용
- 포함된 GitLab Runner의 등록 실패
- 너무 많은 리디렉션
- 불변 필드 오류로 업그레이드에 실패
ImagePullBackOff,Failed to pull image및manifest unknown오류helm 2to3 convert후 “cannot patch …” 업그레이드 실패type mismatch on mailroom:%!t()` 업그레이드 실패 - 복구 실패:
ERROR: cannot drop view pg_stat_statements because extension pg_stat_statements requires it - 번들 PostgreSQL pod 시작하지 못함:
database files are incompatible with server - 번들 NGINX Ingress pod 시작하지 못함:
Failed to watch *v1beta1.Ingress /api/v4/jobs/request엔드포인트의 부하 증가- SSH를 통한 Git:
the remote end hung up unexpectedly - YAML 구성:
매핑 값은이 컨텍스트에서 허용되지 않습니다 - TLS 및 인증서
308: Permanent Redirect로 인한 리디렉트 루프-
nginx-controller로그에서 “잘못된 단어” 오류 및404오류
GitLab 차트 문제 해결
UPGRADE FAILED: 작업 실패: BackoffLimitExceeded
만약 차트의 6.0 버전으로 업그레이드하는 중에 이 오류를 받았다면, 아마도 올바른 업그레이드 경로를 따르지 않은 것이므로, 먼저 최신 5.10.x 버전으로 업그레이드해야 합니다:
-
GitLab Helm 릴리스 이름을 식별하기 위해 모든 릴리스 디렉터리을 보세요(
defaultK8s namespace로 배포하지 않은 경우-n <namespace>를 포함해야 합니다):helm ls -
GitLab Helm 릴리스가
gitlab로 가정하고, 마지막 성공한 리비전을 식별하기 위해 릴리스 히스토리를 확인해야 합니다 (DESCRIPTION아래에서 리비전의 상태를 볼 수 있음):helm history gitlab -
가장 최근의 성공한 리비전이
1이라고 가정하면 다음 명령을 사용하여 롤백합니다:helm rollback gitlab 1 -
<x>를 적절한 차트 버전으로 대체하여 upgrade 명령을 다시 실행하세요:helm upgrade --version=5.10.<x> -
이 시점에서
--version옵션을 사용하여 특정 6.x.x 차트 버전을 전달하거나, GitLab의 최신 버전으로 업그레이드할 수 있습니다:helm upgrade --install gitlab gitlab/gitlab <other_options>
명령줄 인수에 대한 자세한 정보는 Helm을 사용하여 배포 섹션에서 찾을 수 있습니다. 차트 버전 및 GitLab 버전 간의 매핑에 대한 내용은 GitLab 버전 매핑을 참조하세요.
UPGRADE FAILED: “$name”에 배포된 릴리스가 없음
이 오류는 초기 설치가 실패한 후 두 번째 설치/업그레이드에서 발생합니다.
초기 설치가 완전히 실패하고, GitLab이 운영되지 않았다면, 먼저 다시 설치하기 전에 실패한 설치를 삭제해야 합니다.
helm uninstall <릴리스 이름>
반면에, 초기 설치 명령이 시간 초과되었지만 GitLab이 성공적으로 실행된 경우, --force 플래그를 helm upgrade 명령에 추가하여 오류를 무시하고 릴리스를 업데이트 시도할 수 있습니다.
그렇지 않으면, 이 오류가 성공적으로 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 컨테이너의 로그를 확인하면, 반복적으로 다음을 볼 수 있습니다:
데이터베이스 연결 및 스키마 버전 확인 중
경고: 이 버전의 GitLab은 gitlab-shell 8.7.1에 의존하고 있습니다. ...
데이터베이스 스키마
현재 버전: 0
코드베이스 버전: 20190301182457
이것은 migrations 작업이 아직 완료되지 않았음을 나타냅니다. 이 작업의 목적은 데이터베이스가 초기화되고 모든 관련 마이그레이션이 적용되었음을 보장하는 것입니다. 응용 프로그램 컨테이너는 데이터베이스가 예상한 데이터베이스 버전 이상이거나 동일한지를 기다리려고 시도합니다. 이렇게 함으로써 응용 프로그램이 코드베이스의 스키마와 일치하지 않는다는 기대에 맞게 코드를 저지하지 않도록 합니다.
-
migrations작업을 찾으세요.kubectl get job -lapp=migrations - 작업에 의해 실행되는 pod을 찾으세요.
kubectl get pod -ljob-name=<job-name> -
STATUS열을 확인하여 출력을 검사하세요.
만약 STATUS가 Running이면 계속 진행하세요. STATUS가 Completed라면, 다음 확인이 통과한 후 잠시 후 응용 프로그램 컨테이너가 시작될 것입니다.
이 pod에서 로그를 확인하세요. kubectl logs <pod-name>
이 작업 실행 중에 실패가 있으면 처리해야 합니다. 이러한 실패는 해결되기 전까지 응용 프로그램 사용을 차단합니다. 가능한 문제는 다음과 같습니다:
- 구성된 PostgreSQL 데이터베이스로의 접근이 불가능하거나 인증에 실패함
- 구성된 Redis 서비스로의 접근이 불가능하거나 인증에 실패함
- Gitaly 인스턴스에 도달하지 못함
구성 변경 적용
다음 명령은 gitlab.yaml에 적용된 업데이트를 수행합니다:
helm upgrade <릴리스 이름> <차트 경로> -f gitlab.yaml
포함된 GitLab Runner의 등록 실패
이 경우는 GitLab에서 runner 등록 토큰이 변경된 경우에 발생할 수 있습니다 (주로 백업을 복원한 후 발생합니다).
- GitLab 설치의
admin/runners웹페이지에서 새로운 공유 Runner 토큰을 찾으세요. -
Kubernetes에 저장된 기존 Runner 토큰 시크릿의 이름을 찾으세요
kubectl get secrets | grep gitlab-runner-secret -
기존 시크릿을 삭제하세요
kubectl delete secret <runner-secret-name> -
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가 지정된 경우에 발생할 수 있습니다.
-
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 -
변경사항을 적용하세요.
불변 필드 오류로 업그레이드에 실패
spec.clusterIP
이 차트의 3.0.0 릴리스 이전에는 spec.clusterIP 속성이 실제 값("")이 없음에도 불구하고 여러 서비스에 채워져 있었습니다. 이것은 Helm 3의 속성을 세 방향으로 Merge하는 문제를 초래하는 버그였습니다.
차트가 Helm 3로 배포된 후에, 서비스들에서 clusterIP 속성을 수집하고 Helm에 제공된 값으로 넣거나 영향 받는 서비스를 Kubernetes에서 제거하지 않는 한 가능한 업그레이드 경로가 없을 것입니다.
이 차트의 3.0.0 릴리스는 이 오류를 수정했지만, 이것은 매뉴얼으로 수정해야 합니다.
이 문제는 영향을 받는 모든 서비스를 단순히 제거하여 해결할 수 있습니다.
-
영향받는 모든 서비스를 제거하세요:
kubectl delete services -lrelease=RELEASE_NAME - Helm을 통해 업그레이드를 수행하세요.
- 이후의 업그레이드는 이 오류를 겪지 않아야 합니다.
LoadBalancer의 동적 값을 변경하며, 이에 따라 externalIP에 대한 DNS 레코드를 업데이트해야 할 수 있습니다!
externalIP에 대한 자세한 내용은 글로벌 Ingress 설정 문서를 참조하세요.spec.selector
차트 릴리스 이전에 Sidekiq pod에 고유한 셀렉터가 제공되지 않았습니다 3.0.0. 이에 대한 문제는 여기에서 문서화되어 있습니다.
Helm을 사용하여 3.0.0으로 업그레이드하면 이전 Sidekiq 배포를 자동으로 삭제하고 새로운 배포를 만들 때 Sidekiq Deployments, HPAs 및 Pods 이름에 -v1을 추가합니다.
3.0.0을 설치하는 동안이 Sidekiq 배포에서 계속해서 이 오류가 발생하면 다음 단계로 이를 해결하세요.
-
Sidekiq 서비스를 제거합니다.
kubectl delete deployment --cascade -lrelease=RELEASE_NAME,app=sidekiq -
Helm을 통해 업그레이드를 수행하세요.
“RELEASE-NAME-cert-manager”에 대해 “cannot patch“오류 발생
CertManager 버전 0.10에서 업그레이드하면 여러 개의 호환되지 않는 변경 사항이 발생합니다. 이전 사용자 정의 리소스 정의를 Helm의 추적에서 제거하고 다시 설치해야 합니다.
Helm 차트는 기본적으로 이 작업을 수행하려고 시도하지만 이 오류가 발생하면 매뉴얼 조치가 필요할 수 있습니다.
만약 이 오류 메시지가 발생했다면 새로운 사용자 정의 리소스 정의가 실제로 배포에 적용되도록 하기 위해 정상적인 것보다 한 단계 더 필요합니다.
-
이전 CertManager 배포를 제거합니다.
kubectl delete deployments -l app=cert-manager --cascade -
다시 업그레이드를 실행합니다. 이번에는 새로운 사용자 정의 리소스 정의를 설치합니다.
helm upgrade --install --values - YOUR-RELEASE-NAME gitlab/gitlab < <(helm get values YOUR-RELEASE-NAME)
gitlab-kube-state-metrics에서 “cannot patch” 오류
Prometheus 버전 11.16.9에서 15.0.4로 업그레이드하면 기본적으로 비활성화된 (prometheus.kubeStateMetrics.enabled=false) kube-state-metrics 배포의 셀렉터 레이블이 변경됩니다.
이 오류 메시지가 발생한다면, 즉 prometheus.kubeStateMetrics.enabled=true이면 추가 조치가 필요합니다:
-
이전 kube-state-metrics 배포를 제거합니다.
kubectl delete deployments.apps -l app.kubernetes.io/instance=RELEASE_NAME,app.kubernetes.io/name=kube-state-metrics --cascade=orphan -
Helm을 통해 업그레이드를 수행하세요.
ImagePullBackOff, Failed to pull image 및 manifest unknown 오류
만약 global.gitlabVersion을 사용하고 있다면, 해당 속성을 제거하는 것으로 시작하세요.
차트와 GitLab 간의 버전 매핑을 확인하고 helm 명령어에서 gitlab/gitlab 차트의 호환 가능한 버전을 지정하세요.
helm 2to3 convert 후 “cannot patch …” 업그레이드 실패
이는 알려진 문제입니다. Helm 2 릴리스를 Helm 3로 마이그레이션한 후 계속해서 업그레이드가 실패할 수 있습니다. Helm v2에서 Helm v3로 마이그레이션에서 자세한 설명과 해결 방법을 찾을 수 있습니다.
type mismatch on mailroom: %!t()` 업그레이드 실패
이러한 오류는 유효한 맵을 기대하는 키에 유효한 맵을 제공하지 않았을 때 발생할 수 있습니다.
예를 들어, 아래 구성은 이러한 오류를 발생시킵니다:
gitlab:
mailroom:
이를 해결하려면 다음 중 하나를 수행하십시오:
-
gitlab.mailroom에 유효한 맵을 제공합니다. -
mailroom키를 완전히 제거합니다.
선택적 키의 경우 빈 맵({})은 유효한 값입니다.
복구 실패: ERROR: cannot drop view pg_stat_statements because extension pg_stat_statements requires it
Helm 차트 인스턴스에 백업을 복원하는 동안이 오류가 발생할 수 있습니다. 다음 단계를 해결책으로 사용하세요.
-
toolbox파드 내에서 DB 콘솔을 엽니다./srv/gitlab/bin/rails dbconsole -p -
확장을 삭제합니다.
DROP EXTENSION pg_stat_statements; - 복원 프로세스를 수행합니다.
-
복원이 완료된 후, DB 콘솔에서 확장을 다시 만듭니다.
CREATE EXTENSION pg_stat_statements;
pg_buffercache 확장에 대해 동일한 문제가 발생하면 동일한 단계를 수행하여 삭제하고 다시 만드세요.
이 오류에 대한 자세한 내용은 이슈 #2469에서 찾을 수 있습니다.
번들 PostgreSQL pod 시작하지 못함: database files are incompatible with server
GitLab Helm 차트의 새 버전으로 업그레이드한 후 번들 PostgreSQL pod에서 다음과 같은 오류 메시지가 표시될 수 있습니다.
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 pod 시작하지 못함: 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로 설정했다면 이 문제가 발생할 수 있습니다. 다음 단계를 통해 확인하세요:
-
/api/*를 제공하는 pod에서gitlab-workhorse컨테이너에 액세스합니다.kubectl exec -it --container=gitlab-workhorse <gitlab_api_pod> -- /bin/bash -
/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: the remote end hung up unexpectedly
SSH를 통한 Git 작업이 다음 오류와 함께 때때로 실패할 수 있습니다:
fatal: the remote end hung up unexpectedly
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를 실행하여 이것이 네트워크 타임아웃이 아니라 메모리 제한 때문인지 확인하세요.System OOM encountered, victim process: gitlab-shell Memory cgroup out of memory: Killed process 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: 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)
개인 인증 기관으로 서명된 인증서의 일부 신뢰가 발생할 수 있으며, 이는 다음과 관련이 있습니다:
- 제공된 인증서가 별도의 파일에 없는 경우
- 인증 기관이 필요한 모든 단계를 수행하지 않는 경우
또한, GitLab은 대부분 루비 온 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 컴포넌트가 작동하지 않을 수 있습니다.
인증서를 global.certificates.customCAs에 추가로 제공하기 위해 차트 Globals를 사용하십시오.
pod이 배포되면 init 컨테이너가 인증서를 마운트하고 GitLab 컴포넌트에서 사용할 수 있도록 설정합니다. 이니셜 컨테이너는 registry.gitlab.com/gitlab-org/build/cng/alpine-certificates입니다.
추가 인증서는 /usr/local/share/ca-certificates에 마운트되며, 시크릿 키 이름은 인증서 파일 이름으로 사용됩니다.
이니셜 컨테이너는 /scripts/bundle-certificates를 실행합니다 (소스). 이 스크립트에서 update-ca-certificates는 다음을 수행합니다:
-
/usr/local/share/ca-certificates의 사용자 정의 인증서를/etc/ssl/certs에 복사합니다. - 번들
ca-certificates.crt을 컴파일합니다. -
각 인증서에 대한 해시를 생성하고 Rails용으로 필요한 심볼릭 링크를 생성합니다. 이는 Rails에 필요합니다. 인증서 번들은 경고와 함께 건너뛰어집니다:
WARNING: unique_name does not contain exactly one certificate or CRL: skipping
이니셜 컨테이너의 상태와 로그를 문제 해결하십시오. 예를 들어, 인증서 이니셜 컨테이너의 로그를 보고 경고를 확인하십시오:
kubectl logs gitlab-webservice-default-pod -c certificates
Rails 콘솔 확인
제공한 인증서가 Rails가 신뢰하는지 확인하기 위해 도구 상자 파드를 사용하십시오.
-
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 -
Rails가 인증 기관을 확인하는 위치를 확인하십시오:
OpenSSL::X509::DEFAULT_CERT_DIR -
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를 사용하여 인증서 컨테이너를 실행하십시오.
-
디렉터리 구조를 설정하고 인증서를 채워넣으십시오:
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 -
올바른 컨테이너 버전을 확인하십시오:
kubectl get deployment -lapp=webservice -ojsonpath='{.items[0].spec.template.spec.initContainers[0].image}' -
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 -
인증서가 올바르게 작성되었는지 확인하십시오:
-
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로 인한 리디렉트 루프
로드 밸런서가 암호화되지 않은 트래픽(HTTP)을 NGINX로 보내도록 구성된 경우 308: Permanent Redirect가 발생할 수 있습니다. NGINX는 기본적으로 HTTP를 HTTPS로 리디렉팅하므로 “리디렉트 루프”에 빠질 수 있습니다.
이를 수정하려면 NGINX의 use-forwarded-headers 설정을 활성화하십시오.
nginx-controller 로그에서 “잘못된 단어” 오류 및 404 오류
차트 6.6 이상으로 업그레이드한 후, 클러스터에 설치된 응용 프로그램에 대한 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 객체를 configuration snippets의 사용에 대해 검토하십시오. nginx-ingress.controller.config.annotation-value-word-blocklist 설정을 조정하거나 수정해야 할 수 있습니다.
추가 세부 정보는 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: {} 또는 securityContext:로 설정하는 것은 동작하지 않습니다. 이는 Helm이 기본값을 사용자가 제공한 구성과 Merge하는 방식 때문입니다.간헐적인 502 오류
Puma 워커가 메모리 제한 임계값을 넘는 요청을 처리하는 경우 해당 요청은 노드의 OOMKiller에 의해 종료됩니다. 그러나 요청을 종료시키는 것은 반드시 webservice 파드 자체를 종료하거나 다시 시작시키지는 않습니다. 이 상황은 요청이 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"}
이 문제를 해결하려면 webservice 파드의 메모리 제한을 높이세요.
도움말