故障隔离的关键在于通过cgroups对cpu、内存等资源设硬性限制：--cpus=0.8实现绝对cpu上限，--memory=512m防止oom波及其他服务，需验证cgroup版本与驱动匹配，并可结合systemd做服务级兜底。

故障隔离的关键，在于让单个容器出问题时不影响其他服务。cgroups 是 Linux 内核提供的底层机制，能从 CPU、内存等维度做硬性限制，避免资源争抢导致级联故障。配置重点不是“全开”，而是按需设限、留有余量、明确边界。

CPU 隔离：防止单个容器吃满 CPU

核心是控制使用量和竞争权重。生产环境建议优先用绝对限制（--cpus），而非仅靠权重（--cpu-shares）。

• --cpus=0.8：限制容器最多使用 0.8 个逻辑 CPU 核心。Docker 自动转换为 cgroup 的 cpu.cfs_period_us=100000 和 cpu.cfs_quota_us=80000，效果稳定可预期
• --cpu-shares=512：仅在多个容器同时争抢 CPU 时生效，表示相对权重（默认 1024）。适合同优先级服务间微调，不能防止单个容器打满 CPU
• 若需更细粒度，可直接写入 cgroup 文件：echo 80000 > /sys/fs/cgroup/cpu/docker/<container-id>/cpu.cfs_quota_us</container-id>

内存隔离：防止 OOM 波及系统或其他容器

内存必须设硬上限，否则一个容器内存泄漏可能触发系统级 OOM Killer，误杀关键进程。

• --memory=512m：设置内存硬上限。超出时内核会终止该容器内进程，但不会影响其他容器或宿主机服务
• --memory-swap=1g：控制内存 + swap 总用量，避免 swap 膨胀拖慢整机 I/O
• 搭配 --oom-kill-disable=false（默认），确保 OOM 时容器内进程被清理，而不是挂起等待资源

配套要点：让隔离真正生效

只配参数不够，还需确认运行时环境支持且未被覆盖。

• 检查宿主机是否启用 cgroups v2：mount | grep cgroup。若显示 cgroup2 on /sys/fs/cgroup type cgroup2，说明已就绪；若为多个 cgroup 挂载点，则是 v1，Docker 默认兼容
• Docker 启动时需确保 --exec-opt native.cgroupdriver=systemd 或 cgroupfs 与宿主机一致，否则限制可能不生效
• 容器启动后，可验证配置：docker inspect <container-id> | grep -A 5 -B 5 'Cpu\|Memory'</container-id>，再比对 /sys/fs/cgroup/ 下对应路径的文件值

进阶建议：结合 systemd 做服务级兜底

对于长期运行的容器化服务（如用 docker-compose 启动的后台服务），推荐用 systemd 单元文件统一管控：

• 创建 /etc/systemd/system/myapp.service.d/limits.conf
• 填入：[Service] + CPUQuota=60% + MemoryMax=768M + Restart=on-failure
• 这样即使 Docker 异常退出，systemd 也能拉起并维持资源约束