Why do Kubernetes control-plane (master) nodes have to be Linux based (i.e. cannot be Windows)?

Question

Upon digging deeper into the Kubernetes architecture it seems that all Kubernetes clusters (both on-premises and cloud) must use Linux as their control-plane (a.k.a. master) nodes.

With that being said the following questions come to mind:

• How come this is the case?
• Why couldn't Windows be used as the control-plane?

Answer 1

First of all I want to say that from a technical perspective it would be possible to have a control plane running onto Windows. It is totally doable, however, no one wants to invest time into a solution which is worse than what already exist and it would take quite some time in order to make this work. Why eat soup with a fork if you already have a spoon?

Now one might wonder if I am exaggerating or not. So I'll try to explain some of the issues that Windows has when it comes to containerization. For that to happen I'll have to explain how containers work first:

Nowadays whenever people are talking about containers they are talking about Linux containers (which I am also going to do in this answer unless stated otherwise). Containers are essentially using Linux Kernel features, most importantly (but not limited to) Linux namespaces. There are many different namespaces (PID, Network, ...) that can be used for "isolation". As an example one can create a new PID namespace, assign it a process and that process will only be able to see itself as the running process (because it is "isolated"). Sounds familiar? Well, if you ever executed ps aux in a container this is what is going to happen. Since it is not possible to cover all the different kinds of Linux features that are essential in order for containers to work in a single post, I hope that by now it is clear that "normal" containers are essentially dependent on Linux.

Okay, so if what I am saying is true, how can containers work on Windows at all?

Guess what...they don't. What Windows is actually doing is spinning up a lightweight Linux machine in the background which then hosts containers. Sounds ridiculous? Well, it is. Here is a passage out of Microsoft's documentation:

However, Windows images can run only on Windows hosts and Linux images can run on Linux hosts and Windows hosts (using a Hyper-V Linux VM, so far), where host means a server or a VM.

So what about Windows containers then (as opposed to Linux containers)?

Windows containers do run natively on Windows by using features of the Windows kernel, similar as Linux containers do. Developers tried to mimic the behavior of Linux containers as much as possible, however, due to poor design of the Windows kernel this simply is not possible and many hacks had to be used. As one can imagine, many issues come with that decision, too many to actually mention them all. Just to mention one: Windows containers are way bigger than Linux containers. It is very common for Window containers to actually reach gigabyte sizes. Even after making Windows Server Core images smaller by 40% back in 2019 the insider image was still over 1GB (uncompressed even over 2.5GB).

With all that overhead in mind, Linux simply is superior in every way when it comes to containerization (and many other things as well) and there has never been a need to have a Windows control plane.

TL;DR

Because Windows is a poor operating system when it comes to containerization (and many other things).