Docker Engine 29 的两个新默认值：原地升级无感，重装机器会以为镜像没了
官方资料：Docker Engine v29 发布说明 · Docker Engine version 29 博客 · 运维记录原文：Docker 29 quietly changed two defaults
v29.0.0 于 2025-11-10 发布，官方把它定位成 foundational release：新特性不多，底层改动大。补丁版本当前已到 29.8.x。发布说明里明确写了，这个版本包含多项破坏性变更与弃用，升级前需要读完。
默认值一：containerd image store 成为全新安装的默认存储
containerd image store 取代旧的 overlay2 graph driver，成为全新安装的默认镜像/内容管理层。
关键限定是「全新安装」：已有安装原地升级时不会自动迁移，继续使用 overlay2 与原有镜像，什么都不会动。
真正会踩坑的是切换存储后端，或者从零重建机器。此时 daemon 会指向一个初始为空的新存储，既有容器与镜像看起来「消失」，需要重新 pull，或者跨存储做 save/load。它们没有丢，只是 daemon 换了个抽屉，切回 overlay2 就又出现了。
docker image load / save 新增 --platform 多平台选择：
docker image load --platform linux/amd64,linux/arm64 -i image.tar
legacy graph driver 已经弃用，官方计划在未来版本移除。
默认值二：nftables 防火墙后端（实验性）
给 docker 守护进程加 --firewall-backend=nftables 即可启用。官方规划是未来 nftables 成为默认、iptables 弃用。但实验阶段有几处行为差异：
- 没有 DOCKER-USER 链。所有「把自定义规则加到 DOCKER-USER」的脚本和教程无处可挂。
- 用于覆盖 Docker DROP 规则的 ACCEPT 规则失效。一条链里的 accept 不会终止另一条链的处理。
- iptables FORWARD 链上遗留的 DROP 策略会静默黑洞掉包。Docker 的 nftables 规则已经接受，包却被 iptables 侧的 DROP 拦掉，两套子系统之间不协调。
- Docker 不会自动开启主机 IP 转发。bridge 网络需要转发，主机未开启时，daemon 启动或网络创建会直接报错，需要手动开启；也可以用
--ip-forward=false关掉这项检查，但端口转发等功能会一起失效。 - 目前不支持 Swarm 节点启用。
破坏性变更与弃用
- daemon 现在要求 API 版本 >= v1.44（Docker v25.0+）。用 pre-v25 客户端连接会报
Minimum supported API version错误。 - cgroup v1 弃用，支持延续到至少 2029-05，尽快迁到 cgroup v2。
- Docker Content Trust 从 CLI 移除，可作为独立插件单独构建。
- Go module 路径变更：
github.com/docker/docker弃用，改用github.com/moby/moby/client与github.com/moby/moby/api；github.com/moby/moby视为内部实现细节。自 v29 起发布 tag 带docker-前缀（如docker-v29.0.0）。影响 Go module 使用者与包维护者。 - 通过 legacy links 设置在容器上的环境变量弃用，不再自动添加。可用
DOCKER_KEEP_DEPRECATED_LEGACY_LINKS_ENV_VARS=1临时找回，后续版本会移除。 - Debian armhf（32 位）包现在面向 ARMv7，不再支持 ARMv6；官方不再提供 Raspbian（32 位）包，64 位设备请用 Debian arm64。
- bridge 网络的 iptables 规则更新，移除
DOCKER-ISOLATION-STAGE-1/2链。
安全加固
29.4.x 起为 CVE-2026-31431 加固：默认 seccomp profile 阻止 AF_ALG socket 与 socketcall(2) 复用器，防止容器内经内核 crypto API 提权（"Copy Fail"）。这项加固会破坏 32 位程序与 i386 镜像，包括 SteamCMD 和部分 Wine 工作负载。
29.8.x 起针对 CVE-2026-3143xx 系列持续加固，用定向 AppArmor/SELinux 规则在 LSM 层阻断 AF_ALG，覆盖 socket(2) 与 socketcall(2) 两条路径，并且不误伤合法的 32 位程序。SELinux 系统上需要 daemon 配置 selinux-enabled: true（默认关闭）。
一次单人运维的实测结论
环境：单台 VPS + Coolify + 少量容器。
结论是原地升级相对安全：不动镜像存储、不动防火墙后端，继续跑 overlay2 + iptables，可以放心吃安全补丁。但不要在有业务的活主机上启用 nftables，也不要在官方给出迁移指南前迁移镜像存储。
最容易踩的是「重装机器」：全新安装会默认落到 containerd 存储。要保留 registry 副本，并预期重新 pull。升级本身很无聊，重装才会给你惊喜。