연간 600시간을 절감한 Kubernetes 한 줄 수정

Terraform 변경을 계획·적용하는 Atlantis를 재시작할 때마다 30분씩 멈추는 문제가 있었다. 월 약 100회 재시작이 필요해, credential rotation과 onboarding 때마다 전체 엔지니어링 작업이 막히고 on-call 경보까지 발생했다.

원인은 Kubernetes의 기본 동작이었다. Atlantis는 singleton StatefulSet으로 동작하며 PersistentVolume(PV) 에 저장된 repository state를 사용했는데, PV에 들어 있는 파일 수가 수백만 개까지 늘어나자 재시작 시 마운트 과정이 비정상적으로 길어졌다. inode가 고갈돼 PV를 확장해야 했고, 이 과정에서 문제의 본질이 드러났다.

kubectl rollout restart statefulset atlantis를 실행하면 새 Pod는 바로 생성되지만, 실제로는 Init:0/1 상태에서 오랫동안 멈춰 있었다. Pod 이벤트만으로는 원인을 찾기 어려웠고, 더 깊게 들어가 kubelet 로그를 확인하면서 PV 마운트 이후에 긴 공백이 생기는 것을 발견했다.

핵심 단서는 다음 로그였다.

• Setting volume ownership ... and fsGroup set
• 파일이 많으면 ownership 설정이 느릴 수 있다는 경고

즉, Kubernetes가 PV를 마운트할 때 fsGroup 때문에 전체 파일 시스템에 대해 재귀적으로 그룹 소유권을 바꾸고 있었던 것이다. 파일과 디렉터리가 너무 많아 chgrp -R에 가까운 작업이 매번 발생했고, 그 결과 재시작 시간이 30분까지 늘어났다.

해결은 단순했다. Pod securityContext에 Kubernetes 1.20부터 지원되는 fsGroupChangePolicy 를 추가하고, 기본값인 Always 대신 OnRootMismatch 로 바꿨다. 루트 디렉터리의 권한이 이미 맞으면 전체 PV를 다시 훑지 않기 때문에, 불필요한 재귀 권한 변경을 피할 수 있다.

• 적용 전: 재시작 약 30분
• 적용 후: 재시작 약 30초
• 절감 효과: 월 50시간 이상, 연간 약 600시간

기본값은 작은 볼륨에는 합리적이지만, 데이터가 커지면 조용히 병목이 된다. 대용량 PV를 쓰는 워크로드라면 fsGroup과 fsGroupChangePolicy를 점검하고, OnRootMismatch가 안전한지 확인할 필요가 있다. 이번 사례는 복잡한 설정보다도, 시스템이 왜 그렇게 동작하는지 묻는 질문 하나가 큰 시간을 절약할 수 있다는 점을 보여준다.