问题描述
我正在深入研究 kubernetes 架构，在所有本地/云 Kubernetes 集群中，主节点（也称为控制平面）需要是 Linux 内核，但我找不到原因？
解决方法
首先，我想说，从技术角度来看， 可以在 Windows 上运行控制平面。这是完全可行的，但是，没有人愿意将时间投入到比现有解决方案更糟糕的解决方案上，并且需要相当长的时间才能使这项工作发挥作用。如果你已经有了勺子，为什么还要用叉子喝汤？
现在人们可能会怀疑我是否在夸大其词。因此，我将尝试解释 Windows 在容器化方面存在的一些问题。为此，我必须先解释容器的工作原理：
如今，每当人们谈论容器时，他们都在谈论 Linux 容器（除非另有说明，否则我也将在此答案中这样做）。容器本质上使用 Linux 内核功能，最重要的是（但不限于）Linux namespaces。有许多不同的命名空间（PID、网络等）可用于“隔离”。例如，可以创建一个新的 PID 命名空间，为其分配一个进程，该进程只能将自己视为正在运行的进程（因为它是“隔离的”）。听起来很熟悉？好吧，如果您曾经在容器中执行过 ps aux，这就是将会发生的事情。
由于不可能在一篇文章中涵盖所有不同种类的 Linux 特性，这些特性对于容器工作至关重要，我希望现在很清楚“普通”容器本质上依赖于 Linux。
好吧，如果我说的是真的，容器如何在 Windows 上运行？
你猜怎么着……他们没有。 Windows 实际上在做的是在后台启动一个轻量级的 Linux 机器，然后托管容器。听起来很可笑？嗯，是的。 Here 是 Microsoft 文档中的一段：
但是，Windows 映像只能在 Windows 主机上运行，Linux 映像可以在 Linux 主机和 Windows 主机上运行（目前使用的是 Hyper-V Linux VM），其中主机是指服务器或 VM。
那么 Windows 容器（相对于 Linux 容器）呢？
Windows 容器确实通过使用 Windows 内核的功能在 Windows 上本地运行，类似于 Linux 容器。开发人员试图尽可能多地模仿 Linux 容器的行为，然而，由于 Windows 内核设计不佳，这根本不可能，必须使用许多技巧。可以想象，这个决定带来了很多问题，太多了，无法全部提及。仅提一提：Windows 容器比 Linux 容器大得多。 Window 容器实际达到 GB 大小是很常见的。 Even after making Windows Server Core images smaller by 40% back in 2019 内部图像仍然超过 1GB（未压缩甚至超过 2.5GB）。
考虑到所有这些开销，Linux 在容器化（以及许多其他方面）方面在各方面都非常出色，而且从来不需要 Windows 控制平面。
TL;DR
因为在容器化（以及许多其他方面）方面，Windows 是一个糟糕的操作系统。
,响应如此明确，因为自 2002 年以来的 Linux 附带的内核具有：
- 命名空间
- Cgroup
有关此技术的更多详细信息，请访问： namespace and cgroup
这两个在创建Linux容器之后使用，在Docker创建容器之后使用。
由于 k8s 是一个容器编排系统，因此它将基于 Linux 系统，因为它本身包含（命名空间和 cgroup）Linux 命令也很丰富，因为它有很多实用程序来管理文件、网络和其他.. ..
希望我的回答能说明为什么 k8s master 在 Linux 上运行。
,除了我们不费心在 Windows 上测试控制平面之外，并没有什么好的理由。从理论上讲，在 Windows 上应该可以正常编译的只是 Go 守护进程，但如果出现任何问题，您将自己解决。