make "docker-env" on containerd stable

[medyagh]

currently we warn users
out.WarningT("Using the docker-env command with the containerd runtime is a highly experimental feature, please provide feedback or contribute to make it better")

[afbjorklund]

This needs more details, on what is actually required before it is considered non-experimental?

As long as it is using nerdctld, it will always be experimental... The alternative is to use dockerd:

• Deprecate the Docker container runtime and merge with containerd #21841

Then it will run the real docker daemon with containerd storage, and continue to be supported.

---

In order of preference:

1. minikube image

2. minikube ssh

3. minikube docker-env (legacy)

Recently we saw Docker v29 client breaking the support for Podman servers, after an API upgrade...

It has been upgraded to Docker v25 LTS now, but it can very well break again with Docker v30 and up.

[afbjorklund]

I think it will be possible to make load and build still work, assuming DOCKER_BUILDKIT=0 that is...

But the support for running Docker in minikube (no Kubernetes) is something that should be removed.
It is useful as a testing target when developing the VM, but nothing that needs to be supported for users.

https://minikube.sigs.k8s.io/docs/tutorials/docker_desktop_replacement/ - there are other replacements

---

Here is the default response, when building: (this is a known issue, there is no support for running a builder)

 => ERROR [internal] booting buildkit                                                                                                                                              10.9s
 => => pulling image moby/buildkit:buildx-stable-1                                                                                                                                 10.7s
 => => creating container buildx_buildkit_default                                                                                                                                   0.1s
------
 > [internal] booting buildkit:
------
WARNING: No output specified with docker-container driver. Build result will only remain in the build cache. To push result image into registry use --push or to load image into docker use --load
ERROR: Error response from daemon: 404 page not found

Here is the DOCKER_BUILDKIT=0 response: (this is the recommended workaround, for nerdctld and podman)

DEPRECATED: The legacy builder is deprecated and will be removed in a future release.
            BuildKit is currently disabled; enable it by removing the DOCKER_BUILDKIT=0
            environment-variable.

Sending build context to Docker daemon  2.048kB
#1 [internal] load build definition from Dockerfile
...
#5 DONE 0.2s
#6 exporting to image
#6 exporting layers 0.0s done
#6 exporting manifest sha256:1708ad31e0f50155f0ec1f2749680a09e0ea4f6a3bc213b5cd942243788f14e8 done
#6 exporting config sha256:2bcdd44147725390a6aaef734d78d83dca3b64a110ddfc574d74d22bea73afe2 done
#6 naming to <none>@sha256:1708ad31e0f50155f0ec1f2749680a09e0ea4f6a3bc213b5cd942243788f14e8 done
#6 DONE 0.1s

Both sending the build context and exporting image, is something that is avoided when using dockerd...

1. The build context is handled over gRPC now, so only need to send those files that are actually needed

2. The containerd worker already stores the layer in the right store, so there is no need to export/import

Podman always uses the legacy builder ("buildah"), there is no support yet in podman buildx for BuildKit

[afbjorklund]

The docker-env command on podman/cri-o has some similar issues, to nerdctl/containerd:

• Support docker-env with cri-o runtime #22547 (comment)

But it does support running BuildKit in a container, as long as you use docker build --load.

To push result image into registry use --push or to load image into docker use --load

---

Both are considered legacy compatibility, and is not fully supported by the upstream.

There might be problems with future Docker Engine API versions, including version 29.

 API version:       1.41 (downgraded from 1.50)

The only supported variant is running podman or nerdctl locally, without the daemon.

[afbjorklund]

Newer podman versions (6) will need to switch database, but that should be OK with cri-o...

https://blog.podman.io/2025/12/boltdb-database-migration/

It has started spewing warnings in 5.7: WARN[0000] The deprecated BoltDB database driver is in use.

• Minikube fails to detect Podman container IP when BoltDB deprecation warning is emitted (Fedora 42, Podman 5.7.0, boltdb) #22537

That is, cri-o only uses the image blobs in the storage and doesn't care about the database.

So podman can use BoltDB or it can SQLite, it doesn't matter. They don't share containers at all.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale