This change for the Docker runtime has been coming for some time now. Developers just need to change their container runtime from Docker to a supported container runtime.

'If it were, we wouldn't need the shim, and this wouldn't be a thing.' But it's not the end of the world. In addition, Docker isn't compliant with CRI. The rest is only so much unneeded and unwelcome code, which opens a bigger attack surface and requires maintenance. Dockershim's job is to extract only the runtime. Docker is a popular choice for that runtime, but Docker was not designed to be embedded inside Kubernetes, and that causes problems.Īs the programmers observed, 'The thing we call 'Docker' isn't actually one thing - it's an entire tech stack.' Docker includes many user enhancements for programmers, but Kubernetes doesn't need any of that. Inside your Kubernetes cluster, the container runtime's job is pulling and running your container images. Part of the confusion stems from people using 'Docker' to mean a great many different things. In short, it's not - I repeat - not a big deal. Docker-produced images will continue to work in your cluster just as they always have.

All that's happened is Docker as an underlying runtime is being deprecated in favor of CRI runtimes. You can still build containers, use them in registries, and push and pull. As the developers explained in their well-named ' Don't Panic: Kubernetes and Docker' blog post, all that's happening is that Kubernetes is deprecating Docker as a container runtime after v1.20.

What is kubernetes docker