In Kubernetes, use the official example manifests at github.com/moby/buildkit/tree/master/examples/kubernetes (pod.rootless.yaml, deployment+service.rootless.yaml, statefulset.rootless.yaml, job.rootless.yaml). Prefer the *.rootless.yaml variants to minimize container-breakout risk; fall back to *.privileged.yaml if rootless mode doesn't work in your cluster. Apply with `kubectl apply -f pod.rootless.yaml` then run `buildctl --addr kube-pod://buildkitd build --frontend dockerfile.v0 --local context=/path --local dockerfile=/path` (requires RBAC access to pods/exec; if unavailable, use the Deployment+Service variant with mTLS instead).
Key pod.rootless.yaml settings (from examples/kubernetes/pod.rootless.yaml): image `moby/buildkit:master-rootless`, args: ['--oci-worker-no-process-sandbox'], securityContext: seccompProfile.type=Unconfined (needs K8s >=1.19), appArmorProfile.type=Unconfined (needs K8s >=1.30), runAsUser=1000, runAsGroup=1000; mount an emptyDir volume at /home/user/.local/share/buildkit (the image's default VOLUME there doesn't work rootless on nosuid/nodev filesystems like GKE COS). Readiness/liveness probes run `buildctl debug workers`.
`--oci-worker-no-process-sandbox` (a buildkitd flag) is used in place of Docker's `--security-opt systempaths=unconfined` because Kubernetes lacks an equivalent option; it avoids creating a new PID namespace, but is discouraged outside Kubernetes since it can't terminate leftover ExecOp processes and allows ExecOp containers to kill/ptrace arbitrary processes in the buildkitd container (docs/rootless.md).
For a single ephemeral container doing client+daemon in one shot ('daemonless mode'), use the moby/buildkit:master-rootless image's buildctl-daemonless.sh entrypoint: `docker run -it --rm --security-opt seccomp=unconfined --security-opt apparmor=unconfined --security-opt systempaths=unconfined -v /path/to/dir:/tmp/work --entrypoint buildctl-daemonless.sh moby/buildkit:master-rootless build --frontend dockerfile.v0 --local context=/tmp/work --local dockerfile=/tmp/work` (from the moby/buildkit README 'Daemonless' section).
Known gotchas
overlayfs snapshotter requires kernel >= 5.11 (or an Ubuntu kernel); on kernel >= 4.18 fuse-overlayfs is used automatically instead, and below 4.18 the native snapshotter is used. If you hit overlayfs errors, explicitly run `buildkitd --oci-worker-snapshotter=fuse-overlayfs` (needs `docker run --device /dev/fuse`) or `--oci-worker-snapshotter=native`.
Rootless network mode is always network.host per docs/rootless.md 'Known limitations'.
Common rootless failures documented with fixes: `newuidmap`/`/etc/subuid` errors (see rootlesscontaine.rs/getting-started/common/subuid/); `fork/exec /proc/self/exe: no space left on device` with a max_user_namespaces warning → `sysctl -w user.max_user_namespaces=N` on host nodes; `fork/exec ... permission denied` about apparmor_restrict_unprivileged_userns → set `kernel.apparmor_restrict_unprivileged_userns=0` (needed on Ubuntu 24.04+); `mount proc:/proc ... operation not permitted` → missing `--security-opt systempaths=unconfined`.
On Google's Container-Optimized OS and similar nosuid/nodev-mounted default volumes, the image's default VOLUME /home/user/.local/share/buildkit silently fails to work rootless — must mount an explicit emptyDir there instead.
`docker build` has used Buildx+BuildKit by default since Docker Engine 23.0 — the standalone buildkitd/buildctl workflow is only needed when you can't or don't want to run the Docker daemon (per moby/buildkit README).
Give your agent this knowledge — and 17,300+ more routes
One MCP install gives any agent live access to the full route map across 5,900+ domains, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp
Need this verified for your stack — or a route we don't have yet?