关键在于“权重+软限+统一控制面”三层协同：需先确认cgroups v2纯模式（/proc/sys/fs/cgroup/unified/hybrid为0）、单挂载点、docker使用systemd管理器；再通过cpu.weight+cpu.max、memory.weight+memory.limit+memory.swap、io.weight+pids-limit等组合实现多维动态平衡。
要用 cgroups v2 实现 Docker 多维度混部资源的动态平衡，关键不是堆参数，而是理解“权重+软限+统一控制面”三层协同逻辑。Docker 27 默认启用 cgroups v2，所有资源（CPU、内存、IO）必须在同一个层级树下协同生效，脱离这个前提谈“精细”容易失效。
确认并启用 cgroups v2 统一挂载
这是所有配置落地的前提。Docker 不会自动切换旧系统，需宿主机明确支持：
- 检查是否已启用：
cat /proc/sys/fs/cgroup/unified/hybrid输出 0 表示纯 v2 模式；若为 1，则仍处于 hybrid 混合模式，需调整内核启动参数（如添加systemd.unified_cgroup_hierarchy=1）并重启 - 验证挂载点：
find /sys/fs/cgroup -maxdepth 1 -type d | head -5应只看到一个顶层 cgroup2 挂载点（如/sys/fs/cgroup），而非多个独立子系统目录（/sys/fs/cgroup/cpu、/sys/fs/cgroup/memory等） - Docker 启动时应使用 systemd cgroup 管理器：
docker info | grep "Cgroup Manager"显示 systemd 而非 cgroupfs
CPU：用 weight + quota 实现弹性优先级调度
仅靠 --cpu-shares 只能在争抢时起作用，无法防止单个容器突发吃满 CPU。真正平衡需要“权重定比例、配额保底线”双控：
-
--cpu-shares=2048设高优先级服务（如 API 网关），--cpu-shares=512设低优先级批处理任务；两者共存时，理论时间比约为 4:1 - 叠加
--cpu-quota=60000 --cpu-period=100000（即每 100ms 最多用 60ms），防止高权重容器长期霸占资源，给其他容器留出响应窗口 - 避免使用
--cpus（硬核数限制），它在 v2 下映射为cpu.max，会直接掐断超限请求；而cpu.weight + cpu.max组合更利于突发流量平滑过渡
内存：weight 决生存，limit 定边界，swap 控回退
内存不像 CPU 可被调度让渡，OOM 是瞬时事件。必须同时控制“谁先死”和“谁不能涨”：
-
--memory-weight=900给 Redis 或 Kafka broker，大幅降低其被 OOM killer 选中的概率；--memory-weight=50给日志归档脚本，让它在压力下优先释放 -
--memory=2g设置硬上限，强制容器在达到阈值前触发内存回收；搭配--memory-reservation已废弃，v2 中请勿混用 -
--memory-swap=3g（即 swap 总量 = memory + swap），允许短暂溢出至交换区，避免立即 OOM，但需确保宿主机 swap 配置合理且不跨 NUMA 节点
IO 与进程组协同，防止隐性资源倾轧
常被忽略的是 IO 和进程生命周期对整体平衡的影响。cgroups v2 的 unified hierarchy 允许跨控制器联动：
- 用
--blkio-weight=800提升数据库容器的磁盘带宽优先级，配合--pids-limit=200限制其 fork 爆炸，避免因大量短命进程拖垮调度器 - 对定时任务容器，可设
--memory=512m --memory-weight=10 --cpu-shares=256，再通过docker update动态调低--cpu-quota在业务低峰期进一步收窄资源窗口 - 所有容器启动后，检查统一路径：
ls /sys/fs/cgroup/docker/*/cpu.weight、/sys/fs/cgroup/docker/*/memory.weight、/sys/fs/cgroup/docker/*/io.weight是否全部存在且数值匹配，确认 v2 控制器已实际接管
