为什么 Kubernetes 控制平面（masters）必须是 linux？
Why Kubernetes control planes (masters) must be linux?
我正在深入研究 kubernetes 架构，在所有 Kubernetes 集群中 on-premises/Cloud 主节点 a.k.a 控制平面需要 Linux 内核，但我找不到为什么？
除了我们不想在 Windows 上测试控制平面外，没有什么好的理由。从理论上讲，这只是 Go 守护进程，应该可以在 Windows 上正常编译，但如果出现任何问题，您将自己解决。
首先我想说的是，从技术角度来看， 可以将控制平面 运行 连接到 Windows。这是完全可行的，但是，没有人愿意将时间投入到比现有解决方案更糟糕的解决方案上，并且需要相当长的时间才能完成这项工作。既然有勺子，为什么还要用叉子喝汤？
现在有人可能怀疑我是不是在夸大其词。因此，我将尝试解释 Windows 在容器化方面遇到的一些问题。为此，我必须先解释 容器的工作原理：
如今，每当人们谈论容器时，他们都是在谈论 Linux 容器（除非另有说明，否则我也会在本回答中这样做）。容器本质上使用 Linux 内核功能，最重要的是（但不限于）Linux namespaces。有许多不同的名称空间（PID、网络等）可用于“隔离”。例如，可以创建一个新的 PID 命名空间，为其分配一个进程，该进程将只能将自己视为 运行ning 进程（因为它是“孤立的”）。听起来很熟悉？好吧，如果您曾经在容器中执行过 ps aux，这就是将要发生的事情。
由于不可能涵盖容器在单个 post 中工作所必需的所有不同类型的 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控制平面。
TL;DR
因为 Windows 在容器化（以及许多其他方面）方面是一个糟糕的操作系统。
响应非常明确，因为 Linux 自 2002 年以来就带有内核：
- 命名空间
- C组
有关此技术的更多详细信息，请访问：
namespace and cgroup
这两个在创建 Linux 容器之后使用，并在 Docker 使用之后创建容器。
并且由于 k8s 是一个容器编排系统，所以它将基于 Linux 系统，因为它本身包含（命名空间和 cgroup），而且 Linux 命令很丰富，因为它有很多用于管理文件、网络和其他内容的实用程序....
我希望我的回复能澄清为什么 k8s master 运行 在 Linux 上。
我正在深入研究 kubernetes 架构，在所有 Kubernetes 集群中 on-premises/Cloud 主节点 a.k.a 控制平面需要 Linux 内核，但我找不到为什么？
除了我们不想在 Windows 上测试控制平面外，没有什么好的理由。从理论上讲，这只是 Go 守护进程，应该可以在 Windows 上正常编译，但如果出现任何问题，您将自己解决。
首先我想说的是，从技术角度来看， 可以将控制平面 运行 连接到 Windows。这是完全可行的，但是，没有人愿意将时间投入到比现有解决方案更糟糕的解决方案上，并且需要相当长的时间才能完成这项工作。既然有勺子，为什么还要用叉子喝汤？
现在有人可能怀疑我是不是在夸大其词。因此，我将尝试解释 Windows 在容器化方面遇到的一些问题。为此，我必须先解释 容器的工作原理：
如今，每当人们谈论容器时，他们都是在谈论 Linux 容器（除非另有说明，否则我也会在本回答中这样做）。容器本质上使用 Linux 内核功能，最重要的是（但不限于）Linux namespaces。有许多不同的名称空间（PID、网络等）可用于“隔离”。例如，可以创建一个新的 PID 命名空间，为其分配一个进程，该进程将只能将自己视为 运行ning 进程（因为它是“孤立的”）。听起来很熟悉？好吧，如果您曾经在容器中执行过 ps aux，这就是将要发生的事情。
由于不可能涵盖容器在单个 post 中工作所必需的所有不同类型的 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控制平面。
TL;DR
因为 Windows 在容器化（以及许多其他方面）方面是一个糟糕的操作系统。
响应非常明确，因为 Linux 自 2002 年以来就带有内核：
- 命名空间
- C组
有关此技术的更多详细信息，请访问： namespace and cgroup
这两个在创建 Linux 容器之后使用，并在 Docker 使用之后创建容器。
并且由于 k8s 是一个容器编排系统，所以它将基于 Linux 系统，因为它本身包含（命名空间和 cgroup），而且 Linux 命令很丰富，因为它有很多用于管理文件、网络和其他内容的实用程序....
我希望我的回复能澄清为什么 k8s master 运行 在 Linux 上。