本文目录导读：
针对沙箱（sandbox）自定义配置文件精准限制硬件资源（CPU、内存、磁盘 I/O、网络）的问题，需要根据你使用的沙箱技术（如 Docker、LXC、Firejail、gVisor、Kata Containers 等）选择对应的配置方式。
以下是最主流场景（Docker/LXC）和通用安全沙箱（Firejail）的精准配置方法。
核心原则
精准限制硬件资源,通常依赖 Linux 内核的 cgroups v2（部分旧系统为 v1）机制，你需要确保系统内核支持并开启了 cgroups v2。
检查方法：
mount | grep cgroup
如果输出包含 cgroup2，则为 v2。
Docker 容器（最常用）
通过 docker run 命令或 docker-compose.yml 文件中的 deploy.resources 字段进行限制。
CPU 精准限制
-
绝对限制（配额）：限制容器在每单位周期内能使用的 CPU 时间。
docker run --cpus="1.5" my_image
解释：最多使用 1.5 个逻辑 CPU 核心（例如在 4 核机器上，最多占 1.5 核）。
-
相对权重（共享）：当 CPU 资源争用时，按比例分配。
docker run --cpu-shares=512 my_image
注意：默认为 1024，权重高了不一定能抢到，但低了一定抢不到。
-
绑定物理核心（精细化）：强制容器只使用特定 CPU 核心（如 0 和 1）。
docker run --cpuset-cpus="0-1" my_image
建议：对于低延迟或高性能计算场景，优先使用
--cpuset-cpus配合--cpus使用。
内存精准限制
- 硬限制：超过则触发 OOM（Out of Memory）Killer。
docker run -m 512m my_image
- 软限制（保留内存）：尽量保证不低于此值，但物理内存不足时仍可能被回收。
docker run -m 512m --memory-reservation=256m my_image
- Swap 限制：禁用交换分区以避免性能抖动。
docker run -m 512m --memory-swap=512m my_image
（等于严格限制物理内存，不使用 swap）
磁盘 I/O 精准限制
- 读写速率限制（Bps）：
docker run --device-read-bps /dev/sda:1mb --device-write-bps /dev/sda:1mb my_image
- IOPS 限制：
docker run --device-read-iops /dev/sda:100 --device-write-iops /dev/sda:100 my_image
注意：需要指定具体的块设备（如
/dev/sda），不适用于 overlay2 文件系统内部的写入。
网络带宽限制
Linux 原生 cgroups 不直接限制网络速率，需使用 TC（Traffic Control） 或 net_prio 模块。
- 简单方法：借助
tc命令创建虚拟接口限制：# 假设容器网卡名称为 eth0，限制出站速度为 1mbit tc qdisc add dev eth0 root tbf rate 1mbit burst 32kbit latency 400ms
Docker Compose 示例：
version: '3.8'
services:
app:
image: my_image
deploy:
resources:
limits:
cpus: '0.50' # 限制 0.5 核 CPU
memory: 256M # 限制 256 MB 内存
reservations:
cpus: '0.25' # 保证 0.25 核
memory: 128M # 保证 128 MB
Firejail（轻量级安全沙箱）
Firejail 通过 --rlimit-* 参数和 --cgroup 参数实现精准限制。
CPU 限制
-
使用 cgroups（需 cgroups v2 已挂载）：
firejail --cgroup=/sys/fs/cgroup/system.slice/firejail-cpu.servic my_app
然后配合
systemd配置限制该 cgroup 的 CPU 配额。 -
使用
taskset绑定核心：firejail --taskset=0-1 my_app # 只允许使用核心 0 和 1
内存限制
- 硬限制：
firejail --rlimit-as=500000000 my_app # 限制地址空间为 500 MB firejail --rlimit-rss=200000000 my_app # 限制常驻内存为 200 MB
- cgroups 精确限制（推荐）：
# 创建容错文件 sudo mkdir /sys/fs/cgroup/my_firejail echo 256M > /sys/fs/cgroup/my_firejail/memory.max firejail --cgroup=/sys/fs/cgroup/my_firejail my_app
磁盘 I/O
- 通过
--nice降低优先级：firejail --nice=19 my_app # 最低优先级
- cgroups v1 io 限制（较繁琐）： 需要手动配置 I/O 权重。
gVisor / Kata Containers（虚拟机级沙箱）
如果使用 gVisor（runsc）或 Kata Containers，限制方法与 Docker 类似，但由虚拟化层实现。
- gVisor：使用与 Docker 相同的
--cpus和-m，但限制由 runsc 在用户态实现。docker run --runtime=runsc --cpus=1 -m 512m my_image
- Kata：同样使用 Docker 参数，但底层使用轻量级虚拟机（QEMU/Cloud Hypervisor），限制更严格。
docker run --runtime=kata --cpus=2 -m 1g my_image
常见陷阱与最佳实践
| 陷阱 | 解决方案 |
|---|---|
| 内存超卖导致 OOM | 设置 --memory-swap=0 或等于 --memory 禁用 swap。 |
| CPU 使用率 100% 但没达到限制 | 检查是否被其他进程抢占，使用 --cpuset-cpus 绑定核心。 |
| 磁盘 I/O 限制不生效 | 确保限制的是块设备（如 /dev/sda），而非 overlay 文件系统。 |
| cgroups v1 vs v2 兼容性问题 | 确认系统版本，Ubuntu 22.04+ / Debian 11+ / RHEL 9+ 默认 v2。 |
| 没有 root 权限 | cgroups 需要 root，可用 newuidmap 结合用户命名空间（user namespace）实现（较复杂）。 |
精准限制执行步骤
- 确定沙箱类型（Docker / Firejail / 其他）。
- 优先使用
--cpus和-m（最简单的绝对限制）。 - 如果需要硬隔离，结合
--cpuset-cpus绑定物理核心。 - 如果需要 I/O 隔离，使用
--device-read/write-bps/iops。 - 最终验证：
# 在容器内运行压力测试 docker exec <container_id> stress --cpu 4 --vm 2 --vm-bytes 512M
并在宿主机使用
htop或docker stats观察资源是否被精准卡住。
如果你能提供具体的沙箱框架（如 Docker、Podman、Firejail 还是自定义的 nsenter + cgroups 脚本），我可以给出更针对性的配置示例。
标签： 额度限制
