This post has been republished via RSS; it originally appeared at: Containers articles.
You may have heard that the Kubernetes v1.20 release deprecated dockershim. Our friends in the community published a DON’T PANIC blog that does a great job of clarifying, since a lot of people kind of freaked out.
This didn’t quite do the trick, so they wrote a FAQ too. Still, the message hasn’t landed everywhere it needs to. And none of these publications address the specialness that is Windows head-on. So, we felt we need to share what this means to you as a user of Windows Server containers in Kubernetes (K8s). As dockershim slowly exits Kubernetes, building containers is no different. For both Windows and Linux, containers built with different toolsets can be run with different runtimes. This is no different for Kubernetes. Containers built with Docker will run without modification in Kubernetes with containerd. Microsoft contributes to containerd to ensure that running those containers on Windows takes advantage of the latest and greatest the platform has to offer. For fun, we thought we’d share some of the myths about what all this means for Windows containers and bust (dispel) them for you.
Myth – the K8s docker shim deprecation will break my Windows container builds for Kubernetes!
Busted – Docker Desktop for Windows will continue to build containers! That is what Docker makes it to do! Kubernetes can run those containers using containerd. (The small print: if your containers depend on Docker sockets (aka docker in docker), you’re out of luck.)
Myth – Docker Desktop for Windows uses containerd already!
Busted – Docker Desktop for Windows uses Docker Engine which is built on moby. Moby, as of this writing, partially depends on containerd. There is ongoing work to adapt moby to use more of containerd on Windows.
Myth – All of my Docker CLIs I depend on my local machine for build process are broken!
Busted – Docker CLIs on your dev box are not being affected, and you may continue to use them to build container images. All this works thanks to the way Docker, containerd, and other tools conform to the Open Container Initiative (OCI) – a set of standards which help ensure tools used to build, publish, and run containers all interoperate together.
Myth – If I upgrade my Azure Kubernetes Service (AKS) cluster to Kubernetes v1.24 (when dockershim is currently planned for removal from kubelet) my Windows containers won’t run!
Busted – Your upgrade will deploy the new containerd runtime on the Windows nodes. But the containers will run just fine.
Myth - I must rebuild all my containers and K8s clusters to use containerd!
Busted – The containerd change is only on the host runtime. Container images build with Docker and other tools that are OCI compliant do not require you to rebuild. You can still use the same container image to run with Kubernetes and containerd. If you are using AKS, all you need to do is deploy your workload on a host which has containerd runtime. For more detail read the Don’t Panic blog.
Myth – I’m running my own DIY (do it yourself - unmanaged) K8s cluster and not using a distro and removing dockershim will break me!
Busted – The K8s community has tested the containerd container runtime for both Linux and Windows to ensure that containers that work with the Docker Engine runtime work with the containerd. Before the should replace your docker runtime on both Windows Server nodes and Linux nodes with containerd. You can find instructions on how to configure runtimes in the community documentation.
Myth – My air-gapped Kubernetes cluster will break with the move to containerd!
Busted – Air-gapped k8s operation still requires your container images to be available to the Windows host in the same way, either from a local container registry, or baked into the OS image’s local containerd image store. This is no different whether you are using dockershim or not.
Finally, a note for customers looking into adopting AKS-HCI: The current preview release uses dockershim as the runtime on Windows. Containerd will be the default runtime in a future release and just like AKS, customers can expect a smooth transition – along with documented instructions on how to upgrade.
As a part of the Kubernetes community, we are working to make sure you are covered. Docker and other tools that build OCI containers will work with the containerd runtime in Kubernetes. These topics, and more, are covered in the Kubernetes Special Interest Group for Windows (SIG Windows) where all are welcome. Please reach out to us if you have questions or feedback.