故障隔离的关键在于通过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
内存隔离：防止 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'，再比对/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 也能拉起并维持资源约束
