Gitaly on Kubernetes

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

히스토리 GitLab 17.3에서 실험적 기능 으로 도입되었습니다. GitLab 17.10에서 실험적 기능에서 베타로 변경되었습니다. GitLab 18.2에서 베타에서 제한적 가용성으로 변경되었습니다. Disclaimer 이 페이지에는 개발 중인 제품, 기능에 대한 정보가 포함되어 있습니다. 이 정보는 참고 목적으로만 제공되며, 구매 또는 계획 시 이 정보에 의존하지 마십시오. Kubernetes에서 Gitaly를 실행하면 가용성 트레이드오프가 있으므로 프로덕션 환경을 계획할 때 이러한 트레이드오프를 고려하고 그에 맞게 기대치를 설정하세요. 이 문서는 기존 제한 사항을 최소화하고 계획하는 방법에 대한 지침을 설명합니다. 타임라인 # Gitaly on Kubernetes는 Gitaly 팀에 의해 평가되어 Gitaly를 배포하는 안전한 방법으로 결정되었습니다. 이 문서의 나머지 부분에서는 이를 위한 모범 사례를 자세히 설명합니다. 내부적으로, 기능을 GA(Generally Available) 로 이동하기 전에 프로덕션 수준의 워크로드를 처리할 수 있는지 확인하기 위해 Gitaly on Kubernetes를 도그푸딩하는 중입니다. FY26Q4에 도그푸딩을 완료하고 FY27Q1에 Gitaly on Kubernetes를 GA로 이동할 예정입니다. 배경 # 설계상 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 기본값). 노드