kaniko — утилита, которая собирает контейнерные образы по Dockerfile, не подключаясь к Docker Engine.Он работает внутри контейнера или Kubernetes-кластера и особенно полезен в средах, где запуск Docker небезопасен, невозможен или нежелателен.
Проект поддерживается сообществом и развивается как официальный форк после архивации оригинального репозитория Google. Актуальная версия поддерживается в репозитории Chainguard.
Зачем нужен kaniko
Классическая сборка Docker-образов предполагает доступ к Docker-демону (dockerd). Это создаёт ряд проблем:
- требуется privileged-доступ;
- повышаются риски безопасности;
- сложно использовать в Kubernetes-кластерах;
- не подходит для многих CI/CD-платформ.
kaniko решает эти проблемы, так как:
- не использует Docker-демон;
- запускается как обычный контейнер;
- безопасен для CI и Kubernetes;
- поддерживает стандартные Dockerfile.
По сути, kaniko читает Dockerfile, пошагово выполняет инструкции и напрямую пушит готовый образ в registry.
Где и как используют kaniko
1. CI/CD пайплайны
kaniko часто используют в:
- GitLab CI
- GitHub Actions
- Jenkins
- Argo Workflows
Он отлично подходит для сборки образов в shared-раннерах без privileged-режима.
2. Kubernetes-кластеры
kaniko можно запускать как:
- Job
- Pod
- часть CI внутри кластера
Это удобно, если весь процесс деплоя уже живёт в Kubernetes.
3. Повышенные требования к безопасности
В средах с жёсткими security-политиками (банки, enterprise-проекты) kaniko позволяет собирать образы без доступа к хост-системе.
Как работает kaniko
Упрощённо процесс выглядит так:
- kaniko запускается в контейнере
- Читает Dockerfile
- Выполняет инструкции (FROM, RUN, COPY и т.д.)
- Создаёт слои образа во временной файловой системе
- Пушит результат в container registry
Docker-демон на этом этапе не используется вообще.
Установка и запуск kaniko
Базовый запуск через Docker
-v $(pwd):/workspace \
-v ~/.docker/config.json:/kaniko/.docker/config.json:ro \
gcr.io/kaniko-project/executor:latest \
--dockerfile=Dockerfile \
--context=/workspace \
--destination=registry.example.com/my-image:latest
Здесь:
- /workspace — контекст сборки
- config.json — доступы к registry
- –destination — куда пушить образ
Запуск kaniko в Kubernetes
Пример Job:
kind: Job
metadata:
name: build-image-kaniko
labels:
app: kaniko-builder
spec:
backoffLimit: 1
template:
metadata:
labels:
app: kaniko-builder
spec:
restartPolicy: Never
containers:
- name: executor
image: gcr.io/kaniko-project/executor:latest
args:
- "--dockerfile=/workspace/Dockerfile"
- "--context=git://github.com/example-org/sample-app.git#refs/heads/main"
- "--destination=registry.example.com/sample-app:1.0.0"
- "--cache=true"
- "--cache-repo=registry.example.com/kaniko-cache"
volumeMounts:
- name: docker-auth
mountPath: /kaniko/.docker
volumes:
- name: docker-auth
secret:
secretName: registry-docker-config
Часто используемые параметры
| Параметр | Описание |
|---|---|
| –dockerfile | Путь к Dockerfile, который используется для сборки образа. |
| –context | Контекст сборки: локальная директория или Git-репозиторий. |
| –destination | Адрес container registry и тег итогового образа. |
| –no-push | Собирает образ без отправки (push) в registry. |
| –cache | Включает кэширование слоёв для ускорения повторных сборок. |
| –cache-repo | Registry, в котором хранятся закэшированные слои образов. |
| –snapshotMode | Режим создания слоёв файловой системы (например, time или redo). |
| –verbosity | Уровень логирования kaniko (debug, info, warn). |
| –build-arg | Передача build-аргументов в Dockerfile. |
Кэширование сборок
kaniko поддерживает layer-cache, что ускоряет повторные сборки:
--cache-repo=registry.example.com/kaniko-cache
Важно: кэш хранится в registry, а не локально.
Ограничения kaniko
Стоит учитывать:
- некоторые нестандартные инструкции Docker могут работать иначе;
- нет интерактивного shell во время сборки;
- сборка может быть медленнее, чем Docker с локальным кэшем;
- требуется корректно настроенный registry-доступ.
FAQ
- Что из себя представляет kaniko и для чего его можно использовать?
kaniko — это инструмент для сборки container-образов из Dockerfile без использования Docker-демона. Он применяется в CI/CD-пайплайнах и Kubernetes-кластерах, где запуск Docker в privileged-режиме невозможен или нежелателен. - Работает ли kaniko в связке с Kubernetes?
Да, kaniko изначально ориентирован на работу в Kubernetes. Его можно запускать как Job или Pod, а также использовать в составе CI внутри кластера. Это позволяет собирать и публиковать образы напрямую в registry без доступа к хост-системе. - Нужен ли Docker для работы kaniko?
Нет. Docker-демон (dockerd) не требуется. kaniko выполняет сборку образов полностью в user-space, что делает его безопасным для облачных и корпоративных сред. - Поддерживает ли kaniko обычные Dockerfile?
Да, kaniko работает со стандартными Dockerfile, включая multi-stage сборки. Большинство инструкций (FROM, RUN, COPY, ARG и др.) поддерживаются без изменений. - Как kaniko работает с кэшем?
kaniko поддерживает кэширование слоёв, но хранит их не локально, а в container registry. Для этого используется параметр –cache=true и отдельный репозиторий для кэша. Это ускоряет повторные сборки в CI/CD. - Можно ли использовать kaniko для локальной сборки образов?
Технически — да, kaniko можно запускать локально в контейнере. Однако основной сценарий его использования — автоматизированные сборки в CI/CD и Kubernetes, а не локальная разработка. - Чем kaniko отличается от Docker build?
Главное отличие — отсутствие Docker-демона. Docker build требует доступ к хосту и privileged-режим, тогда как kaniko работает как обычный контейнер и безопасен для изолированных сред. - Подходит ли kaniko для production-пайплайнов?
Да. kaniko широко используется в production CI/CD-процессах, особенно в облачных и Kubernetes-ориентированных инфраструктурах с повышенными требованиями к безопасности.
Вывод
kaniko — это практичный и безопасный инструмент для сборки container-образов в современных инфраструктурах. Он особенно хорошо подходит для Kubernetes-кластеров и CI/CD-пайплайнов, где использование Docker-демона либо запрещено, либо нежелательно.
Если вам требуется собирать контейнерные образы:
- без privileged-доступа
- внутри Kubernetes
- с прозрачной интеграцией в CI
kaniko — один из самых надёжных вариантов на сегодня.