[Kubernetes] Docker vs container-d

1 minute read

Previously k8s only supported docker, but as other container runtimes(e.g. rkt) wanted k8s
k8s introduced CRI(Container Runtime Interface) which allowed any vendor to work as a container runtime as long as they adhere to OCI(Open Container Initiative) standard
- OCI consists of image-spec(how an image should be built) and runtime spec(how a container runtime should be developed)
Docker didn’t follow the CRI standards since it was built before k8s and it was the dominant container tool
k8s had to support docker therefore k8s introduced dockershim, a temporal way to support docker
the container runtime of Docker was runC, and the daemon that managed the runC is container-d
container-d is CLI compatible and can work directly with k8s as other runtimes
as of version 1.24 of k8s, support of dockershim was removed, and therefore docker itself was removed as a supported runtime of k8s
- the image built with docker still follow the OCI standard, so the image can be used

Although a part of Docker, it container-d is a separate project on its own
container-d has ctr, a cli tool but not user friendly, and supports only limited features
As an alternative, nerdctl provides a docker-like cli for container-d
crictl is a command line utility used to interact with the CRI compatible container, this is used mostly for debugging purposes
- crictl by default it tries to connect to the sockets in the order below
  - unix:///var/run/dockershim.sock
  - unix:///var/run/containerd.sock
  - unix:///run/crio/crio.sock
  - unix:///var/run/cri-dockerd.sock
- to override and set a specific endpoint, use crictl --runtime-endpoint or set export CONTAINER_RUNTIME_ENDPOINT

[Kubernetes] Kubernetes Architecture