Kubernetes EKS 1.33에서 Kaniko에서 BuildKit으로 Docker 빌드 전환 방법과 성

컨테이너 이미지를 안전하게 빌드하여 배포하는 과정은 현대 소프트웨어 개발에서 꼭 필요한 파이프라인 중 하나입니다. 특히 쿠버네티스 환경(EKS 1.33)에서 CI/CD 파이프라인을 유지 관리하려면 신뢰할 수 있는 빌드 솔루션이 필수죠. 기존까지 인기 있었던 Kaniko는 최근 EKS 업그레이드 이후 여러 가지 문제로 고민을 준 반면, Docker 팀이 직접 개발한 BuildKit은 성능과 안정성 면에서 새로운 해법을 제시합니다. 이 글에서는 Kaniko에서 BuildKit으로 전환했던 실제 경험을 바탕으로, 실패 원인과 성공적인 마이그레이션, 그리고 실전에서 얻은 교훈과 팁을 소개합니다.

Kaniko의 불안정함: EKS 1.33에서 겪은 문제들

Kaniko는 한동안 쿠버네티스 클러스터에서 비권한(Docker 데몬 없이도) 빌드가 가능하다는 점에서 각광받았습니다. 하지만 EKS 1.33으로 업그레이드한 뒤, GitLab CI에서 다음과 같은 문제에 직면했습니다.

Kaniko 파드가 예고 없이 크래시나며 로그 정보도 거의 남기지 않음
빌드 캐시가 정상적으로 설정되어도 일관성 없이 무시되거나 동작하지 않음
ECR 인증 오류(401)가 간헐적으로 발생, IRSA 설정이 정상이어도 동일 증상 반복

이러한 예측 불가한 실패들은 프로덕션 환경에서는 도저히 용납될 수 없는 리스크입니다.

BuildKit이 Kaniko보다 우수한 이유

BuildKit은 도커팀이 만든 최신 빌드 엔진으로, 쿠버네티스 환경에서 컨테이너 이미지를 안전하게 효율적으로 만들기 위한 기능을 대거 갖추고 있습니다.

똑똑한 캐싱: 이미지 레이어 캐시를 손쉽게 레지스트리에 업로드 및 다운로드 가능
정교한 인증 처리: IRSA, ECR 연동이 별도 트릭 없이 안정적으로 작동
속도: 병렬 빌드와 효율적 리소스 사용으로 평균 40% 빌드 시간 단축(실전 비교)
에러 진단: Kaniko에 비해 훨씬 명확한 빌드 실패 로그 제공

최근 GitLab CI, 쿠버네티스 환경에서 BuildKit은 단순 편리함을 넘어, 실질적 운영 안정성을 책임지는 대안이 되고 있습니다.

BuildKit으로 마이그레이션: 준비 단계

BuildKit으로 옮기기 전 갖춰야 할 사항은 다음과 같습니다.

쿠버네티스 상에서 돌아가는 GitLab Runner와 Kubernetes Executor 설정
ServiceAccount에 충분한 IAM(특히 IRSA) 권한 부여, ECR 접근 보장
BuildKit과 Kaniko 모두 기본적으로 'privileged' 파드 권한 필요하지만, BuildKit은 rootless(비권한) 모드도 지원해 보안 고민을 줄여줍니다.

이 환경이 구비되어 있다면, BuildKit 공식 문서나 커뮤니티 가이드를 참고해 빠르게 구현에 착수할 수 있습니다.

실제 마이그레이션: 설정과 코드 예시

BuildKit 파드 배포 Helm Chart 대신 직접 YAML로 커스텀 리소스를 만드는 방법을 추천합니다. 배포 후 CI 설정에서 BUILDKIT_ADDR를 다음처럼 지정해 줍니다. tcp://buildkitd.buildkit.svc.cluster.local:1234
ECR 인증 정보 셋업 GitLab CI의 before_script 단계에서 IRSA 역할을 통한 AWS 인증 정보를 반드시 정확하게 남겨야 합니다.
buildctl 명령어 활용과 캐싱 BuildKit의 buildctl 명령어를 활용해, ECR에 이미지 푸시뿐만 아니라 캐시 레이어도 잘 관리할 수 있습니다. 빌드 reproducibility, 캐시 효율성, 그리고 자동 푸시까지 한번에 해결됩니다.

BuildKit 도입 효과: 성능과 안정성 실전 비교

실제 운영 환경에서 Kaniko에서 BuildKit으로 전환한 뒤, 체감했던 장점은 명확했습니다.

빌드 시간이 평균 40% 단축되어 개발자 대기 시간 감소
파드 크래시나 빌드 실패 현상이 완전히 사라짐(100% 성공률)
Cache Repository(ECR)를 통한 빌드 재활용이 항상 바르게 동작
IRSA/이중 인증 문제가 완전히 해결

이러한 변화 덕분에 개발, 운영 모두 쾌적함을 느끼며 업무 효율성이 크게 올랐습니다.

Kaniko 프로젝트의 현황과 향후 고려사항

Kaniko는 한때 인기 많았지만, 현재 GitHub 리포는 사실상 유지보수 중단 상태입니다. PR과 주요 이슈가 수 개월째 방치되고 있고, 최신 쿠버네티스(EKS 1.33 등)와의 호환성도 갈수록 떨어지고 있습니다. 특히, 문제 발생시 파악과 대응 속도가 크게 느려지는 만큼, 신규 혹은 장기 프로젝트에서는 BuildKit을 필수적으로 도입하는 것을 권장합니다.

마무리: 쿠버네티스 이미지 빌드의 미래, BuildKit으로 전환하자

Kaniko의 시대가 저물면서, BuildKit은 쿠버네티스와 CI/CD의 최신 트렌드에서 빠질 수 없는 툴로 급부상하고 있습니다. 만약 현재 Kaniko를 쓰면서 불안정 현상을 경험했다면, BuildKit 마이그레이션을 적극적으로 검토할 때입니다. 작은 설정 변경만으로 캐싱, 인증, 속도까지 모두 개선되는 놀라운 경험을 하실 수 있습니다.

실전 조언: 환경에 따라 rootless 모드도 지원하니, 보안성까지 마음 놓고 업그레이드해보세요. 최신 빌드 솔루션을 쓰는 것, 그 자체가 클라우드 전환과 개발 혁신의 첫 걸음입니다!

출처 및 참고 : Migrating from Kaniko to BuildKit for Docker Builds on Kubernetes (EKS 1.33) | by Herve Khg | Medium