Docker-ulimit容器和主机之间的差异

我认为，

docker

容器与主机共享这些属性。但是，在一台

docker

主机上，有以下

ulimit

设置：

ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 63399
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 63399
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

但在一个容器中，可以得到：

ulimit -a
-f: file size (blocks)             unlimited
-t: cpu time (seconds)             unlimited
-d: data seg size (kb)             unlimited
-s: stack size (kb)                8192
-c: core file size (blocks)        unlimited
-m: resident set size (kb)         unlimited
-l: locked memory (kb)             64
-p: processes                      unlimited
-n: file descriptors               65536
-v: address space (kb)             unlimited
-w: locks                          unlimited
-e: scheduling priority            0
-r: real-time priority             0

---

具体地看一下

-n

设置，容器是否因为主机的限制而被限制为1024个打开的文件？任何人都可以解释一下容器中的

ulimit

与底层

docker

主机中的

ulimit

的含义之间的区别吗？

资源限制可以由docker在容器启动期间设置，您可以在启动容器时使用

--ulimit

参数调整这些设置。在容器启动过程中，可以通过

strace

调用

containerd

过程来轻松验证，例如，以下命令

$ docker run -it --ulimit nofile=1024 alpine

将生成以下跟踪：

prlimit64(7246, RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=1024},  <unfinished ...>

在未明确指定

--ulimit

的情况下运行容器时，此检查会给出不同的值（可能继承自

containerd

），例如：

为什么Docker可以通过检查主机上的

ulimit

设置比您观察到的更高的限制？让我们打开

man 2 prlimit

：

A privileged process (under Linux: one with the CAP_SYS_RESOURCE capability
in the initial user namespace) may make arbitrary changes to either limit value.

这意味着任何具有

CAP\u SYS\u RESOURCE

功能的进程都可以设置任何资源限制，Docker具有此功能。您可以通过检查

/proc/$PID/status

文件的

CapEff

字段来检查它，其中

$PID

是

containerd

过程的PID，并使用

capsh--decode>对该值进行解码：

$ pidof docker-containerd
675
$ cat /proc/675/status | grep CapEff
CapEff: 0000003fffffffff
$ capsh --decode=0000003fffffffff
0x0000003fffffffff=cap_chown,<...>,cap_sys_resource,<...>

$pidocker集装箱码头
675
$cat/proc/675/status | grep CapEff
资本支出：0000003fffffff
$capsh--decode=0000003fffffff
0x0000003fffffffff=cap\u chown，，cap\u sys\u资源，

总结：是的，Docker可能会增加容器的资源限制，因为它有这样做的特权，您可以使用
--ulimit
参数调整这些限制。
Docker守护程序ulimit设置是从init继承的（可能是systemd），而ulimit cli将对应用的用户进行限制。除非覆盖默认值，否则守护程序限制将传递给容器。
A privileged process (under Linux: one with the CAP_SYS_RESOURCE capability
in the initial user namespace) may make arbitrary changes to either limit value.

$ pidof docker-containerd
675
$ cat /proc/675/status | grep CapEff
CapEff: 0000003fffffffff
$ capsh --decode=0000003fffffffff
0x0000003fffffffff=cap_chown,<...>,cap_sys_resource,<...>