例如，如果一个Linux操作系统将ulimit nofile设置为1024（软）和硬（4096），并且我使用----ulimit nofile=10240:40960运行docker，那么容器可以使用比它的主机更多的nofile吗？

• Docker在其权限上设置了CAP_SYS_RESOURCE功能。这意味着Docker可以设置与主机不同的ulimit。根据man 2 prlimit：

特权进程（在Linux下：在初始用户名称空间中具有CAP_RESOURCE能力的用户）可以对任一限制值进行任意改变。

• 因此，对于容器，要考虑的限制是由docker守护进程设置的限制。你可以使用这个命令检查docker daemon的限制：

$ cat /proc/$(ps -A | grep dockerd | awk '{print $1}')/limits | grep "files"
Max open files            1048576              1048576              files

• 正如你所看到的，Docker 19有一个相当高的1048576限制，所以你的40960**将像一个魅力一样工作。
• 如果你运行一个docker容器，将--ulimit设置为高于节点但低于守护进程本身，你不会发现任何问题，也不需要像下面的例子那样给予额外的权限：

$ cat /proc/$(ps -A | grep dockerd | awk '{print $1}')/limits | grep "files"
Max open files            1048576              1048576              files     

$ docker run -d -it --rm --ulimit nofile=99999:99999 python python;
354de39a75533c7c6e31a1773a85a76e393ba328bfb623069d57c38b42937d03

$ cat /proc/$(ps -A | grep python | awk '{print $1}')/limits | grep "files"
Max open files            99999                99999                files

• 您可以在/etc/init.d/docker文件上设置dockerd的新限制：

$ cat /etc/init.d/docker | grep ulimit
                ulimit -n 1048576

• 至于容器本身具有比docker守护进程更高的ulimit，这有点棘手，但可行，参考这里。
• 我看到你已经标记了Kubernetes标签，但没有在你的问题中提到它，但为了使它在Kubernetes上工作，容器将需要securityContext.priviledged: true，这样你就可以在容器内以root身份运行命令ulimit，这里有一个例子：

image: image-name
  command: ["sh", "-c", "ulimit -n 65536"]
  securityContext:
    privileged: true