PID（进程标识符）是操作系统分配给每个进程的唯一编号，系统可分配的PID总量是有限的。fork炸弹正是利用这一点，通过一行代码不断复制自身进程，在极短时间内把PID耗尽，最终让正常服务无法启动新进程。裸机上防御fork炸弹往往需要依赖ulimit或系统级配置，而容器环境下有一个更精准的武器：PID cgroup控制器。它可以把进程数量限制作用在单个容器的命名空间内，即使容器内被引爆fork炸弹，宿主机和其他容器也不受影响。
一、fork炸弹的原理与危害
最经典的fork炸弹是bash写法，只有十来个字符：
:(){ :|:& };:
这段代码定义了一个名为:的函数，函数体是:|:&，即调用自己两次，并通过管道连接、放到后台执行。最后的;结束函数定义，:触发第一次调用。从此开始进程数呈指数级增长：1个变2个，2个变4个，几秒内就能创建数万个进程。
进程爆炸带来的后果是PID表被占满、内存被榨干、CPU调度完全被打乱。此时管理员连一个kill命令都可能执行失败，因为执行命令本身也需要fork新进程。在传统裸机环境下，通常靠修改/etc/security/limits.conf设置nproc上限，或者调整内核参数kernel.pid_max，但这些方案粒度太粗，只能全局生效，无法针对单个服务做隔离。
二、cgroup的pids控制器如何工作
现代Linux内核的cgroup提供了一个专门的pids控制器，它统计的是该cgroup层级内所有进程与线程的总数。当容器尝试创建新进程时，内核会在fork系统调用路径上检查当前cgroup的进程计数，一旦达到上限，fork就会失败并返回错误，子进程根本不会被创建出来。这意味着防线设在内核层面，用户空间无法绕过。
这个机制依赖两个关键条件：一是容器必须使用独立的PID命名空间，这样容器内的主进程才有自己的PID体系；二是容器运行时（如Docker、containerd）需要正确挂载pids控制器。可以查看宿主机的cgroup文件确认：
# 查看某个容器cgroup下的PID限制文件 cat /sys/fs/cgroup/pids/docker/<container_id>/pids.max cat /sys/fs/cgroup/pids/docker/<container_id>/pids.current
pids.max是上限值，pids.current是当前计数。值得一提的是，pids控制器统计的是任务数（含线程），所以一个多线程应用即使进程不多，线程数也会计入总额，配置时要把线程开销考虑进去。
三、Docker与Kubernetes中的配置方法
Docker提供了--pids-limit参数，使用非常直接。启动容器时加上参数即可，例如限制为200个进程：
docker run -d --name myapp --pids-limit=200 nginx:latest # 进入容器验证，尝试超过限制 docker exec myapp bash -c 'for i in $(seq 1 500); do sleep 100 & done; jobs | wc -l'
当进程数逼近200时，后续的fork会收到Resource temporarily unavailable错误（errno为EAGAIN），但已运行的进程不受影响。这个行为非常理想：攻击被截断，正常业务进程继续存活。
在Kubernetes中，对应的能力通过Pod的resources.limits字段暴露，字段名为pids，例如：
apiVersion: v1
kind: Pod
metadata:
name: demo-pod
spec:
containers:
- name: app
image: nginx:latest
resources:
limits:
memory: "512Mi"
cpu: "500m"
pids: "200"
注意pids的值必须写成字符串形式。另外，Kubelet还支持--pod-max-pids级别的节点级兜底配置，防止某些未声明限制的Pod失控。如果使用Docker作为K8s的运行时，也可以在daemon.json中设置"default-pids-limit"为所有容器设置默认值，做到全局兜底。
四、上限取值建议与常见误区
设置PID上限不是越小越安全。取值太小会误伤正常应用，尤其是Java这类依赖大量线程的运行时，一个Tomcat实例轻松就有两三百个线程，如果上限设为100，服务启动阶段就会莫名失败，而且报错往往藏在很深的日志里，排查起来相当费劲。比较稳妥的做法是先观察应用的正常水位，再乘以2到3倍作为上限，例如常态运行80个任务的应用，设置200到300比较合理。
另一个常见误区是认为PID限制可以替代CPU和内存限制。实际上fork炸弹即使被截断，已创建的几百个进程仍会竞争CPU和内存，所以完整的资源隔离方案应该是四件套：pids、cpu、memory、blkio一起配置，多维度组合才能构成真正的容器安全边界。
最后建议定期做演练：在测试环境的容器里手动执行fork炸弹（最好用受控的版本，比如限制循环次数），确认限制值生效、容器外的进程数保持稳定。防线只有被验证过才算真正存在，否则只是配置文件里一行看起来很安心的数字。