请教一个 Docker 和 Host 环境交互关联的问题(POD 挂载/dev 与 OOM）

[DigitalG]

我公司目前的有个开发者用的 k8s 集群（用处：开发者申请资源创建一些自定义数据处理任务在上面执行）。为了获取一些 host 上的硬件信息，运维让这个集群上的 POD ，都默认挂载了 host 的 /dev 目录。最直观上，这会使得一些工具(top/free 等)显示的内容和实际 POD 拥有的资源存在差异（比如 pod 拥有 10GB 内存，但 top 显示的是 Host 全部的 256GB 内存）。

我总怀疑一些任务经常 OOM 是不是跟这些有关（可能会被系统杀掉的条件会变？我们运维是觉得这么做没什么问题）。但我自己对 k8s 不是特别了解，网上没有搜索到这么做的例子，不太清楚从哪个方向去查。有没有有经验的同学知道这么做有什么问题吗？或者能指一下可能相关的资料我去差一下。

[Cola98]

pod 应该不是一口气获取到这么多资源的吧？

[DigitalG]

@Cola98 你是指哪个过程呀？ pod 实际还是分配到的那小部分资源，但 /dev 不是 linux 的设备目录么，由于 pod 挂载了 Host 的 /dev 目录，导致 pod 内的各种和设备交互的命令显示的都是 host 的信息。我有些怀疑这会导致 pod 里的系统资源调度出现问题

[suixn]

oom 是用 container_memory_working_set_bytes 判断的。可以观察下这个指标。
另外，pod 内看到 host 的 cpu,内存资源是正常的。

[DigitalG]

@suixn 这样啊，谢谢，是我太不了解了。奇怪运维跟我说是因为挂载了 dev 才这样

[Cola98]

@DigitalG 这个就不清楚了，之前怀疑是 Pod 的原因

[NoirStrike]

看你的应用能不能识别到限制,
设置了 limit, 但应用不知道, 按宿主机的规格去用资源 OOM 很正常咯

[julyclyde]

你指的其实是 /proc 吧？

lxcfs 可以处理这个问题

[DigitalG]

@julyclyde 哦对对，是挂载了 /proc ，我说错了...