GitLab 차트의 스토리지 구성

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

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

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

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

중요: 설치 후 추가적인 스토리지 이전 작업을 최소화하기 위해 사전 계획이 필요합니다. 첫 번째 배포 이후에 변경 사항은 helm upgrade를 실행하기 전에 기존 쿠버네티스 오브젝트를 매뉴얼으로 수정해야합니다.

일반적인 설치 동작

설치 프로그램은 기본 스토리지 클래스와 동적 볼륨 프로비저닝을 사용하여 스토리지를 생성합니다. 애플리케이션 이 스토리지에 영구 볼륨 클레임을 통해 연결됩니다. 관리자는 사용 가능한 경우 동적 볼륨 프로비저닝 대신 정적 볼륨 프로비저닝을 권장합니다.

관리자는 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. 클러스터에 영구 디스크를 생성합니다.](https://kubernetes.io/docs/concepts/storage/volumes/#creating-a-pd) 
gcloud compute disks create --size=50GB --zone=*GKE_ZONE* *DISK_VOLUME_NAME*
  1. 예제 YAML 구성을 수정한 후 영구 볼륨을 생성합니다. 
kubectl create -f *PV_YAML_FILE*

Amazon EKS 사용

note
여러 존에 배포해야하는 경우, 스토리지 솔루션을 정의할 때 Amazon의 스토리지 클래스 설명서를 검토해야합니다.
  1. 클러스터에 영구 디스크를 생성합니다.](https://kubernetes.io/docs/concepts/storage/volumes/#creating-an-ebs-volume) 
aws ec2 create-volume --availability-zone=*AWS_ZONE* --size=10 --volume-type=gp2
  1. 예제 YAML 구성을 수정한 후 영구 볼륨을 생성합니다. 
kubectl create -f *PV_YAML_FILE*

매뉴얼으로 PersistentVolumeClaim 생성

Gitaly 서비스는 StatefulSet을 사용하여 배포됩니다. 올바르게 인식되고 사용하려면 영구 볼륨 클레임을 다음 명명 규칙을 사용하여 생성해야합니다. 

<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 영구 볼륨 클레임의 올바른 이름은: repo-data-gitlab-gitaly-0 입니다.

참고: 여러 가상 스토리지를 사용하는 경우 Praefect와 함께 사용하려면 정의된 가상 스토리지당 Gitaly 레플리카 당 하나의 PersistentVolumeClaim가 필요합니다. 예를 들어 default 및 vs2 가상 스토리지가 각각 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 구성을 수정하여 매뉴얼으로 생성된 디스크 볼륨을 사용할 서비스만 유지하세요.

설치 후 스토리지 변경

초기 설치 후에는 쿠버네티스 개체를 헬름 업그레이드 명령어 외부에서 편집하여 새 볼륨으로 이주하거나 디스크 크기를 변경하는 스토리지 변경이 필요합니다.

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

선택적 볼륨

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