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