与容器和 Docker 层表示混淆
Confused with Containers & Docker Layer Representation
这是在 Docker 层之上显示容器 运行 的流行表示，而后者又 运行 在主机操作系统（内核） 上
但我在这篇文章中读到容器本质上 运行 在内核而不是 docker。
http://crunchtools.com/containers-dont-run-on-docker/
我现在很困惑哪个表示是正确的表示。要启动停止容器，我们当然需要 Docker 或容器引擎，但一旦启动，它就会 运行 在 Linux 内核上。我倾向于同意第二种表示。请对这方面有所了解。
正确的表示是第二个
容器范式基于同一概念的特定 OS 实现：Linux 使用 User Namespaces, Windows uses Hyper-V，依此类推...以上技术允许您创建容器在进程隔离方面，它就像一个 OS 独立实例。
Docker、LXC 以及任何其他的，就像允许用户通过 API 或 CLI.
容器相对于虚拟机的一个主要优势是容器通常被描述为“轻量级”。
容器通过不启动完全独立的环境来实现这一点，而是使用主机的环境——即内核。这是通过进程隔离实现的（通过 linux namespaces, dating back to 2002) and separate resource limitation (through cgroups，可追溯到 2007 年）。我们甚至可以通过在主机上启动一个容器来使其可见，并且在容器 运行ning 时列出主机上的所有进程（例如通过 ps aux）。我们将看到容器中的进程。如果我们有权限，我们甚至可以杀死那些进程（如果我们杀死正确的进程，即入口点）从而杀死容器。
有一个 nice talk from Liz Rice on youtube 他们解释并展示了如何通过系统内核调用构建基本容器（他们在演示中使用 golang，但我们可以重写所有这些调用直接内核调用，例如，如果我们愿意，可以将它们烘焙到 .sh 脚本中）。
如果我们将编程与编程相提并论，我们可以说 docker API 是现有功能的外观。我会说第二张图片更接近我所描述的内容。
如果我们的 docker-host 是一个非 linux 基础的系统（MacOS，Windows），那么我们需要一种方法来为 base-host 提供内核容器运行时间。对于 windows，我们可以通过 Hyper-V or WSL2. For MacOS, the hypervisor.framework 用于 运行 一个 linux 虚拟机来实现。在这种情况下，第一张和第二张图片的组合最能描述设置。
我认为这两个图在某种程度上都是正确的。然而，他们对同一个问题给出了不同的鸟瞰视角。
有如此高层次的图表，确实很难判断究竟是什么在运行一个容器。更接近真实的分解实际上看起来如下：
请注意，在上图中，每个方框代表主机上的一个常规 Linux 进程。因此，dockerd、containerd 和容器本身在这方面没有什么不同。容器实际上是常规的 Linux 进程。他们只是比其他人稍微更孤立和受限制。
容器与其他进程的不同之处在于 Docker（通过其子组件）将这些进程放入虚拟化沙箱中。从内部看，这些框看起来像是这些进程的 OS 的专用实例。而这正是内核发挥关键作用的地方——它提供了所有 OS 级别的虚拟化能力（例如命名空间、虚拟网络设备等）来创建这样的盒子。或者监狱，如果你愿意的话。
您可以在本系列文章中找到有关容器管理器、运行时和垫片的更多技术细节：
这是在 Docker 层之上显示容器 运行 的流行表示，而后者又 运行 在主机操作系统（内核）
但我在这篇文章中读到容器本质上 运行 在内核而不是 docker。
http://crunchtools.com/containers-dont-run-on-docker/
我现在很困惑哪个表示是正确的表示。要启动停止容器，我们当然需要 Docker 或容器引擎，但一旦启动，它就会 运行 在 Linux 内核上。我倾向于同意第二种表示。请对这方面有所了解。
正确的表示是第二个
容器范式基于同一概念的特定 OS 实现：Linux 使用 User Namespaces, Windows uses Hyper-V，依此类推...以上技术允许您创建容器在进程隔离方面，它就像一个 OS 独立实例。
Docker、LXC 以及任何其他的，就像允许用户通过 API 或 CLI.
容器相对于虚拟机的一个主要优势是容器通常被描述为“轻量级”。
容器通过不启动完全独立的环境来实现这一点，而是使用主机的环境——即内核。这是通过进程隔离实现的（通过 linux namespaces, dating back to 2002) and separate resource limitation (through cgroups，可追溯到 2007 年）。我们甚至可以通过在主机上启动一个容器来使其可见，并且在容器 运行ning 时列出主机上的所有进程（例如通过 ps aux）。我们将看到容器中的进程。如果我们有权限，我们甚至可以杀死那些进程（如果我们杀死正确的进程，即入口点）从而杀死容器。
有一个 nice talk from Liz Rice on youtube 他们解释并展示了如何通过系统内核调用构建基本容器（他们在演示中使用 golang，但我们可以重写所有这些调用直接内核调用，例如，如果我们愿意，可以将它们烘焙到 .sh 脚本中）。
如果我们将编程与编程相提并论，我们可以说 docker API 是现有功能的外观。我会说第二张图片更接近我所描述的内容。
如果我们的 docker-host 是一个非 linux 基础的系统（MacOS，Windows），那么我们需要一种方法来为 base-host 提供内核容器运行时间。对于 windows，我们可以通过 Hyper-V or WSL2. For MacOS, the hypervisor.framework 用于 运行 一个 linux 虚拟机来实现。在这种情况下，第一张和第二张图片的组合最能描述设置。
我认为这两个图在某种程度上都是正确的。然而，他们对同一个问题给出了不同的鸟瞰视角。
有如此高层次的图表，确实很难判断究竟是什么在运行一个容器。更接近真实的分解实际上看起来如下：
请注意，在上图中，每个方框代表主机上的一个常规 Linux 进程。因此，dockerd、containerd 和容器本身在这方面没有什么不同。容器实际上是常规的 Linux 进程。他们只是比其他人稍微更孤立和受限制。
容器与其他进程的不同之处在于 Docker（通过其子组件）将这些进程放入虚拟化沙箱中。从内部看，这些框看起来像是这些进程的 OS 的专用实例。而这正是内核发挥关键作用的地方——它提供了所有 OS 级别的虚拟化能力（例如命名空间、虚拟网络设备等）来创建这样的盒子。或者监狱，如果你愿意的话。
您可以在本系列文章中找到有关容器管理器、运行时和垫片的更多技术细节：