我正在深入挖掘 kubernetes 架构，在所有本地/云 Kubernetes 集群中，主节点 a.k.a 控制平面需要是 Linux 内核，但我找不到为什么？
最佳答案
首先，我想说的是，从技术角度来看， 可以在 Windows 上运行控制平面。这是完全可行的，但是，没有人愿意将时间投入到比现有解决方案更糟糕的解决方案上，并且需要相当长的时间才能完成这项工作。既然已经有了勺子，为什么还要用 fork 喝汤？
现在有人可能怀疑我是不是在夸大其词。因此，我将尝试解释 Windows 在容器化方面存在的一些问题。为此，我必须先解释容器的工作原理:
如今，每当人们谈论容器时，他们都是在谈论 Linux 容器(除非另有说明，否则我也将在本回答中这样做)。容器本质上是在使用 Linux 内核功能，最重要的是(但不限于)Linux namespaces .有许多不同的 namespace (PID、网络等)可用于“隔离”。例如，可以创建一个新的 PID namespace ，为其分配一个进程，该进程将只能将自己视为正在运行的进程(因为它是“孤立的”)。听起来很熟悉？好吧，如果您曾经在容器中执行过 ps aux，就会发生这种情况。
由于不可能在一篇文章中涵盖容器运行所必需的所有不同类型的 Linux 功能，我希望到现在为止，“普通”容器本质上依赖于 Linux 已经很清楚了。
好吧，如果我说的是真的，容器如何在 Windows 上运行？
你猜怎么着……他们没有。 Windows 实际上在做的是在后台启动一个轻量级的 Linux 机器，然后托管容器。听起来很荒谬？好吧，是的。 Here是微软文档中的一段话:
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.
那么 Windows 容器又如何(与 Linux 容器相反)？
Windows 容器通过使用 Windows 内核的功能在 Windows 上本地运行，类似于 Linux 容器。开发人员试图尽可能多地模仿 Linux 容器的行为，但是，由于 Windows 内核的设计不佳，这根本不可能，因此不得不使用许多 hack。可以想象，这一决定带来了很多问题，实际上无法一一列举。仅举一个:Windows 容器比 Linux 容器大得多。 Window 容器实际上达到千兆字节大小是很常见的。 Even after making Windows Server Core images smaller by 40% back in 2019内部图像仍然超过 1GB(未压缩甚至超过 2.5GB)。
考虑到所有这些开销，Linux 在容器化(以及许多其他方面)方面在各个方面都更胜一筹，而且从来不需要 Windows 控制平面。
长话短说
因为在容器化(以及许多其他方面)方面，Windows 是一个糟糕的操作系统。
关于kubernetes - 为什么 Kubernetes 控制平面(masters)必须是 linux？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/67961188/