daemon.json不能配置容器级sysctl参数，仅支持全局设置如default-ulimits；容器级sysctl必须在docker run、docker-compose或kubernetes pod中显式指定，否则无效。
通过 daemon.json 统一管理 docker 集群配置，核心是让所有节点使用一致的守护进程级参数，避免逐台手动配置。它不能替代编排工具（如 swarm 或 kubernetes）的集群调度逻辑，但能统一底层运行时行为，比如镜像仓库、日志驱动、网络插件、资源限制等。
明确 daemon.json 的作用边界
daemon.json 是 Docker Engine 的静态配置文件，影响单个节点的守护进程启动行为。它不传播配置、不协调节点间状态，也不处理服务发现或任务分发。它的“统一管理”体现在：所有节点部署相同内容的 /etc/docker/daemon.json，再配合配置分发工具（如 Ansible、SaltStack、Chef 或简单脚本），实现批量同步。
常用需统一的关键配置项
以下字段在集群中建议保持一致，否则可能引发兼容性问题：
- registry-mirrors：统一镜像加速地址，加快拉取速度并降低对上游 registry 的压力
- insecure-registries：若使用私有 HTTP 仓库，各节点需同步配置，否则 pull 失败
-
log-driver 和 log-opts：统一日志后端（如
fluentd或awslogs），便于集中采集分析 - default-ulimits：避免因 ulimit 差异导致容器内应用（如数据库、Java 服务）启动失败
-
live-restore：设为
true可在不中断容器前提下重启 dockerd，提升集群运维稳定性 -
storage-driver 和 storage-opts：尤其在使用
overlay2或zfs时，驱动和参数需匹配内核与磁盘布局
安全与集群协同注意事项
有些配置看似通用，实则需按节点角色差异化设置：
-
iptables 和 ip-forward：在启用 Swarm 模式或自定义 CNI 时，应设为
false并交由网络插件管理，避免规则冲突 - experimental：开启实验特性前，确保所有节点版本一致，否则可能导致 Swarm join 失败或服务异常
-
labels：可为不同节点打 label（如
"node-type=worker"），供 Swarm scheduler 使用，此时需按角色定制而非完全统一 -
metrics-addr：若集成 Prometheus，建议统一暴露地址（如
":9323"），但注意防火墙策略需同步放开
配置生效与验证流程
修改 daemon.json 后必须重载或重启 dockerd，且需验证是否真正生效：
- 执行
sudo systemctl reload docker（支持热重载）或sudo systemctl restart docker - 检查是否报错：
sudo journalctl -u docker --since "1 minute ago" | grep -i error - 确认当前配置：
docker info | grep -E "(Registry|Log|Storage|Cgroup)" - 在多个节点上运行
docker info --format '{{.RegistryConfig.InsecureRegistryCIDRs}}'等命令比对输出
不复杂但容易忽略的是配置分发后的权限与 SELinux 上下文——确保 /etc/docker/daemon.json 属主为 root:root，权限为 644，在启用了 SELinux 的系统上还需执行 restorecon /etc/docker/daemon.json。
