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부터 일반 가용성(GA)입니다. GitLab은 클라우드 공급자의 특정 관리형 Kubernetes 오퍼링(예: Amazon EKS, Google GKE, Azure AKS)과의 호환성을 보장하지 않습니다. 프로덕션 환경에 배포하기 전에 특정 환경을 검증해야 합니다. 배경 # 설계상 Gitaly(비 클러스터)는 단일 장애 지점(SPoF) 서비스입니다. 데이터는 단일 인스턴스에서 소싱되고 제공됩니다. Kubernetes의 경우 StatefulSet 파드가 교체되면(예: 업그레이드, 노드 유지 관리 또는 퇴출 중) 파드 또는 인스턴스가 제공하는 데이터에 대한 서비스 중단이 발생합니다. Cloud Native Hybrid 설정(Gitaly VM)에서 Linux 패키지(Omnibus)는 다음을 통해 문제를 마스킹합니다: 인플레이스 Gitaly 바이너리 업그레이드. 그레이스풀 리로드 수행. 컨테이너 또는 파드가 완전히 종료되고 새 컨테이너 또는 파드로 시작해야 하는 컨테이너 기반 라이프사이클에는 동일한 접근 방식이 적합하지 않습니다. Gitaly Cluster(Praefect)는 인스턴스 간 데이터를 복제하여 데이터 및 서비스 고가용성 측면을 해결합니다. 그러나 Gitaly Cluster(Praefect)는 컨테이너 기반 플랫폼에 의해 증폭되는 기존 문제 및 설계 제약 때문에 Kubernetes에서 실행하기에 적합하지 않습니다. Cloud Native 배포를 지원하기 위해 Gitaly(비 클러스터)만 옵션입니다. 올바른 Kubernetes 및 Gitaly 기능과 구성을 활용하여 서비스 중단을 최소화하고 좋은 사용자 경험을 제공할 수 있습니다. 요구 사항 # 이 페이지의 정보는 다음을 가정합니다: Kubernetes 버전 1.29 이상. Kubernetes 노드 runc 버전 1.1.9 이상. Kubernetes 노드 cgroup v2. 네이티브, 하이브리드 v1 모드는 지원되지 않습니다. systemd 스타일 cgroup 구조 만 지원됩니다(Kubernetes 기본값). 노드 마운트 포인트 /sys/fs/cgroup 에 대한 파드 액세스. containerd 버전 2