最有效方式是在启动时就设置内存、cpu、进程数和磁盘io的硬性上限。必须用-m 1g --memory-swap=1g禁用swap，配合--cpus=1.2硬限cpu、--pids-limit=150防fork炸弹、--device-read-bps限io，并通过/sys/fs/cgroup/文件验证生效。
直接给容器加硬性资源限制，是防止它拖垮宿主机最有效的方式。关键不是等出问题再补救，而是在启动时就设好内存、CPU、进程数和磁盘IO的“天花板”。
必须设内存硬上限并禁用 swap
不设内存限制，容器就能无限吃内存，触发 OOM Killer 时可能误杀 sshd、dockerd 等关键系统进程。
- 用
-m 1g --memory-swap=1g强制只用 1GB 物理内存，彻底禁用 swap - 不要只写
-m 1g却放任--memory-swap默认值（通常是 -1，即不限），那等于没限 - Java、Elasticsearch 这类应用还要同步调小 JVM 堆（如
-Xmx768m），避免容器还没超限，JVM 就先 OOM
CPU 用 --cpus 做真实硬限--cpu-shares 只在争抢时起作用，空闲时照样跑满；--cpus 才是全程生效的硬边界。
-
--cpus=1.2表示最多占用 1.2 个逻辑 CPU 时间，不管负载高低都守约 - 宿主机有 4 核，就别让单个 Web 容器设
--cpus=3，留足余量给系统和其他服务 - 高优先级网关类服务可额外配
--cpu-shares=2048，但前提是--cpus已设稳
堵住进程数和磁盘 IO 的攻击入口
DDoS 或 fork 炸弹类攻击常从这两处突破：
- 加
--pids-limit=150限制最大进程/线程数，防爆开大量子进程 - 对 I/O 密集型容器（如日志收集、文件上传服务），加
--device-read-bps /dev/sda:10mb --device-write-bps /dev/sda:5mb - Web 容器挂载 tmpfs：
--tmpfs /tmp:rw,size=50m,mode=1777，避免/tmp写满影响全局
运行时加固不能省
资源限制只是第一层，还得配合最小权限运行：
-
--read-only挂载根文件系统，阻断恶意脚本写入 -
--cap-drop=ALL --cap-add=NET_BIND_SERVICE只保留必要能力 -
--security-opt no-new-privileges:true防止提权后绕过限制
验证配置是否真生效
别只信启动命令，进容器看 cgroup 文件才是真相：
-
cat /sys/fs/cgroup/memory/memory.max应输出字节数（如1073741824= 1G） -
cat /sys/fs/cgroup/cpu.max查 CPU 配额是否匹配--cpus设置 -
docker stats 容器名实时观察 MEM USAGE / LIMIT 是否稳定在预期范围内
不复杂但容易忽略：所有限制参数必须在 docker run 时一次性写全，docker update 虽能改部分项（如内存、CPU），但像 --pids-limit、--read-only 这类只能重建容器才能生效。
