GitLab 차트의 저장소 구성

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

GitLab 차트 내의 다음 응용 프로그램은 상태를 유지하기 위해 지속적인 저장소를 필요로 합니다.

  • Gitaly (Git 저장소 유지)
  • PostgreSQL (GitLab 데이터베이스 데이터 유지)
  • Redis (GitLab 작업 데이터 유지)
  • MinIO (객체 저장소 데이터 유지)

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

중요: 설치 후 추가 저장소 이관 작업을 최소화하려면 사전 계획을 통해. 첫 배포 이후의 변경 사항은 helm upgrade를 실행하기 전에 기존 쿠버네티스 객체를 수동으로 편집해야 합니다.

일반 설치 동작

설치 프로그램은 기본 저장소 클래스 및 동적 볼륨 프로비저닝을 사용하여 저장소를 생성합니다. 응용 프로그램은 Persistent Volume Claim을 통해 이 저장소에 연결됩니다. 관리자는 가능한 경우 동적 볼륨 프로비저닝 대신 정적 볼륨 프로비저닝을 사용할 것을 권장받습니다.

운영 환경에서 관리자는 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과 다른 점이 있으므로 변경하기 전에 각각의 구체적인 문서를 확인하는 것이 중요합니다.

정적 볼륨 프로비저닝 사용

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

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’s own documentation on storage classes을 확인하세요.

  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 팟 이름은 다음과 같이 생성됩니다. 

<statefulset-name>-<pod-index>

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

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

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

참고: 여러 가상 스토리지를 사용하여 Praefect를 사용하는 경우, 정의된 각 가상 스토리지 당 Gitaly 레플리카 당 하나의 PersistentVolumeClaim이 필요합니다. 예를 들어, default 및 vs2 Virtual Storage가 각각 2개의 레플리카로 정의된 경우, 다음과 같은 PersistentVolumeClaim이 필요합니다.

  • 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을 구성에 제공할 수 있습니다. 이 차트는 여전히 volume claim을 생성하고 수동으로 생성된 볼륨에 바인딩을 시도합니다. 각 포함된 애플리케이션에 대한 차트 설명서를 확인하세요.

대부분의 경우, 예제 YAML 구성을 수정하여 수동으로 생성된 디스크 볼륨을 사용할 서비스만 유지하세요.

설치 후 스토리지 변경

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

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

선택적 볼륨

대규모 설치의 경우, 백업/복원을 작동하도록 Toolbox에 지속적인 스토리지를 추가해야 할 수 있습니다. 문제 해결 문서에서 이에 대한 가이드를 확인하세요.