本质是容器网络命名空间（netns）残留导致新容器在bind()或setns()阶段阻塞，表现为启动卡在created状态或报address already in use；需通过ls -l /var/run/netns/、ip netns list、ss -tulnp等命令验证，并用umount、rm、ip netns delete清理，预防重在优雅终止与升级Docker版本。
这个问题本质是容器网络命名空间（netns）残留导致新容器无法绑定端口或初始化网络栈，常见于使用 docker-compose up --force-recreate 或 Kubernetes 滚动更新后旧容器已退出但 netns 未被内核及时回收。它不是 Docker 本身卡死，而是新容器在 bind() 或 setns() 阶段被阻塞，表现为“启动卡在 created 状态”或日志中反复出现 address already in use、operation not permitted 等提示。
确认是否为 netns 残留问题
执行以下命令快速验证：
- 查看是否有孤立的网络命名空间：
ls -l /var/run/netns/（若存在非空条目且对应容器已退出，即为残留） - 检查内核中挂起的网络命名空间引用：
ip netns list（该命令依赖iproute2，若输出异常或卡住，说明 netns 状态异常） - 定位占用目标端口的进程（即使
docker ps显示无容器）：sudo ss -tulnp | grep :PORT（例如:8080），若显示pid=0或进程名为空，大概率是残留 netns 中的监听套接字
强制清理残留网络命名空间
不依赖重启 dockerd，直接从内核层面释放：
- 卸载挂载点（若
/var/run/netns/xxx存在）：sudo umount /var/run/netns/xxx - 删除挂载点文件：
sudo rm -f /var/run/netns/xxx - 若
ip netns list仍显示残留项，手动清理其关联的 pid：sudo ip netns delete xxx（自动触发清理） - 如上述无效，可尝试查找并 kill 关联的 init 进程（极少见）：
sudo ls -la /proc/*/ns/net 2>/dev/null | grep 'xxx'→ 找到对应 PID 后sudo kill -9 PID
预防滚动升级时 netns 残留
根本在于让旧容器真正“干净退出”，而非被信号强杀：
- 确保容器主进程（PID 1）能正确响应
SIGTERM并完成网络资源释放（如关闭监听 socket、断开连接），避免直接用docker kill强制终止 - 在
docker-compose.yml中显式配置优雅终止时间：stop_grace_period: 30s，并配合应用层 shutdown hook - 禁用
network_mode: host下的滚动更新——host 网络模式无独立 netns，但会因端口竞争引发类似现象；改用自定义 bridge 网络更可控 - 升级到 Docker 24.0+ 并启用
systemdcgroup 驱动（非默认的cgroupfs），其对命名空间生命周期管理更严格，可显著降低残留概率
验证与兜底方案
清理后，立即验证网络栈可用性：
- 运行一个最小化测试容器：
docker run --rm -p 8080:80 nginx:alpine，看是否能正常启动并访问 - 若仍失败，临时重启网络子系统（影响小，无需重启宿主机）：
sudo systemctl restart systemd-networkd（仅限使用 systemd-networkd 的系统） - 终极手段：重启 dockerd（生产环境慎用）：
sudo systemctl restart docker—— 会中断所有容器，但可彻底清空所有命名空间状态
