核心是启用live-restore并严格遵循适用边界：仅支持同一主版本下的补丁级升级（如26.1.3→26.1.4），需在/etc/docker/daemon.json配置{"live-restore":true}，执行systemctl reload docker验证生效，且禁止变更存储驱动、bridge网络等关键配置。
要实现 docker 引擎升级时容器不断流，核心是启用 live-restore 并严格遵循其适用边界——它不是万能热升级方案，而是专为“守护进程短暂不可用”设计的保活机制。
确认 live-restore 已启用且生效
这是前提。必须在 /etc/docker/daemon.json 中明确配置：
{"live-restore": true}- 执行
systemctl daemon-reload && systemctl reload docker（推荐 reload，不中断服务） - 验证：运行
docker info | grep -i "live restore"，输出应为Live Restore Enabled: true
只适用于补丁级升级（如 24.0.7 → 24.0.8）
live-restore 仅保障 daemon 进程重启后能重新接管原有容器进程，前提是容器运行时环境未发生不兼容变更：
- 支持：同一主版本下的小版本更新（YY.MM.x 变化），例如 26.1.3 升到 26.1.4
- 不支持：跨主版本或次版本升级（如 25.0.5 → 26.0.0），此时 dockerd 启动后无法 attach 原有容器，需手动 stop + start
- 升级前务必查阅对应版本 release notes，确认 runtime 兼容性
避免触发配置冲突导致接管失败
即使启用了 live-restore，若 daemon 启动时关键配置变更，也会导致容器无法恢复管理，表现为“容器还在跑，但 docker ps 看不见”：
- 禁止修改存储驱动（如从 overlay2 改为 btrfs）
- 禁止调整默认 bridge 网络参数（如
--bip、--fixed-cidr） - 禁止变更
data-root路径或权限 - 升级包自带的默认配置变更（如新版 daemon.json 模板）需人工比对并保留原有关键项
升级操作流程（最小中断窗口）
按顺序执行，可将业务影响控制在秒级：
- 备份当前 /etc/docker/daemon.json 和 /var/lib/docker（可选但强烈建议）
- 下载新版本二进制（如
dockerd），替换旧文件（不覆盖配置） - 执行
systemctl restart docker—— 此时容器进程持续运行，父进程变为 init（PID 1） - 数秒后，新 dockerd 自动扫描并重新接管所有容器；可通过
docker ps和docker inspect 容器名 -f '{{.State.Status}}'确认状态 - 检查日志是否断续：若 daemon 停机超数分钟，容器 stdout/stderr 可能因日志缓冲区满而丢弃，建议搭配外部日志收集（如 fluentd）
