daemon.json不能直接配置sched_fifo/sched_rr等cpu调度策略，仅能通过default-cpu-shares、default-cpu-quota等参数间接影响cfs调度权重与带宽；实时调度需容器启动时加--cap-add=sys_nice并由进程内调用sched_setscheduler()设置。
daemon.json 本身不直接配置容器进程的 cpu 调度策略（如 sched_fifo、sched_rr 等），它无法设置 linux 内核级的实时调度类。docker 容器进程的调度行为由宿主机内核统一管理，而 daemon.json 主要控制守护进程（dockerd）自身行为及容器的默认运行时参数，不介入进程级别的调度策略配置。
能间接影响 CPU 调度行为的 daemon.json 配置项
虽然不能指定调度策略，但可通过以下参数影响容器进程在内核调度器中的权重和资源分配方式：
-
default-ulimits：可设置容器默认的
rt_priority（实时优先级）上限，但需配合容器启动时显式指定--ulimit rt_priority=...才生效；daemon.json 中仅设限，不主动赋予 - default-cpu-shares：设置容器默认 CPU 共享权重（相对值，默认 1024），影响 CFS（完全公平调度器）下的 CPU 时间片分配比例
- default-cpu-quota / default-cpu-period：为所有新建容器设定默认的 CPU 带宽限制（如每 100ms 最多运行 50ms），本质是 cgroups cpu.max 控制
- default-runtime：若使用支持实时调度的自定义运行时（如基于 runc 修改的版本），可在此指定；但标准 runc 不启用实时调度，也无对应 daemon.json 字段
真正需要进程级调度策略时该怎么做
实时调度（如 SCHED_FIFO）必须由容器内进程自行调用 sched_setscheduler() 设置，且需满足：
- 容器以
--cap-add=SYS_NICE启动（授予修改调度策略能力） - 宿主机开启
kernel.sched_rt_runtime_us（非零值，允许实时进程运行） - 进程 UID 在
/proc/sys/kernel/sched_rt_runtime_us和/proc/sys/kernel/sched_rt_period_us允许范围内
这些都属于容器运行时参数，需在 docker run 或 docker-compose.yml 中声明，不能通过 daemon.json 统一预设。
企业场景常见做法
对低延迟或确定性要求高的服务（如金融交易、音视频编码），通常采用组合方式：
- 在 daemon.json 中设
"default-cpu-shares": 2048提升默认 CPU 权重 - 禁用 swap：
"live-restore": true+ 宿主机级vm.swappiness=0 - 配合启动命令：
docker run --cap-add=SYS_NICE --ulimit rtprio=99 ... - 关键进程在容器内主动调用
chrt -f 99 ./app设置 SCHED_FIFO
