But for a richer Kubernetes environment, you might want to look at
CRI-O
https://cri-o.io/ and it's GitHub repo (
https://github.com/cri-o/cri-o).
Others more involved than I with the Kubernetes side of things will likely
have more insight.
The built-in Docker support in Kubernetes (the so called "dockershim") is
getting deprecated - in favor of the standard interfaces such as CRI (for
runtime) and CNI (for network):
https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kub...
https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/1985...
So there it will be between "containerd" (supported by docker/moby for some
features) and "cri-o" (supported by podman for some features), as two
available choices for the CRI:
*
https://kubernetes.io/docs/setup/production-environment/container-runtime...
*
https://kubernetes.io/docs/setup/production-environment/container-runtime...
Both are available out-of-the-box in minikube, by using the
--container-runtime start parameter:
--container-runtime string The container runtime to be used (docker, cri-o,
containerd).
You can also connect directly to them, but there is nothing in Kubernetes
itself that requires this...
(it is a minikube feature, with the docker-env and podman-env commands, to
set the environment)
The plan is to make docker a socket-activated supporting service for
containerd (not a default daemon), and to make podman a socket-activated
supporting service for cri-o (same)...
*
https://github.com/kubernetes/minikube/issues/9230
*
https://github.com/kubernetes/minikube/issues/9232
We mostly use docker/podman when it comes to doing a "load" from an archive
in the cache, or doing a "build" from a Dockerfile/Containerfile to an
image. The rest is done by crictl.
/Anders
PS. Currently minikube still use the legacy docker-2376 and podman-varlink
protocols though.
But eventually both of them will be replaced, by using the unix sockets
over a ssh connection...