一个容易忽略的容器稳定性小问题：文件描述符

在 Kubernetes 里，文件描述符往往不在最显眼的资源清单里，但它既会限制进程，也会逐步侵蚀宿主机的公共容量。

记于 2026-03-20 更新于 2026-03-20

在 Kubernetes 里，大家平时更关注 CPU、内存这类资源；但文件描述符其实也会影响节点稳定性。

RLIMIT_NOFILE 是进程级限制，分软限制和硬限制：软限制是内核实际执行的值，硬限制决定软限制最多能抬到哪里。与此同时，Linux 还有系统级的 open files 上限，例如 /proc/sys/fs/file-max。所以某个容器如果持续泄露文件描述符，问题不一定只停留在 Pod 内，也可能逐步侵蚀宿主机的公共容量。

这件事容易被忽略，是因为 Kubernetes 原生最成熟的资源声明和配额模型，主要围绕 cpu、memory、ephemeral-storage 等资源展开，LimitRange 也主要约束这些字段；文件描述符并不是一个常见的原生 Pod 资源字段。于是在线上高密度、多 Pod 的场景里，FD 问题往往更像节点稳定性问题，而不只是单个应用自己的小故障。

一个很常见的触发方式是：不少服务在启动时会主动调高 nofile 软限制来自保。单机时代这通常没什么问题；但到了多租户或高密度部署场景，局部优化就可能变成对宿主机共享资源的持续挤压。

我会把它记成一个小提醒：容器的边界，不等于宿主机公共资源的边界。