No, it does not change a thing for you. Go back to coding, developing, configuring, monitoring, managing or whatever you where doing.
You may have heard that Kubernetes is deprecating Docker. This information came from the Kubernetes 1.20.0 changelog.
"Docker support in the kubelet is now deprecated and will be removed in a future release."
Woah! Kinda scary, right? Especially when people post that information without any explanations.
And you end up with people freaking out and relaying wrong information.
So much that Kubernetes published a deprecation FAQ and a Don't Panic blog posts trying to put a lid on the panic attack. To be honest, while these two blog posts make a good effort at trying to explain the situation, I think that the Microsoft's AKS documentation does a better job at explaining the changes simply because it uses two diagrams to illustrate that.
You see in the following diagram that the container runtime previously used was Moby.
What is Moby? Is a container runtime from Docker.
What the problem? It's not compliant with the Open Container Initiative so requires a translation layer, that's the Dockershim illustrated in blue, so that calls from the kubelet are carried correctly to the runtime.
Containerd is a container runtime that was created by, guess who? Docker, yep Docker! It was donated to the CNCF.
Why create another container runtime? Because Moby is not CRI compliant.
Why not make Moby compliant? It would be like transforming a bus into an F1 car. Possible, not worth the effort.
As you see in the next diagram, Moby is gone and so is the Dockershim. Removing the extra layer results in better performance.
But what will happen with the containers you built using Docker? They will run as is, period.
Do I have to change something? Nope.
Are you sure? Yep.
Prove it! If you're running Kubernetes 1.19.x in Azure Kubernetes Service, you're already running Docker containers on a cluster that does not have Moby installed. Have you heard of some panic attack coming from the Azure's customers? Nope.
What will not work
What? I just said that everything will work! Yes yes yes but there's a few things that will not work inside the cluster. These things, you're likely never did before and likely never do.
Have you ever ssh into a node so that you can run Docker commands directly on it before? If yes, you'll now have to use the CRICLT tool and not all Docker commands are supported.
From inside your cluster, have you ever deployed an app that talked directly to the Docker daemon using sockets? Likely no. You may have used a 3rd party tool that did that, but that tool was probably updated to communicate with containerd by now.
Building images inside a cluster using Docker-in-Docker (DinD) will no longer work. Example: if you have a CI/CD tool running inside a cluster, building images.
Not convinced yet?
Bret Fisher, a Docker captain, recorded a show explaining the whole situation with Docker's Justin Cormack. Bonus, you get the history of why Docker was first used in Kubernetes. Worth listening!
Docker's Sebastiaan van Stijn explanations on Twitter:
Here's a great Twitter thread by Kat Cosgrove:
Learn more about containerd with Phil Estes, IBM & Derek McGowan, Docker.
And finally, Lessons Learned Migrating Kubernetes from Docker to containerd Runtime with Ana Calin, Paybase
Hope this help! 😀
Learn Docker and Kubernetes
Like this blog post? I also teach Docker and Kubernetes at Kubernetes Academy Online.
Kubernetes Academy Online is Offering Self-Paced Online Video Training Courses with complete Hands-on Exercises. Available for AWS, Azure, DigitalOcean, Google Cloud Platform, and Linode. In English or French. Instructor-led Virtual Classes also available.
Courses info: KubernetesAcademy.online