Docker主机中的Ulimits与容器中的Ulimits

Question

我发现对于这个问题没有一个直接的答案，但是下面是解释：

假设我有一个主机，它的最大打开文件数为1024：

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

在该主机上运行一个Docker容器，并包含以下内容：

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

如果我尝试打开超过1024个文件，那么在容器中会有什么问题吗？我认为在这种情况下容器的真正限制将是1024个文件。你认为呢？

- os11k

---

此线程提供了很好的解释：https://dev59.com/h6_la4cB1Zd3GeqPvp_U - gnan r

Answer 1

虽然有点晚了，但我只想澄清一下关于ulimit差异的疑惑。

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

这是因为在主机上运行命令时，它显示的是其软限制。另一方面，容器显示的值是主机操作系统的硬限制。造成这种情况的原因是您可以越过软限制。因此，在某种意义上，硬限制实际上是真正的限制。您可以在此链接中了解更多关于ulimit的信息。

要查看硬限制，请键入以下命令

ulimit -Hn

你将会看到这些值是匹配的。

注意：您不能越过硬限制，但如果您是root用户，则可以将其增加。

在Docker配置中可以使用LimitNOFILE设置打开文件的限制，或者可以将它们传递给docker run命令：

$ docker run -it --ulimit nofile=1024:2048 ubuntu bash -c 'ulimit -Hn && ulimit -Sn'
2048
1024

有关在Docker中设置ulimits的详细信息，请参见此处。

请注意，此限制可以设置得比操作系统的硬限制更高，这可能会引起麻烦。

- Alim Ul Gias

Answer 2

真正的限制将是1048576。

看一下图片右侧的部分，它显示容器基本上只是在同一操作系统上运行的隔离进程:

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

例如，ulimits的差异可能是由Docker配置引起的。

（请注意，对于虚拟机，情况将会有所不同：客户操作系统可能显示1048576的值，但最终打开的调用将由主机操作系统处理，该操作系统将施加1024的限制）

- user3151902

Answer 3

我需要直接回答原帖问题：

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

不会。在这种情况下，我发现主机值在容器内没有影响，Docker容器可以指定自己的ulimit值。

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

- Mitch