Introduction

When Jenkins runs on Kubernetes, docker: command not found usually means the agent container simply does not contain the Docker CLI. Even if you add the CLI, builds can still fail because a Kubernetes Pod does not automatically have access to a Docker daemon.

That distinction matters. There are really two separate requirements: a client binary and a build backend. In modern Kubernetes CI, the cleanest fix is often to stop depending on Docker-in-Docker and switch to a daemonless image builder such as Kaniko, BuildKit, or Buildah.

What the Error Actually Means

The literal message docker: command not found is the shell telling you the binary is missing from the agent image. It does not yet say anything about permissions, the socket, or registry credentials.

You can confirm that quickly inside the Jenkins agent container:

which docker
ls -l /var/run/docker.sock

Possible outcomes:

• no docker binary: install it or change strategy
• binary exists but no daemon socket: Docker commands still cannot run
• socket exists but permission is denied: runtime access is blocked

That is why adding apt-get install docker is only part of the story.

Why This Happens in Kubernetes Agents

Traditional Jenkins agents on VMs often had Docker preinstalled and talked to the host daemon. Kubernetes agents are different:

• the Pod image is usually minimal
• the node runtime may not be Docker at all
• mounting a host Docker socket is often disallowed
• privileged containers are restricted in many clusters

So an old Jenkins pipeline that assumed docker build would be available often breaks when migrated to Kubernetes.

Recommended Fix: Use a Daemonless Builder

If your goal is "build and push a container image," use a tool designed for Kubernetes instead of recreating a VM-style Docker environment.

A common choice is Kaniko. The Jenkins pipeline runs a container that already contains the build tool and pushes directly to the registry.

1pipeline {
2  agent {
3    kubernetes {
4      yaml '''
5apiVersion: v1
6kind: Pod
7spec:
8  containers:
9    - name: kaniko
10      image: gcr.io/kaniko-project/executor:v1.23.2
11      command: ["sleep"]
12      args: ["99d"]
13      volumeMounts:
14        - name: regcred
15          mountPath: /kaniko/.docker
16  volumes:
17    - name: regcred
18      secret:
19        secretName: regcred
20'''
21    }
22  }
23  stages {
24    stage('Build image') {
25      steps {
26        container('kaniko') {
27          sh '/kaniko/executor --context=$WORKSPACE --destination=registry.example.com/app:build-42'
28        }
29      }
30    }
31  }
32}

This removes the need for a Docker daemon entirely.

If You Really Need Docker CLI

Some pipelines genuinely rely on Docker-specific behavior. In that case you must provide both pieces:

1. an agent image with the Docker CLI installed
2. a reachable Docker daemon

A minimal diagnostic Pod might look like this:

1apiVersion: v1
2kind: Pod
3metadata:
4  name: docker-client-test
5spec:
6  containers:
7    - name: docker
8      image: docker:27-cli
9      command:
10        - /bin/sh
11        - -c
12        - docker version && sleep 3600
13      volumeMounts:
14        - name: docker-sock
15          mountPath: /var/run/docker.sock
16  volumes:
17    - name: docker-sock
18      hostPath:
19        path: /var/run/docker.sock

This setup is operationally fragile and often blocked by cluster policy. It also couples builds to node runtime details. Use it only if you control the cluster and accept the security tradeoffs.

Registry Credentials Are a Separate Problem

Teams often fix the CLI problem and then hit a push failure. That is expected. Image building and image publishing are separate concerns.

For Jenkins on Kubernetes, credentials usually come from:

• Kubernetes secrets mounted into the agent Pod
• cloud-native workload identity
• Jenkins credentials injected into the build step

Do not conflate docker not found with authentication problems. Solve them in order.

Prefer Reproducible Agent Images

Whether you use Docker CLI, Kaniko, or BuildKit, build the Jenkins agent image intentionally. Avoid ad hoc package installation during the pipeline run. A pinned agent image gives you:

• reproducible tooling versions
• faster startup
• fewer network dependencies during CI
• easier debugging when builds fail

In other words, the fix should live in your agent definition, not in a shell step that mutates the environment every run.

Common Pitfalls

The first mistake is assuming that installing the Docker CLI solves the whole problem, when the daemon is still missing. Another is mounting the host Docker socket into shared cluster workloads without understanding the security implications. Teams also migrate old Jenkinsfiles unchanged and then wonder why VM assumptions fail inside Pods. Finally, switching to Kaniko or BuildKit but keeping old docker build commands in the pipeline defeats the point of changing tools.

Summary

• 'docker: command not found means the Jenkins agent image lacks the Docker CLI.'
• Even with the CLI installed, you still need a working build backend.
• On Kubernetes, daemonless builders such as Kaniko are usually the better design.
• If you must use Docker, provide both the binary and daemon access deliberately.
• Treat registry authentication and image-building strategy as separate concerns.