Kaniko vs BuildKit: замеряем время, CPU и память сборки в кластере

Вот важная новость с фронта ИИ: chemtech 5 минут назад Kaniko vs BuildKit: замеряем время, CPU и память сборки в кластере Простой 7 мин 0 DevOps * Kubernetes * Туториал ВведениеВ Kubernetes-кластере рано или поздно встаёт вопрос: где собирать Docker image приложений? Вариант «на своей машине разработчика» не масштабируется на команду. Вынос сборок на отдельную виртуальную машину решает эту проблему, но создаёт накладные расходы на обслуживание инфраструктуры и лишает ключевых преимуществ k8s: отдельная ВМ не масштабируется горизонтально под нагрузку, параллельные джобы конкурируют за общие CPU, RAM и диск, а накапливающийся кэш требует регулярной очистки.

Классических ответов два — Kaniko и BuildKit. Kubernetes executor с использованием Kaniko или BuildKit лишен этих недостатков: сборка происходит в изолированных подах прямо на нодах кластера, ресурсы динамически масштабируются, а виртуальные машины для Docker-демона больше не требуются. Kaniko (GoogleContainerTools/kaniko) — инструмент от Google для сборки без privileged-контейнера.

Технические детали

С июня 2025 года репозиторий архивирован и проект больше не развивается. BuildKit (moby/buildkit) — стандартный движок docker build, работающий в k8s в daemonless и rootless-режиме без привилегий ноды. В этой статье будет протестировано 5 проектов разных языков и фреймворков собираются обоими инструментами в одних и тех же условиях, с замером времени, потребления CPU/RAM и поведения кэша.

В конце — итоговая сводная таблица и разбор преимуществ и недостатков каждого подхода для продакшна. Оба инструмента используют только registry-кэш. Локальный кэш на ноде намеренно не используется — он копится на диске и требует очистки.

Registry-кэш чистить не нужно: манифест кэша перезаписывается на каждом прогоне, а мусор подчищает garbage collection реестра. Хранясь вне пода, он переживает пересоздание и смену ноды. Сравниваемые проектыБенчмарк собирает 5 проектов — по одному на характерный «профиль сборки»:№ПроектЯзык/FrameworkПрофиль сборкиРепозиторий1Next.

Отраслевые последствия

jsNode/React SSRnpm ci + сборка клиентаnextjs2Nuxt 3Node/Vue SSRnpm ci + сборка клиентаnuxtjs3Go HTTP-сервисGogo build → статический бинарник (из scratch)golang4Android APKJava/Kotlin, GradleassembleRelease, тяжёлый Gradle/SDKandroid5ML: PyTorch inferencePythonpip install torch + скачивание ~1. 3 ГБ весов в BUILD-стадии (public S3-бакет)ml-pytorchАрхитектура стендаАрхитектура стендаРазвёртываниеПеред развертыванием gitlab runner требуется чтобы у вас был создан Kubernetes кластер, S3 бакет и Container Registry. В S3 бакет заливаем файл весов, например pytorch_model для job ml-pytorch.

Для мониторинга устанавливаем VictoriaMetrics k8s-stack. Установка GitLab RunnerУстанавливаем GitLab Runner с такой конфигурацией values. yaml:gitlabUrl: # Количество параллельно выполняемых джобов.

Событие, по словам экспертов, усилит конкуренцию в сфере ИИ.