容器资源限额的核心目标是实现有边界的运行，内存必须设硬上限并控制swap（如--memory=512m --memory-swap=512m），cpu须用--cpus做硬配额而非仅靠--cpu-shares权重，pid需显式限制防fork炸弹，io和网络也应按服务类型补充限流。
容器编排资源限额的核心目标，是让每个容器“有边界地运行”，而不是靠运气或隔离机制来避免拖垮宿主机。命名空间只管“看得见”，cgroups 才管“用得着”——没设硬上限，再好的隔离也挡不住一个失控的进程吃光内存、打满 CPU 或 fork 出几万个子进程。
内存必须设硬上限，且 swap 要明确控制
仅用 -m 512m 不够：它只限制物理内存，容器仍可大量使用 swap，最终导致磁盘 IO 暴涨、响应延迟飙升甚至系统假死。关键在 --memory-swap：
- --memory=512m --memory-swap=512m：完全禁用 swap，强制只用 512MB 物理内存（推荐生产环境）
- --memory=512m --memory-swap=1g：允许最多 512MB swap（总上限 1GB），适合短时峰值但需宿主机已启用 swap
- --memory-swap=-1：开放全部 swap —— 生产中禁用，等于放弃内存兜底控制
启动后进容器验证：cat /sys/fs/cgroup/memory/memory.limit_in_bytes 应为 536870912（512MB），cat /sys/fs/cgroup/memory/memory.memsw.limit_in_bytes 应与之相等才表示 swap 真正关闭。
CPU 用 --cpus 做硬配额，别依赖 --cpu-shares
--cpu-shares 是权重，不是限制：空闲时容器照样能跑满所有核；只有多个容器争抢 CPU 时才起作用。防止单应用霸占资源，必须用 --cpus：
- --cpus=1.5：容器每 100ms 最多使用 150ms CPU 时间，本质是硬性周期配额
- 搭配 --cpuset-cpus="0-1" 可绑定到特定物理核，减少跨 NUMA 访存开销
- Java 类应用还需同步调小 JVM 堆（如 -Xmx384m），否则堆外内存可能绕过 Docker 限制
PID 数量必须显式限制，防 fork 炸弹
PID 命名空间本身不限制创建数量。默认不设限时，一个简单 fork 炸弹几秒就能耗尽系统 PID 总数（通常 32768），导致新进程无法启动、整个宿主机僵住：
- --pids-limit=128：该容器内最多运行 128 个进程/线程（含子线程）
- 值为 -1 表示不限 —— Docker 默认行为，生产务必覆盖
- 禁止搭配 --pid=host 或 --privileged，否则限制失效
验证方式：docker exec -it 容器 cat /sys/fs/cgroup/pids.max 应输出具体数字（如 128），而非 max。
IO 和网络需按服务类型补位
对数据库、对象存储、日志聚合等 I/O 密集型服务，磁盘吞吐打满会卡住整个宿主机的 I/O 队列：
- --device-read-bps=/dev/sda:30mb：限制从 sda 每秒最多读 30MB
- --device-write-iops=/dev/sda:150：限制向 sda 每秒最多写 150 次 IO
- 对外服务应走反向代理（如 Nginx），在入口层用 limit_req 控制单 IP 请求频率
- 宿主机防火墙（iptables/nftables）丢弃异常 SYN 包或端口扫描，减轻内核协议栈压力
不复杂但容易忽略：所有限额都应在容器启动时一次性指定，Docker 不支持运行中动态收紧关键项（如内存上限），更新只能放宽或调整非核心参数。
