kaniko: compilação de imagens Docker sem Docker no Kubernetes e CI/CD

kaniko é uma ferramenta que constrói imagens de contêiner a partir de um Dockerfile sem se conectar ao Docker Engine. Ela é executada dentro de um contêiner ou de um cluster Kubernetes e é especialmente útil em ambientes onde a execução do Docker é insegura, impossível ou indesejada.

O projeto é mantido pela comunidade e evolui como um fork oficial após o arquivamento do repositório original do Google. A versão atual é mantida no repositório da Chainguard.

Para que serve o kaniko

A construção tradicional de imagens Docker pressupõe acesso ao daemon Docker (dockerd). Isso gera uma série de problemas:

é necessário acesso privilegiado;
os riscos de segurança aumentam;
é difícil usar em clusters Kubernetes;
não é adequado para muitas plataformas de CI/CD.

O kaniko resolve esses problemas, pois:

não utiliza o daemon Docker;
é executado como um contêiner comum;
é seguro para CI e Kubernetes;
suporta Dockerfiles padrão.

Na prática, o kaniko lê o Dockerfile, executa as instruções passo a passo e envia a imagem final diretamente para o registry.

Onde e como o kaniko é utilizado

1. Pipelines de CI/CD

O kaniko é frequentemente utilizado em:

GitLab CI
GitHub Actions
Jenkins
Argo Workflows

Ele é ideal para a construção de imagens em runners compartilhados sem a necessidade de modo privilegiado.

2. Clusters Kubernetes

O kaniko pode ser executado como:

Job
Pod
parte do CI dentro do cluster

Isso é conveniente quando todo o processo de deploy já acontece no Kubernetes.

3. Requisitos elevados de segurança

Em ambientes com políticas de segurança rigorosas (bancos, projetos enterprise), o kaniko permite construir imagens sem acesso ao sistema host.

Como o kaniko funciona

De forma simplificada, o processo é o seguinte:

o kaniko é iniciado dentro de um contêiner
lê o Dockerfile
executa as instruções (FROM, RUN, COPY, etc.)
cria as camadas da imagem em um sistema de arquivos temporário
envia o resultado para um container registry

O daemon Docker não é utilizado em nenhum momento.

Instalação e execução do kaniko

Execução básica via Docker

docker run \

-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 — contexto de build
config.json — credenciais de acesso ao registry
--destination — destino para onde a imagem será enviada

Execução do kaniko no Kubernetes

apiVersion: batch/v1

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

Parâmetros mais utilizados

Parâmetro	Descrição
--dockerfile	Caminho para o Dockerfile utilizado na construção da imagem.
--context	Contexto de build: diretório local ou repositório Git.
--destination	Endereço do container registry e a tag da imagem final.
--no-push	Constrói a imagem sem enviá-la (push) para o registry.
--cache	Ativa o cache de camadas para acelerar builds repetidos.
--cache-repo	Registry onde as camadas em cache são armazenadas.
--snapshotMode	Modo de criação das camadas do sistema de arquivos (por exemplo, time ou redo).
--verbosity	Nível de log do kaniko (debug, info, warn).
--build-arg	Passagem de argumentos de build para o Dockerfile.

Cache de builds

O kaniko oferece suporte a cache de camadas, o que acelera builds subsequentes:

--cache=true \ --cache-repo=registry.example.com/kaniko-cache

Importante: o cache é armazenado no registry, e não localmente.

Limitações do kaniko

É importante considerar:

algumas instruções Docker não padrão podem se comportar de forma diferente;
não há shell interativo durante o build;
o build pode ser mais lento do que o Docker com cache local;
é necessário configurar corretamente o acesso ao registry.

FAQ

O que é o kaniko e para que ele pode ser usado? O kaniko é uma ferramenta para construir imagens de contêiner a partir de Dockerfiles sem utilizar o daemon Docker. Ele é usado em pipelines de CI/CD e clusters Kubernetes onde a execução do Docker em modo privilegiado não é possível ou desejável.
O kaniko funciona em conjunto com Kubernetes? Sim. O kaniko foi projetado para funcionar no Kubernetes. Ele pode ser executado como Job ou Pod, além de ser usado como parte do CI dentro do cluster. Isso permite construir e publicar imagens diretamente no registry sem acesso ao host.
É necessário Docker para usar o kaniko? Não. O daemon Docker (dockerd) não é necessário. O kaniko realiza todo o processo de build em user space, o que o torna mais seguro para ambientes corporativos e em nuvem.
O kaniko suporta Dockerfiles padrão? Sim. O kaniko funciona com Dockerfiles padrão, incluindo builds multi-stage. A maioria das instruções (FROM, RUN, COPY, ARG, etc.) é suportada sem alterações.
Como o kaniko trabalha com cache? O kaniko oferece cache de camadas, mas armazena esse cache em um container registry, e não localmente. Para isso, utiliza-se o parâmetro --cache=true e um repositório dedicado, acelerando builds repetidos em CI/CD.
É possível usar o kaniko para builds locais? Tecnicamente, sim — o kaniko pode ser executado localmente em um contêiner. No entanto, seu principal caso de uso são builds automatizados em CI/CD e Kubernetes, e não o desenvolvimento local.
Qual a diferença entre kaniko e docker build? A principal diferença é a ausência do daemon Docker. O docker build exige acesso ao host e modo privilegiado, enquanto o kaniko funciona como um contêiner comum e é mais seguro em ambientes isolados.
O kaniko é adequado para pipelines de produção? Sim. O kaniko é amplamente utilizado em pipelines de CI/CD em produção, especialmente em infraestruturas baseadas em Kubernetes com requisitos elevados de segurança.

Conclusão

kaniko é uma ferramenta prática e segura para a construção de imagens de contêiner em infraestruturas modernas. Ela é especialmente adequada para clusters Kubernetes e pipelines de CI/CD onde o uso do daemon Docker é proibido ou indesejado.

Se você precisa construir imagens de contêiner: