Gitaly on Kubernetes

Kubernetes에서 Gitaly를 실행하는 방법, 가용성 트레이드오프 및 모범 사례를 설명합니다.

히스토리 GitLab 17.3에서 실험 기능으로 도입. GitLab 17.10에서 실험에서 베타로 변경. GitLab 18.2에서 베타에서 제한 공개로 변경. GitLab 18.11에서 제한 공개에서 일반 공개로 변경. Kubernetes에서 Gitaly를 실행하면 가용성 측면에서 절충이 생기므로, 운영 환경을 계획할 때 이러한 절충을 고려하고 기대 수준을 그에 맞게 설정합니다. 이 문서는 현재 제약을 최소화하고 대비하는 방법을 설명하고 안내합니다. Gitaly on Kubernetes는 Gitaly 팀이 평가했으며 Gitaly를 배포하는 안전한 방식으로 판단했습니다. 이 문서의 나머지 부분에서는 그 모범 사례를 설명합니다. 타임라인 # Gitaly on Kubernetes는 GitLab 18.11부터 일반 공개되었습니다. GitLab은 클라우드 공급자의 특정 관리형 Kubernetes 서비스(Amazon EKS, Google GKE, Azure AKS 등)와의 호환성은 보장하지 않습니다. 운영 환경에 배포하기 전에 사용 중인 환경에서 직접 검증해야 합니다. 배경 # 설계상 Gitaly(비클러스터)는 단일 장애 지점(SPoF) 서비스입니다. 데이터는 단일 인스턴스에서 공급되고 제공됩니다. Kubernetes에서는 StatefulSet Pod가 교체될 때(예를 들어 업그레이드, 노드 유지 관리, 퇴출 과정에서) 해당 Pod나 인스턴스가 제공하던 데이터에 서비스 중단이 발생합니다. Cloud Native Hybrid 구성(Gitaly VM)에서는 Linux 패키지(Omnibus)가 다음 방식으로 이 문제를 가립니다. Gitaly 바이너리를 제자리에서 업그레이드합니다. 그레이스풀 리로드를 수행합니다. 컨테이너나 Pod가 완전히 종료되고 새 컨테이너나 Pod로 시작해야 하는 컨테이너 기반 수명 주기에는 같은 방식이 맞지 않습니다. 클라우드 네이티브 배포에서는 Gitaly(비클러스터)가 유일한 일반 공개 옵션입니다. Kubernetes의 Gitaly Cluster(Praefect) 는 베타입니다. 적절한 Kubernetes 및 Gitaly 기능과 구성을 활용하면 서비스 중단을 최소화하고 좋은 사용자 경험을 제공할 수 있습니다. 요구 사항 # 이 페이지의 내용은 다음을 전제로 합니다. Kubernetes 버전 1.29 이상. Kubernetes 노드 runc 버전 1.1.9 이상. Kubernetes 노드 cgroup v2. 네이티브 및 하이브리드 v1 모드는 지원하지 않습니다. systemd 방식 cgroup 구조 만 지원합니다(Kubernetes 기본값). 노드 마운트 지점 /sys/fs/cgroup 에 대한 Pod 접근 권한. containerd 2.1.0 이상 버전. /sys/fs/cgroup 의 root 사용자 파일 시스템 권한에 대한 Pod init 컨테이너( init-cgroups ) 접근 권한. Pod cgroup을 Gitaly 컨테이너 (사용자 git , UID 1000 )에 위임하는 데 사용합니다. cgroups 파일 시스템이 n