BuildKit vs Kaniko: CIでのイメージbuildに適しているのはどちら?
BuildKitは高速でcacheが豊富なデフォルトのビルダー。Kanikoはdaemonなしでイメージをbuildし、制限されたKubernetesのrunnerに適する。
BuildKitはDockerのモダンなbuildエンジンで、高度なcachingと並列実行を備えます。KanikoはDockerfileから、Dockerのdaemonや特権アクセスなしに、containerやKubernetesのpod内でcontainerイメージをbuildします。
| BuildKit | Kaniko | |
|---|---|---|
| Daemonの必要性 | あり (buildkitd) | なし |
| 特権アクセス | しばしば必要 | 不要 |
| Caching | 高度(local/registry/inline) | layer cacheをregistryへ |
| 速度 | 概して高速 | 良好、機能は少ない |
| 最適な用途 | 一般的なCI、Docker build | Kubernetes / 非特権runner |
CIでは
BuildKitは通常、高度なcaching(registry、inline、mount cache)と並列のbuildステージのおかげで、より高速で高機能なビルダーです - 一般的なCIのrunnerで理想的です。Kanikoの利点は、daemonや特権モードなしでbuildできることで、dockerdの実行が望ましくない制限されたKubernetesベースのrunnerに適します。どちらもlayer cacheをregistryにpushして、繰り返しのbuildを高速化できます。
パイプラインでの選び方
標準的なrunnerでの速度とcachingには、BuildKit(docker buildx経由)を選びましょう。runnerが非特権またはKubernetes-nativeでbuild daemonを実行できない場合はKanikoを使いましょう。いずれの場合もregistryベースのlayer cachingを設定しましょう。
結論
最高速度とcachingを求める標準runner: BuildKit。daemonを実行できない非特権またはKubernetesのrunner: Kaniko。rebuildを避けるため、どちらでもlayerをregistryにcacheしましょう。