컨테이너 빌드 도구 선택을 위한 특성 및 성능 비교 (Kaniko, Buildah, Buildkit)

 

하이퍼바이저를 이용한 VM(Virtual Machine) 대신 호스트 OS를 cgorup과 namespace 기반으로 리소스와 파일시스템을 격리한 컨테이너 기술을 사용해 자원을 사용하는 시대가 왔습니다.

 

컨테이너 기술이 등장하면서 상태 저장을 위해 VHD 등을 사용하던 VM과 달리 컨테이너 이미지라는 새로운 이미지 유형을 이용해 OS 상태를 정의할 수 있게 되었는데요.

 

시간이 지나 컨테이너 기술을 표준화하는 OCI(Open Container Initiative)가 등장하고, 컨테이너들을 조율해주는 오케스트레이션 툴인 Kubernetes에 Dockershim 컨테이너 런타임이 제외되면서 다양한 컨테이너 빌드 도구가 등장하게 되었습니다.

 

이번 포스팅에서는 이렇게 등장한 컨테이너 빌드 도구들이 각각 어떤 특성을 가지고 있는지, 어떠한 성능 지표를 나타내는지 알아보면서 빌드 도구들을 비교해보도록 하겠습니다.

 

---

 

1. 개요

 

본 포스팅은 Kubernetes 환경에서 사용할 컨테이너 이미지 빌드 도구의 선택을 돕기 위해 성능 및 특성을 비교 분석한 글입니다.

 

이 글을 통해 각 빌드 도구의 정성적 특성과 정량적 특성을 파악할 수 있습니다.

 

글에 포함된 수치 및 특성은 테스트 환경에 따라, 도구의 버전에 따라 달라질 수 있습니다.

 

---

2. Build Tools

 

2023년 현재 기준, 운영환경에서 선택할 수 있을 만큼 성숙한 이미지 빌드 도구들의 리스트는 다음과 같습니다.

 

1. Docker
   
   
2. Buildpack
   
   
3. Kaniko
   
   
4. Buildah
   
   
5. Buildkit

 

위 도구들 중, 본 포스팅에서는 Docker와 Buildpack을 제외한 Kaniko, Buildah, Buildkit 3개 도구만을 비교했습니다.

 

Docker를 비교 대상에서 제외한 이유는 다음과 같습니다.

 

1. Docker Daemon 사용
   
   Docker는 이미지 빌드 등의 동작을 위해 Docker daemon을 필요로 합니다.
   이러한 특징은 노드가 분산되어 있는 Kubernetes 환경에서 많은 자원을 요구하기 때문에 비효율적입니다.
   이에 더해 Docker Daemon은 Host에 대해 Root Privilege를 요구하므로 보안 취약점을 발생시킨다는 단점도 존재합니다.
   따라서 Kubernetes 환경에서 Docker를 빌드 도구로 사용하는 것은 비효울적이고 보안에 취약하다는 단점이 있어 비교 대상에서 제외했습니다.
   
   
2. Docker in Docker 구조의 비효울성
   
   Docker Daemon이 각 노드마다 실행되어야 한다는 단점을 극복하기 위해 Docker Container 내부에 Docker를 실행해 이미지를 빌드하는 DinD(Docker in Docker) 구조를 사용할 수 있습니다.
   하지만 이 구조는 여전히 Docker Conatiner 내부에서 Docker Daemon이 실행되어야 한다는 점 때문에 자원 소모량이 많고, Root 권한을 필요로 해 보안 취약점이 발생합니다.
   게다가 Storage Driver 문제, 캐시 공유 불가능 등의 문제를 가지고 있기 때문에 Docker를 이미지 빌드 도구 비교 대상에서 제외했습니다.
   
   
   

 

Buildpack을 비교 대상에서 제외한 이유는 다음과 같습니다.

 

1. 타 도구와 다른 빌드 방식
   
   Buildpack은 Dockerfile 없이 Source Code의 Configuration(EX: application.configuration, requirements.txt ..) 만으로 이미지를 빌드할 수 있다는 특징이 있습니다.
   이는 다른 빌드 도구와 차별화되는 좋은 특징이지만, 본 포스팅에서는 빌드 도구 간 공정한 비교를 위해 최소한 Dockerfile을 기반으로 이미지를 빌드하는 도구만 비교 대상으로 선정했습니다.

---

 

3. Build Tool Comparison

 

Docker와 Buildpack을 제외한 Kaniko, Builah, Buildkit 3개 이미지 빌드 도구 간의 비교를 통해 각 도구들이 어떤 특성을 가지고 있는지, 어떠한 퍼포먼스를 낼 수 있는지 확인합니다.

 

3-1.Feature

 

공통점 

 

Kaniko, Buildah, Buildkit 이미지 빌드 도구들은 다음과 같은 공통점을 가지고 있습니다.

 

1. OCI Compliant
   세 도구 모두 OCI(Open Container Initiative) 규격을 따르는 컨테이너 이미지를 빌드할 수 있습니다. 
   
   
2. Daemonless
   세 도구들 모두 Docker Daemon이나 유사한 Daemon을 필요로 하지 않아 이에 따른 자원의 소모량, 보안 문제를 해결할 수 있습니다.
   
   
3. Multi-stage Build
   세 도구들은 모두 이전 스테이지에서 빌드한 결과물을 다음 스테이지에서 사용할 수 있게 해주는 Multi-stage build 기능을 이용할 수 있습니다.
   이를 통해 Dockerfile을 간결하게 유지할 수 있으며 빌드의 효율성을 높일 수 있습니다.

 

 

차이점

 

Kaniko, Buildah, Buildkit 이미지 빌드 도구들은 다음과 같은 분야에서 차이점을 보입니다.

 

1. Security
   
   
   • Kaniko :
     
     Kaniko는 이미지 빌드를 위해 컨테이너 내에서 Root 권한을 필요로 하지만, Privileged 컨테이너를 요구하지는 않습니다.
     Root는 컨테이너 내부에서만 루트 권한을 부여하지만 Privileged는 컨테이너 내부에서 부여된 권한을 Host에도 부여한다는 차이점이 있습니다.
     따라서 Kaniko는 컨테이너 내부에서는 Root 권한을 가질 수 있지만 이 권한이 Host에까지 미치지는 못합니다.
     
     Reference : https://itnext.io/docker-and-kubernetes-root-vs-privileged-9d2a37453dec
     
     
   • Buildkit :
     
     Buildkit은 Kaniko와 달리 Rootless 버전을 제공해 Root 권한 없이 이미지를 빌드할 수 있습니다. 
     하지만 seccomp와 AppArmor를 Disable해야 하기 때문에 Linux Kernal 단에서 보안 취약점을 노출하게 된다는 단점이 존재합니다.
     GCP의 GKE의 COS(Container Optimized OS)를 사용할 시 Rootless 모드에서 volume을 마운트할 수 없다는 이슈가 존재해 COS 환경에서는 Root 모드로 실행해야 한다는 제한이 있습니다.
     
     Reference : https://github.com/moby/buildkit/issues/879
     
     
   • Buildah :
     
     Buildah 또한 Buildkit과 마찬가지로 Rootless 버전을 지원해 Root 권한 없이 이미지를 빌드할 수 있습니다.
     하지만 Rootless 버전이 GKE COS에서 정상 동작하지 않는 것으로 확인됩니다.
     
     
     
2. Caching
   
   
   • Kaniko :
     
     Kaniko가 다른 빌드 도구와 차별화되는 점은 Snapshot 기능의 존재입니다. Snapshot은 이미지의 Filesystem을 tarball로 압축해 Layer에 보관하는 Kaniko의 캐싱 방법입니다.
     Kaniko는 Base Image의 Filesystem을 포함해 각 Dockerfile의 각 Layer를 Snapshot해 캐싱합니다. 
     이후 해시 값 비교를 통해 캐시된 Layer와 같은 Layer가 존재한다면, Kaniko는 해당 Layer를 새로 빌드하는 대신 캐시를 사용합니다.
     추가적으로 Kaniko는 캐시를 외부 레포지토리에 저장하고 가져올 수 있는 Remote 캐싱을 지원하기 때문에 CI/CD Pipeline 환경에서 사용하기 유리하다는 장점이 존재합니다.
     
     
   • Buildkit :
     
     Buildkit도 Kaniko와 마찬가지로 Layer 단위로 캐싱을 수행해 이미지 빌드 시 각 Layer의 해시 값 비교를 통해 캐시 적중 여부를 판단합니다.
     그리고 Buildkit 또한 외부 레포지토리에 캐시를 저장하고 가져오는 Remote 캐싱을 지원해 CI/CD Pipeline 환경에서 사용하기 유리합니다.
     추가적으로 Buildkit은 이미지 자체에 캐시를 저장하는 Inline 캐싱 방식을 지원해 레포지토리를 간결하게 유지할 수 있다는 장점이 존재합니다.
     
     
   • Buildah :
     
     Buildah가 Dockerfile을 기반으로 이미지를 빌드하는 buildah bud 명령어는 현재 Remote 캐싱 기능을 제공하지 않습니다.
     현재 Remote 캐싱은 스크립트 언어 기반으로 레이어를 추가하는 buildah add 명령어로만 Remote 캐싱이 가능합니다.
     따라서 Local Cache를 사용할 수 없는 CI/CD Pipeline 환경에서는 Docker 파일을 이용한 빌드 시 캐싱 기능을 사용할 수 없다는 단점이 존재합니다.
     
     
3. Compatibility
   
   
   • Kaniko : 
     
     현재 Kaniko가 지원하는 OS는 Linux가 유일합니다. 
     Kaniko는 Multi-architecture를 지원해 arm64 및 amd64 기반 이미지를 빌드할 수 있습니다.
     
     
   • Buildkit :
     
     현재 Buildkit은 Linux, MacOS, Windows OS를 모두 지원합니다.
     따라서 개발자의 로컬 빌드 테스트에 유리하다는 장점이 존재합니다.
     Buildkit 또한 Multi-architecture를 지원해 arm64, amd64 기반 이미지를 빌드할 수 있습니다.
     
     
   • Buildah :
     
     Buildah는 현재 Linux OS만 지원하고 있습니다.
     Buildah도 Multi-architecture를 지원해 arm64, amd64 기반 이미지를 빌드할 수 있습니다.
     
     
4. Usability
   
   
   • Kaniko :
     
     1. GKE Workload Identity 지원 : Kaniko는 native하게 GKE Workload Identity 기능을 지원하고 있습니다. 따라서 GKE 환경에서 이미지를 빌드할 시 Service account Key 없이도 권한을 부여할 수 있어 보안적인 장점이 존재합니다.
     2. Profiling 지원 : 빌드 시간이 느릴 경우 Stacklog를 검사할 수 있는 Profiling 기능을 지원합니다. 이를 통해 빌드 시 문제점을 점검할 수 있습니다. Reference : https://github.com/GoogleContainerTools/kaniko#kaniko-builds---profiling
     
     
   • Buildkit :
     
     1. Parallel Build 지원 : Buildkit은 Dockerfile에서 의존성이 없는 두 스테이지를 병렬로 실행해 빌드 속도를 높일 수 있습니다. 
     2. Opentracing 지원 : Opentracing을 지원해 Jaeger와 같은 도구에서 Trace를 통합해 추적할 수 있습니다. Reference : https://github.com/moby/buildkit#opentracing-support
     
     
   • Buildah :
     
     1. Bash Script 지원 : Buildah는 Dockerfile 대신 친숙한 Bash script를 사용하여 이미지를 빌드할 수 있습니다. 따라서 Dockerfile 작성에 익숙치 않은 개발자도 쉽게 이미지 빌드 작업을 수행할 수 있습니다.

 

Kaniko의 Snapshot이 동작하는 모습

 

Buildkit의 Remote Caching이 동작하는 모습

---

1.  

 

3-2. Performance

 

Benchmark를 통해 각 빌드 도구들의 상황 별 빌드 속도를 측정한 결과입니다.

 

• 모든 수치는 5번의 빌드 시간을 평균낸 값을 사용했습니다.
• 캐시 및 기타 옵션은 기본값, 혹은 Best Practice에 근접한 옵션으로 진행했습니다.
• 빌드 대상은 Java로 이루어진 Micro-service DEMO의 adservice 애플리케이션을 사용했습니다.
• Buildkit에 유리한 결과가 나오지 않도록 Parallel Build를 사용할 수 없는 Dockerfile로 진행했습니다.

 

빌드 도구 간 회차 별 빌드 속도 비교

 

Kaniko, Buildkit, Buildah의 첫번째, 두번째 빌드 시 빌드 속도 비교 Benchmark 결과입니다.

첫번째 빌드는 캐시가 없는 상태의 빌드 속도를, 두번째 빌드는 캐시가 적중한 상태의 빌드 속도를 알 수 있습니다.

Kaniko는 첫번째 시도에서 가장 느린 속도로 이미지를 빌드했지만, 두번째 시도는 캐시 기능을 이용하지 않은 Buildah보다 빠르고 Buildkit보다는 느렸습니다.

Buildkit은 첫번째, 두번째 시도 모두 빌드 속도가 가장 빨랐습니다.

Buildah는 Remote 캐싱을 지원하지 않기 때문에 첫번째, 두번째 결과가 동일하게 나왔음을 알 수 있습니다. 두 결과 모두 Kaniko와 Buildkit 첫번째 시도의 중간값이 나왔습니다.

 

 

 

Cache Exporting 여부에 따른 회차 별 Buildkit 빌드 속도 비교

 

 

Buildkit의 Cache Exporting 기능은 Remote 레포지토리로 캐시를 적재하는 기능으로, 이 기능의 사용 여부에 따라 빌드 속도가 달라짐을 알 수 있습니다.

첫번째, 두번째 빌드 모두 Exporting 기능을 사용하지 않은 빌드가 더 빨랐습니다.

이는 Export에 소모된 시간이 절약된 결과로 Cache Export 기능을 사용하지 않으면 이후 빌드는 캐시를 사용할 수 없지만, 당장의 빌드는 빠르게 수행할 수 있다는 Trade-off가 존재합니다.

 

 

 

Snapshot Mode에 따른 회차 별 Kaniko 빌드 속도 비교

 

 

 

Kaniko는 3가지의 Snapshot Mode를 지원합니다. Snapshot 모드에 따라 Kaniko가 Snapshot을 생성하는 조건이 달라집니다.

이 중 Full 모드는 파일의 모든 요소를 고려해서 Snapshot 여부를 결정하기 때문에 퍼포먼스는 가장 낮지만 캐시 적중률을 높일 수 있습니다.

반면 Minimal 모드는 파일의 Mtime만을 고려하기 때문에 퍼포먼스는 가장 높지만 캐시 적중률이 낮습니다.

본 Benchmark에서는 Minimal 모드가 첫번째, 두번째 빌드 모두 빌드 시간이 빨랐지만 빌드 구성에 따라 달라질 여지가 많습니다.

 

 

3-3.  Community

 

커뮤니티는 도구를 운영하는 난이도와 기능 추가 여부에 큰 영향을 미치기 때문에 오픈소스 빌드 도구를 선택함에 있어 중요한 요소입니다.

 

다음은 각 도구의 공식 Github 페이지 수치를 비교한 자료입니다.

 

 

 

여러 수치로 봤을때 Github 커뮤니티의 규모는 Kaniko > Buildkit > Buildah 순으로 집계되었습니다.

 

 

 

이 외에 Google에 각 도구들을 검색했을시 Kaniko는 약 378,000개, Buildkit은 168,000개, Buildah는 116,000개 결과가 검색되었습니다.

 

따라서 Community의 지원을 받기 가장 수월한 도구는 Kaniko이며, 그 뒤를 Buildkit과 Buildah가 따른다고 볼 수 있습니다.

 

---

4. Result

 

각 결과를 종합한 테이블은 아래와 같습니다.

 

	Kaniko	Buildkit	Buildah
OCI Compliant	✅	✅	✅
Daemonless	✅	✅	✅
Multi-stage Build	✅	✅	✅
Remote Caching	✅	✅
Security	🔵	🔴	🟡
Compatibility	🔵	🟡	🔵
Usability	🔵	🔵	🔴
Performance	🔵	🟡	🔴
Community	🟡	🔵	🔴

🟡 : 상 

🔵 : 중

🔴 : 하

 

상,중,하를 각각 3,2,1점으로 환산할 시, 최종 점수는 Kaniko와 Buildkit이 동률입니다.

Buildah는 가장 낮은 점수를 얻었습니다.

 

지금까지 비교한 결과를 토대로 아래와 같이 정리할 수 있습니다.

 

현재 가장 널리 사용되고 있으며, 안정적으로 사용할 수 있는 빌드 도구를 원한다면 Kaniko를 선택할 수 있습니다.

Parallel Build 기능을 활용할 수 있으며 빌드 퍼포먼스가 가장 중요하다면 Buildkit을 선택할 수 있습니다.

Kaniko와 Buildkit이 가지고 있는 보안적인 단점을 극복하고 싶다면 Buildah를 선택할 수 있습니다.

 

 

---

5. 마치며

지금까지 Kubernetes 환경에서 사용할 수 있는 빌드 도구들의 특성 및 성능을 비교 분석해봤습니다.

 

빌드 도구를 선택함에 있어 모든 상황에서 월등하게 사용할 수 있는 "Silver Bullet"은 없습니다.

 

모두 고유한 특성을 가지고 있기 때문에 어떤 도구가 좋은 선택일지는 요구사항 및 환경에 따라 달라질 것입니다.

 

중요한 것은 도구를 사용하고자 하는 상황을 정확히 파악하고 이를 기반으로 정량적 수치를 비교함으로써 알맞은 도구를 선택하는 것이라고 생각합니다.

 

이 포스팅을 보시는 분들이 빌드 도구를 선택하는데 있어 도움을 받으셨으면 합니다.