GitLab 차트의 저장소 구성

Tier: Free, Premium, Ultimate Offering: Self-managed

GitLab 차트 내의 다음 애플리케이션은 상태를 유지하기 위해 지속적인 저장소가 필요합니다.

  • Gitaly (Git 리포지토리를 유지함)
  • PostgreSQL (GitLab 데이터베이스 데이터를 유지함)
  • Redis (GitLab 작업 데이터를 유지함)
  • MinIO (객체 저장 데이터 유지)

관리자는 동적 또는 정적 볼륨 프로비저닝을 사용하여 이 저장소를 프로비저닝할 수 있습니다.

중요: 사전 계획을 통해 설치 후 추가 저장소 마이그레이션 작업을 최소화하세요. 첫 배포 후에 변경 사항은 helm upgrade를 실행하기 전에 기존 Kubernetes 객체를 수동으로 편집해야 합니다.

일반 설치 동작

설치 관리자는 기본 저장소 클래스를 사용하여 저장소를 생성하고 동적 볼륨 프로비저닝을 수행합니다. 애플리케이션은 지속적 볼륨 클레임을 통해 이 저장소에 연결됩니다. 관리자는 사용 가능한 경우 동적 볼륨 프로비저닝을 사용하는 것이 좋습니다.

관리자는 kubectl get storageclass를 사용하여 프로덕션 환경에서 기본 저장소 클래스를 결정한 후 kubectl describe storageclass *STORAGE_CLASS_NAME*을 사용하여 이를 검토해야 합니다. Amazon EKS와 같은 일부 제공자는 기본 저장소 클래스를 제공하지 않습니다.

클러스터 저장소 구성

권장 사항

기본 저장소 클래스는 다음을 충족해야 합니다:

  • 사용 가능한 경우 빠른 SSD 저장소를 사용하십시오.
  • reclaimPolicy를 Retain으로 설정하십시오.

reclaimPolicy가 Retain으로 설정되지 않은 상태에서 GitLab을 제거하면 자동화된 작업이 볼륨, 디스크 및 데이터를 완전히 삭제할 수 있습니다. 일부 플랫폼은 기본 reclaimPolicy를 Delete로 설정합니다. gitaly 지속적 볼륨 클레임은 StatefulSet에 속해 있으므로 이 규칙을 따르지 않습니다.

최소 저장소 클래스 구성

다음 YAML 구성은 GitLab을 위한 사용자 정의 저장소 클래스를 생성하는 데 필요한 최소한의 요구 사항을 제공합니다. 설치 환경에 적합한 값으로 CUSTOM_STORAGE_CLASS_NAME을 교체하십시오.

일부 사용자는 Amazon EKS가 노드 생성이 항상 파드와 같은 영역에 있지 않은 동작을 보인다고 보고합니다. 위의 zone 매개변수를 설정하면 위험을 완화할 수 있습니다.

사용자 정의 저장소 클래스 사용

사용자 정의 저장소 클래스를 클러스터 기본값으로 설정하면 모든 동적 프로비저닝에 사용됩니다.

kubectl patch storageclass CUSTOM_STORAGE_CLASS_NAME -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

또는 설치 중 Helm에 서비스마다 사용자 정의 저장소 클래스와 기타 옵션을 제공할 수 있습니다. 제공된 예제 구성 파일을 참조하고 환경에 맞게 수정하십시오.

helm install -upgrade gitlab gitlab/gitlab -f HELM_OPTIONS_YAML_FILE

더 읽어보려면 아래 링크를 참고하고 추가 지속성 옵션을 확인하세요:

참고: 일부 고급 지속성 옵션은 PostgreSQL과 다른 경우가 다르므로 변경을 하기 전에 각 문서를 확인하는 것이 중요합니다.

정적 볼륨 프로비저닝 사용하기

동적 볼륨 프로비저닝이 권장되지만, 일부 클러스터 또는 환경에서는 이를 지원하지 않을 수 있습니다. 관리자는 지속적인 볼륨을 수동으로 생성해야 합니다.

Google GKE 사용하기

  1. 클러스터에 지속 디스크를 생성합니다.
gcloud compute disks create --size=50GB --zone=*GKE_ZONE* *DISK_VOLUME_NAME*
  1. 예제 YAML 구성을 수정한 후 Persistent Volume을 생성합니다.
kubectl create -f *PV_YAML_FILE*

Amazon EKS 사용하기

참고:

여러 영역에 배포해야 하는 경우, 저장 솔루션을 정의할 때 Amazon의 자체 문서를 검토해야 합니다.

  1. 클러스터에 지속 디스크를 생성합니다.
aws ec2 create-volume --availability-zone=*AWS_ZONE* --size=10 --volume-type=gp2
  1. 예제 YAML 구성을 수정한 후 Persistent Volume을 생성합니다.
kubectl create -f *PV_YAML_FILE*

PersistentVolumeClaims 수동으로 생성하기

Gitaly 서비스는 StatefulSet을 사용하여 배포됩니다. 올바르게 인식되고 사용될 수 있도록 아래의 명명 규칙을 사용하여 PersistentVolumeClaim을 생성합니다.

<mount-name>-<statefulset-pod-name>

Gitaly의 mount-name은 repo-data입니다. StatefulSet Pod 이름은 다음 형식으로 생성됩니다:

<statefulset-name>-<pod-index>

GitLab 차트는 다음을 사용하여 statefulset-name을 결정합니다:

<chart-release-name>-<service-name>

Gitaly PersistentVolumeClaim의 올바른 이름은: repo-data-gitlab-gitaly-0입니다.

참고: 여러 개의 Virtual Storage가 있는 Praefect를 사용하는 경우, 정의된 각 Gitaly 복제본마다 하나의 PersistentVolumeClaim이 필요합니다. 예를 들어, default 및 vs2라는 두 개의 Virtual Storage가 각각 2개의 복제본을 가지고 있는 경우, 다음과 같은 PersistentVolumeClaims가 필요합니다:

  • repo-data-gitlab-gitaly-default-0
  • repo-data-gitlab-gitaly-default-1
  • repo-data-gitlab-gitaly-vs2-0
  • repo-data-gitlab-gitaly-vs2-1

환경에 맞게 예제 YAML 구성을 수정하고 helm 호출 시 참조합니다.

StatefulSet을 사용하지 않는 다른 서비스는 관리자가 volumeName을 구성에 제공할 수 있도록 합니다. 이 차트는 여전히 볼륨 클레임을 생성하고 수동으로 생성된 볼륨에 바인딩을 시도합니다. 포함된 각 애플리케이션에 대한 차트 문서를 확인하십시오.

대부분의 경우, 수동으로 생성된 디스크 볼륨을 사용할 서비스만 남기고 예제 YAML 구성을 수정하면 됩니다.

설치 후 스토리지 변경하기

초기 설치 후, 새로운 볼륨으로 마이그레이션하거나 디스크 크기를 변경하는 등의 스토리지 변경은 Helm 업그레이드 명령 외부에서 Kubernetes 객체를 편집해야 합니다.

지속적인 볼륨 관리 문서를 참조하세요.

선택적 볼륨

더 큰 설치의 경우, 백업/복원을 작동시키기 위해 Toolbox에 지속 저장소를 추가해야 할 수 있습니다. 이를 수행하는 방법에 대한 가이드는 문제 해결 문서를 참조하세요.