Run BuildKit as a Kubernetes Driver (2026)

BuildKit, Docker’s next-gen builder, can replace the default Kubernetes container runtime driver for building images, offering significant speedups and advanced features.

Let’s see it in action. Imagine you have a simple Go application and a Dockerfile:

// main.go
package main

import "fmt"

func main() {
	fmt.Println("Hello, Kubernetes!")
}

# Dockerfile
FROM golang:1.20-alpine AS builder
WORKDIR /app
COPY main.go .
RUN go build -o myapp .

FROM alpine:latest
COPY --from=builder /app/myapp .
CMD ["./myapp"]

Normally, kubectl build (or docker build within a Kubernetes context) would use the default driver, which is often slow and lacks advanced features. By configuring Kubernetes to use BuildKit, we can dramatically improve this.

Here’s how you’d set it up. First, you need BuildKit running in your Kubernetes cluster. The easiest way is often via the official buildx image and a Kubernetes Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: buildkitd
spec:
  selector:
    matchLabels:
      app: buildkitd
  template:
    metadata:
      labels:
        app: buildkitd
    spec:
      containers:
      - name: buildkitd
        image: moby/buildkit:latest
        args:
        - --addr=tcp://0.0.0.0:7070
        ports:
        - containerPort: 7070
          name: buildkit

Apply this to your cluster:

kubectl apply -f buildkit-deployment.yaml

Next, you need to expose this BuildKit daemon. A Service is perfect for this:

apiVersion: v1
kind: Service
metadata:
  name: buildkitd
spec:
  selector:
    app: buildkitd
  ports:
    - protocol: TCP
      port: 7070
      targetPort: 7070

Apply the service:

kubectl apply -f buildkit-service.yaml

Now, you need to configure your environment to use this BuildKit service. The key is setting the BUILDKIT_HOST environment variable to point to your Kubernetes service. If your service is buildkitd in the default namespace, and Kubernetes DNS is working, this would be:

export BUILDKIT_HOST="tcp://buildkitd.default.svc.cluster.local:7070"

With this environment variable set, any BuildKit-enabled tool will attempt to connect to your Kubernetes-hosted BuildKit daemon. You can then use docker buildx build (which leverages BuildKit) to build your image directly into your cluster’s container registry.

Let’s assume you have a registry like my-docker-registry.example.com and you want to tag your image as my-docker-registry.example.com/my-app:v1.0.

docker buildx build --platform linux/amd64 -t my-docker-registry.example.com/my-app:v1.0 . --push

The --push flag tells buildx to push the image directly to the registry after building. The --platform flag is crucial for multi-platform builds, which BuildKit excels at.

The mental model here is shifting from a local build process that then pushes to a remote registry, to a distributed build process happening within your Kubernetes cluster, directly interacting with your registry. BuildKit handles the orchestration of build steps, parallel execution, caching, and multi-platform compilation. The Kubernetes driver for BuildKit makes the cluster the builder, not just the runner.

BuildKit’s advanced caching mechanisms are a significant advantage. It doesn’t just cache layers; it caches build steps based on their inputs and outputs. This means if you change a single line of code in your Go application, only the go build step and subsequent image copying will need to be re-executed, not the entire Dockerfile from scratch. This granular caching, combined with BuildKit’s parallel execution capabilities, can reduce build times from minutes to seconds for even complex applications.

The one thing most people don’t realize is how BuildKit’s solver works. It doesn’t execute instructions sequentially as written in the Dockerfile. Instead, it constructs a directed acyclic graph (DAG) of build operations. It analyzes dependencies between these operations by looking at the inputs and outputs of each command. Then, it executes independent operations in parallel and reuses cached results whenever possible. This graph-based approach is what enables its advanced parallelism and caching, making it fundamentally different from older builders that often just ran commands one after another.

The next step is to explore BuildKit’s secrets management and build cache propagation across multiple BuildKit daemons.