Question

我无法找到这个问题的直接答案，但现在是：

假设我有一个拥有最大打开文件1024的主机：

[root@host]# ulimit -a
open files                      (-n) 1024

以及在该主机中运行的docker容器：

[root@container]# ulimit -a
open files                      (-n) 1048576

如果我尝试打开超过1024个文件，那么我在容器中会遇到问题吗？我认为在这种情况下容器的实际限制将是1024个文件。你觉得怎么样？

Answer 1

真正的限制是1048576。

查看此图像的右侧部分，该部分显示容器基本上只是隔离的进程，在同一操作系统上运行：

由于容器中的每个系统调用都将由主机OS直接处理，因此显示的ulimit（1048576）直接来自主机操作系统，这是将要使用的值。

例如，a Docker configuration可能导致ulimits的差异。

（请注意，对于 VMs ，这将有所不同：来宾操作系统可能会显示值1048576，但是开放调用最终将由主机操作系统处理，这将强制执行限制1024）

Answer 2

虽然有点晚了，但我只是想澄清对ulimit差异的疑虑。

如果在运行容器时进行net设置，则容器中显示的ulimit值来自主机操作系统。问题是，为什么从主机运行相同的命令时会看到不同的值？

这是因为在主机中运行命令时，它显示其软限制。另一方面，容器显示的值是主机OS的硬限制。原因是您可以越过软限制。所以从某种意义上说，硬限制实际上是真正的限制。您可以在此link中找到有关ulimit的更多信息。

要查看硬限制，只需输入以下命令

即可

ulimit -Hn

您会看到值匹配。

N.B。您无法越过硬限制，但如果您是根，则可以增加它。

Answer 3

我需要直接回答OP的问题：

如果我尝试打开超过1024个文件，那么我在容器中会有问题吗？

不。在这种情况下，我发现主机值在容器内部无效，并且Docker容器可以指定自己的ulimit值。

换句话说，对于您的容器，将其设置为比主机的默认值高的值是有效的。因此，容器中的有效ulimit nofile值为1048576，可以正常工作。