Kaniko: running in Docker vs Kubernetes executor differences in CI
Kaniko is designed to run as a container. Under a Kubernetes executor it runs as a pod, which is the intended shape. Under a Docker executor you must override the image entrypoint so your script can invoke the executor, and credentials live in /kaniko/.docker.
What this error means
The same Kaniko job that works on a Kubernetes executor fails on a Docker (or shell) executor with entrypoint or "should only be run inside of a container" errors, or vice versa.
# Docker executor without overriding the entrypoint runs /kaniko/executor
# with no args and exits, or the shell cannot invoke it:
ERROR: Job failed: exit code 1Common causes
The Docker executor keeps the Kaniko entrypoint
The Kaniko image entrypoint is the executor itself. Without clearing it, the CI runner cannot run your before_script or a shell around the build.
Kubernetes executor needs the debug image for a shell
To run shell commands (writing config.json) around Kaniko on a Kubernetes executor, you need the debug tag that includes busybox.
How to fix it
Override the entrypoint for shell-based jobs
Use the debug image and clear the entrypoint so your script can set up credentials and call the executor.
image:
name: gcr.io/kaniko-project/executor:debug
entrypoint: [""]
script:
- /kaniko/executor --context dir://. --dockerfile Dockerfile --destination $IMGOn a Kubernetes executor, run Kaniko as the pod
The Kubernetes executor already runs the job in a pod; the same debug image and cleared entrypoint apply.
How to prevent it
- Use the debug image with entrypoint cleared when you need a shell around Kaniko.
- Keep credential setup (config.json) in a script step before the executor.
- Do not run the raw Kaniko binary on a shell executor host.