daemon.json不支持高可用配置，仅能通过data-root、live-restore、日志限流和资源基线等基础设置支撑ha系统稳定运行。
docker 本身不提供原生的高可用（ha）能力，daemon.json 是单机 docker 守护进程的配置文件，它不支持集群管理、自动故障转移、多节点调度或主从切换等高可用功能。所谓“docker 高可用”，实际是指围绕 docker 构建的上层编排系统（如 swarm、kubernetes）实现的，而非 daemon.json 能直接配置。
因此，daemon.json 中没有 ha、cluster、leader-election 或类似高可用语义的参数。强行在其中添加这类字段不仅无效，还可能导致 JSON 解析失败、dockerd 启动异常。
但你可以通过 daemon.json 做几件支撑高可用运行环境的关键基础配置，它们虽不等于 HA，却是 HA 系统稳定运行的前提：
✅ 1. 配置可靠的存储与数据持久化路径
避免因 /var/lib/docker 所在磁盘满或损坏导致整个 Docker 守护进程崩溃：
{
"data-root": "/data/docker",
"storage-driver": "overlay2",
"storage-opts": ["overlay2.override_kernel_check=true"]
}
-
/data/docker应挂载在独立、大容量、有冗余（如 RAID 或分布式存储）的磁盘上 -
overlay2是当前推荐存储驱动，需确保内核版本 ≥ 4.0 且已启用xfs或ext4支持 d_type
✅ 2. 启用 live-restore：守护进程升级/重启时不停容器
这是最接近“高可用体验”的 daemon 级能力——容器持续运行，即使 dockerd 临时中断：
{
"live-restore": true
}
- ✅ 容器进程不受影响（网络、存储、PID 均保留）
- ❌ 不适用于镜像拉取、新建容器、网络变更等需 daemon 协调的操作
- ⚠️ 需配合 systemd 的
Restart=always和健康检查使用才更稳妥
✅ 3. 配置稳健的日志与监控基础
防止日志撑爆磁盘导致服务雪崩，便于快速定位故障节点：
{
"log-driver": "json-file",
"log-opts": {
"max-size": "50m",
"max-file": "5"
},
"metrics-addr": "127.0.0.1:9323",
"experimental": true
}
-
metrics-addr开启 Prometheus 指标端点（需experimental: true），供监控系统采集 dockerd 健康状态 - 日志限流可避免单个容器日志失控拖垮整台宿主机
✅ 4. 配置合理的资源与安全基线
保障节点稳定性，减少因 OOM、权限越界或内核参数冲突引发的宕机：
{
"oom-score-adjust": -500,
"default-ulimits": {
"nofile": { "Soft": 65536, "Hard": 65536 }
},
"iptables": true,
"ip-forward": true,
"userland-proxy": false
}
-
-500降低 dockerd 被系统 OOM killer 杀掉的概率（比普通进程更不易被杀） -
no-file限制配合应用层连接池，防文件描述符耗尽 -
userland-proxy: false减少网络栈开销，提升负载均衡稳定性
Docker 的高可用必须依赖编排层：
-
Swarm 模式：需
docker swarm init --advertise-addr，由 manager 节点协调，daemon.json只负责本节点启动参数 -
Kubernetes：Docker 作为 CRI 运行时，HA 由 kube-apiserver + etcd + 多 master 架构保障，
daemon.json仅做基础调优
不复杂但容易忽略
