Clarification on whether Docker will always be required

[mattysweeps]

The Kind homepage contains this banner.

Dockershim deprecation does NOT impact kind.  🐳
If you already use kind you've actually been testing your workloads on containerd!

While kind uses docker or podman on your host, it uses CRI / containerd "inside" the nodes and does not use dockershim.

However, creating a cluster without the docker cli results in this error message

$ kind create cluster                    
ERROR: failed to create cluster: failed to list clusters: command "docker ps -a --filter label=io.x-k8s.kind.cluster=kind --format '{{.Names}}'" failed with error: exec: "docker": executable file not found in $PATH               
Command Output:

Which comes from https://github.com/kubernetes-sigs/kind/blob/master/pkg/cluster/internal/providers/docker/provider.go#L97

I believe I have a decent understanding of what dockershim is and why it's being deprecated.
https://kubernetes.io/blog/2020/12/02/dockershim-faq/

My question is:

If kind is performing docker commands, then isn't it still reliant on Docker? I know that's slightly different from dockershim, but couldn't Kind use crictl or containerd's libraries directly to remove the need for docker altogether?

[mattysweeps]

Additionally, I think an error should be thrown here instead of defaulting to docker.
https://github.com/kubernetes-sigs/kind/blob/master/pkg/cluster/provider.go#L79

Maybe Kind could have a crictl provider?

[BenTheElder]

Dockershim is a component in Kubernetes, kind doesn't need dockershim, it does need docker or podman currently.

Kind runs containerd inside the nodes (which are created with podman or docker) and Kubernetes runs against that.

#1369 for a crictl provider.

The error is thrown when podman nor docker are present. Podman is still experimental.

The kind docs specify that docker must be installed. There's no relationship to dockershim though.

[BenTheElder]

There hasn't been much interest in a crictl based provider because developers use docker or podman much more than they use say containerd in production. But as mentioned in the note if you run kind you've already run your app "in production" against containerd / CRI instead of dockershim.

Kubernetes is not trying to "kill docker" or anything like that, we have nothing against docker. It's just in production environments for Kubernetes's usage CRI is a more appropriate target and is implemented lower level than docker, and Kubernetes does not want to continue implementing dockershim as a special case built in when containerd can be used instead. On developer machines docker or podman are better targets than CRI.

Whereas kind is: not for production and not using dockershim in any way. We are however working to GA the podman support so users have options.

[mattysweeps]

Thanks for the information!

[BenTheElder]

one important point I neglected here: for users developing Kubernetes itself, docker is required upstream going forward (xref: kubernetes/enhancements#2420) so kind will require it for that (building kubernetes from source and running it).

[BenTheElder]

After #2069 it will be possible to do:

// will not fall back to default
nodeProviderOpt, err := provider.DetectNodeProvider()
if errors.Is(err, provider.NoNodeProviderDetected) {
   // perform your own defaulting or fail, e.g. fallback to docker
   nodeProviderOpt = provider.WithDockerProvider()
} else if err != nil {
    // handle unknown error
}

// will still fall back to default regardless of detection for now if no explicit provider is supplied
provider := NewProvider(nodeProviderOpt, ...)

TODO: provider.WithDockerProvider() is kind of a terrible name, but also in the API now 🤦‍♂️

Will reconsider breaking things. We're not locked out of doing that yet, but I think this can provide more flexibility for embedders while not requiring re-implementation of provider detection and without deciding to break the APIs (which have been fairly stable for a few alpha release now) just yet.

Separately we're looking to go to beta and stop breaking stuff like this, so we should consider this more in the near future.