gitaly

1 개의 포스트

gitlab

Kubernetes에서 Gitaly로 GitLab 스택 통합하기 (새 탭에서 열림)

GitLab 18.11부터 Gitaly on Kubernetes가 정식 지원되면서, GitLab의 모든 구성 요소를 Kubernetes에서 운영할 수 있게 되었습니다. 기존의 Kubernetes와 VM을 함께 사용하는 하이브리드 구조를 없애고, 인프라 운영과 모니터링을 단일 Kubernetes 환경으로 통합할 수 있습니다. 다만 현재 Gitaly Cluster(Praefect)는 Kubernetes를 아직 지원하지 않아 완전한 고가용성은 제공되지 않습니다. ### Kubernetes 환경에 맞춘 Gitaly의 변화 - Git 작업은 메모리 사용량이 크고 패턴을 예측하기 어렵습니다. - Gitaly는 Git 프로세스를 별도 cgroup에서 실행해 메모리 초과로 프로세스가 종료되더라도 주 Gitaly 프로세스가 영향을 받지 않도록 합니다. - Kubernetes에서 이 구조를 구현하기 위해 다음 작업이 필요했습니다. - `containerd` 환경에서 cgroupfs에 쓰기 권한을 부여 - init container로 `/sys/fs/cgroup`를 마운트 - 해당 경로를 쓰기 가능하도록 설정 - 이를 통해 Git 프로세스의 OOM(메모리 부족) 종료가 Gitaly 전체 장애로 이어지는 것을 방지합니다. ### Pod 재시작과 서비스 중단 문제 - VM에서는 Omnibus가 Gitaly 바이너리를 교체하고 소켓을 유지한 채 graceful reload를 수행할 수 있습니다. - Kubernetes에서는 Helm 업그레이드, 노드 드레이닝, 설정 변경 등으로 StatefulSet Pod가 교체되면 프로세스가 강제 종료된 뒤 재시작됩니다. - Gitaly Sharded처럼 자체 고가용성을 제공하지 않는 구성에서는 이 방식이 일시적인 중단을 일으킬 수 있습니다. - 이를 보완하기 위해 Rails 등 Gitaly 클라이언트의 요청 재시도 시간을 설정할 수 있게 했습니다. - Gitaly가 재시작되는 동안 요청을 재시도 - 사용자는 짧은 시간 동안 약간 높은 지연을 경험할 수 있음 - 재시작이 완료되면 요청은 최종적으로 성공 ### 업그레이드 중에도 높은 성공률 유지 - VM 기반 Gitaly와 Kubernetes 기반 Gitaly에서 일반적인 Git 작업을 실행한 뒤, 테스트 중간에 업그레이드를 수행하는 벤치마크를 진행했습니다. - 두 환경의 요청 성공률은 거의 동일했습니다. - Kubernetes에서는 Pod 종료 시 프로세스가 즉시 끝나고 소켓도 닫히지만, 클라이언트 재시도 덕분에 대부분의 요청이 성공했습니다. - 모든 작업에서 100% 성공률을 보장하려면 Gitaly Cluster(Praefect)가 필요합니다. - 그러나 Praefect는 현재 Kubernetes를 지원하지 않으며, Kubernetes 지원의 정식 제공을 준비 중입니다. ### 인프라 통합의 효과 - 기존 하이브리드 배포 사용자는 Gitaly를 VM에서 Kubernetes 클러스터로 이전할 수 있습니다. - 별도의 Gitaly VM fleet를 유지·모니터링할 필요가 없어집니다. - GitLab 전체를 Kubernetes가 관리하는 단일 환경으로 통합할 수 있습니다. - Kubernetes를 이미 운영 중인 신규 GitLab 사용자도 Helm chart를 통해 Kubernetes 네이티브 방식으로 GitLab을 배포할 수 있습니다. ### 설치 방법과 배포 형태 - 권장 설치 방법은 GitLab Helm chart를 사용하는 것입니다. - 설치 전 Gitaly on Kubernetes 공식 문서를 확인해 주요 설정과 일반적인 문제를 검토해야 합니다. - Gitaly는 두 가지 형태로 배포할 수 있습니다. - 전체 GitLab 설치의 일부로 배포 - 외부 Gitaly 구성 요소로 별도 배포 - 구체적인 설정 방법과 주의사항은 Gitaly on Kubernetes 문서에서 각 시나리오별로 제공합니다. ### 실용적인 결론 GitLab을 Kubernetes 중심으로 운영하는 팀이라면 Gitaly를 클러스터로 통합하는 것이 운영 복잡성을 줄이는 현실적인 선택입니다. 다만 무중단 고가용성이 반드시 필요한 환경은 Praefect의 Kubernetes 지원 여부를 확인한 뒤 도입을 결정하는 것이 좋습니다.