현재 VM에서 Jenkins 작업을 실행하고 있는데, 첫 빌드는 오래 걸리지만 바이너리가 저장되어 있어서 그 이후 빌드는 5-10분밖에 안 걸려요. 이제 Kubernetes 파드로 전환해야 하는데, 파드는 작업마다 새로 생성되고 삭제되니까 매번 전체 빌드를 다시 해야 해서(약 2시간 소요) 어떻게 해결하는 게 좋을지 고민하고 있어요.
퍼시스턴트 볼륨을 파드에 마운트할 수 있다는 건 알지만, 이런 볼륨은 보통 읽기 전용(Git 캐시 같은)으로 쓰는 게 좋다고 알고 있어요. 여러 파드가 동시에 같은 볼륨에서 빌드하는 상황을 피하기 위해서죠.
저는 일반적으로 CI 파이프라인 초기에 빌드를 수행하고, 컴파일된 바이너리를 포함하는 컨테이너 이미지를 발행합니다. 그러면 파드들은 해당 이미지를 가져와 몇 초 만에 실행할 수 있습니다. 만약 Kubernetes 내에서 인크리멘털 빌드가 여전히 필요하다면, EFS와 같은 네트워크 기반 캐시를 읽기 전용으로 마운트하여 의존성 캐시를 사용할 수 있습니다.
VM처럼 “항상 떠 있는 빌드 머신”을 Kubernetes에서 그대로 만드는 방식은 일반적인 접근은 아니고, 빌드 작업 자체를 일시적(Pod 단위)으로 수행하도록 설계하는 패턴이 더 널리 쓰입니다.
즉, VM 1대를 계속 켜놓고 빌드를 돌리는 방식이 아니라, 빌드가 필요할 때마다 Kubernetes가 새로운 Pod를 띄우는 구조입니다.
대표적인 방법은 다음과 같은 흐름으로 구성됩니다.
첫째, CI 도구(예: Jenkins, GitHub Actions, GitLab CI 등)에 Kubernetes Agent를 붙이는 방식이 가장 흔합니다.
Jenkins Kubernetes Plugin, GitLab Kubernetes Runner처럼 CI가 빌드 실행 시점에 새로운 Pod를 만들고, 작업이 끝나면 삭제하도록 구성하는 방식입니다. 이렇게 하면 VM처럼 장시간 유지할 필요가 없고, Kubernetes가 자동으로 스케일링을 처리해주는 장점이 있습니다.
둘째, Tekton이나 Argo Workflows처럼 아예 Kubernetes-native CI/CD 도구를 사용하는 방식도 많이 언급됩니다.
이 경우 빌드·테스트·배포 과정이 모두 Kubernetes 리소스로 표현되기 때문에, 파이프라인이 그대로 YAML로 관리되고 Pod 기반 실행이 자연스럽게 정착되는 구조입니다. VM 기반 CI보다 관리 포인트가 줄어들어 개발팀이 선호하는 경우도 많다고 합니다.
셋째, 빌드 성능을 위해 필요한 경우에는 캐시 디렉토리나 Docker Layer Cache를 PVC로 유지하는 식으로 “Pod는 일시적이지만, 필요한 데이터만 지속성 있게 저장하는 구조”를 만들어 사용하기도 합니다. 이를 통해 VM 기반 빌드에서 제공되던 캐싱 효과를 어느 정도 대체할 수 있습니다.
마지막으로, Kubernetes에서 지속적인 빌드 환경을 유지하는 핵심은 “빌드 서버를 상시 운영하는 것”이 아니라, 빌드 작업을 이벤트 기반으로 자동 생성하고 필요 없으면 제거하는 구조로 운영하는 것이라는 점이 반복적으로 강조됩니다. 이렇게 해야만 VM보다 비용·유지보수·보안 측면에서 장점이 생긴다는 의견이 많았습니다.